There are some specific pieces of information in this article that are accurate.
- Angular templates have some JS in HTML while React with JSX has some HTML in JS.
- Angular is a more comprehensive library while React is more of a targeted micro library.
- The Angular 2 file size in some cases is indeed larger than the React file size.
- The React tooling is currently better than the Angular 2 tooling.
While I think Cory did a really good job bringing up these points and making this article entertaining, I do not feel like this is a true “comparison” of the frameworks. Cory explained React like a rock star, but there were a few key points missing from the Angular 2 side of things.
- Angular 2 is still in beta. Some of the criticisms (as I will point out below) will be a non-factor by the time it is in full release.
- As Cory updated in the article, the size of the Angular 2 package will get smaller before the release. Just recently they split out RxJS and in the team meeting that occurred today, they mentioned that reducing the package size is now one of their top priorities. In fact, one of their goals is to “get Angular 2 Hello World app in under 10K payload size”. With the most recent release, Angular 2 is already down to 164K. Simply put, size isn’t going to be an issue for Angular 2.
- The error messages and tooling for Angular 2 is not yet to the level of React, but it is actually better than Cory describes. It is certainly better than Angular 1 and all indications that are that it will be really good by the time Angular 2 is released. When you using Angular 2 with TypeScript and when you consider the Angular CLI will be around soon, the tooling story gets even better. Basically, almost any tooling that is used in React today can (and likely will) be built before long for Angular 2. For example, check out Minko Gechev’s hot loader for Angular 2.
- A lot is mentioned in this article about Angular’s template syntax. Yes, the ngFor syntax is something Angular specific and takes some getting used to, but besides that one specific thing, everything else in the Angular 2 template just adheres to a generic set of principles. Namely, binding to DOM properties with [prop]=”val” and propagating events up from components with (event)=”someFunc()”. Two points on this. First, if the brackets and parenthesis really irk you for some reason, you can always use the alternative syntax instead (i.e. bind-prop=”val” and on-event=”someFunc()”). Also, I seriously don’t think this is any harder to learn than the actual DOM events and stuff used with JSX. Sure, onClick=”someFunc()” is the pure JS way of doing it, but if you know that (or you look it up) and you know the pattern for Angular (i.e. onBlah translates to (blah)) then does it really matter that much? One last point is that by using the Angular syntax, the framework will actually warn you if “blah” is not a valid event.
- Regarding React’s JavaScript-centric design, I think there is one point that is missed here. While it is fair to say that JSX is more JavaScript-centric than Angular templates, Angular 2 is actually really JavaScript-centric as well. All of the old, quirky Angular 1.x APIs (i.e. angular.module, directives, etc.) are gone. Instead all you have is basic ES6 (or TypeScript) + decorators. Since all the “Angular stuff” is in decorators (which, btw, generally just attach meta-data to functions for use by the runtime), you can really easily test and share a large majority of your Angular 2 code with any other framework. In fact, at my company, GetHuman, we are building both a React app and an Angular 2 app that will probably end up using about 75% of the same code because that code is just plain old JavaScript.
- While I think JSX (and, more generally, React rendering) is cool and while I agree with the advantages stated in this article, there are a couple downsides. React rendering is currently a blocking call that will execute during every cycle (unless you specifically tell it not to with shouldComponentUpdate). Angular 2 components in contrast are loaded asynchronously and the template can be pre-compiled. The async part means that Angular 2 can (theoretically…still in the process of working on this with our Angular Universal project) scale better than React on the server side. The pre-compilation means that in some circumstances, Angular views could (again this is early so not enough track record to say definitively) load faster.
I have been meaning to put together my own comparison blog post for awhile now. I haven’t had time, but I will cut to the chase of what it is going to say:
React and Angular 2 are both really, really awesome. You will be just as productive and do just as much in one as the other. The choice in most cases will really just come down to a matter of preference.
I talk about this in more detail within my friend, Kent C. Dodd’s AMA.
One last recommendation I have if you are interested in comparing React with Angular 2 is to check out Minko Gechev’s Clash of Technologies document he created a couple months ago.