Angular 2 versus React: There Will Be Blood

Angular 2 has reached Beta and appears poised to become the hot new framework of 2016. It’s time for a showdown. Let’s see how it stacks up against 2015’s darling: React.

Disclaimer: I enjoyed working in Angular 1 but switched to React in 2015. I’ve published Pluralsight courses on React and Flux and React and Redux in ES6 (free trial). So yes, I’m biased. But I’m attacking both sides.

Alright, let’s do this. There will be blood.

Photo credit: @jwcarrol

You’re Comparing Apples and Orangutans!

Choosing between Angular and React is like choosing between buying an off-the-shelf computer and building your own with off-the-shelf parts.

This post considers the merits of these two approaches. I compare React’s syntax and component model to Angular’s syntax and component model. This is like comparing an off-the-shelf computer’s CPU to a raw CPU. Apples to apples.

Angular 2 Advantages

Low Decision Fatigue

Angular offers more opinions out of the box, which helps you get started more quickly without feeling intimidated by decisions. This enforced consistency also helps new hires feel at home more quickly and makes switching developers between teams more practical.

I admire how the Angular core team has embraced TypeScript, which leads to the next advantage…

TypeScript = Clear Path

While Angular 2 doesn’t require TypeScript, the Angular core team certainly embraces it and defaults to using TypeScript in documentation. This means related examples and open source projects are more likely to feel familiar and consistent. Angular already provides clear examples that show how to utilize the TypeScript compiler. (though admittedly, not everyone is embracing TypeScript yet, but I suspect shortly after launch it’ll become the de facto standard). This consistency should help avoid the confusion and decision overload that comes with getting started with React.

Reduced Churn

In contrast, Angular 2 is a careful, methodical reinvention of a mature, comprehensive framework. So Angular is less likely to churn in painful ways after release. And as a full framework, when you choose Angular, you can trust a single team to make careful decisions about the future. In React, it’s your responsibility to herd a bunch of disparate, fast-moving, open-source libraries into a comprehensive whole that plays well together. It’s time-consuming, frustrating, and a never-ending job.

Broad Tooling Support

Web Component Friendly

Angular’s approach comes with its own set of gotchas, which is a good segue for discussing React’s advantages…

React Advantages

JSX

If you don’t like Angular string-based templates, you can move the templates to a separate file, but then you’re back to what I call “the old days:” wiring the two files together in your head, with no code completion support or compile-time checking to assist. That doesn’t seem like a big deal until you’ve enjoyed life in React. Composing components in a single compile-time checked file is one of the big reasons JSX is so special.

Contrasting how Angular 2 and React handle a missing closing tag

For more on why JSX is such a big win, see JSX: The Other Side of the Coin.

React Fails Fast and Explicitly

In contrast, when you mistype a variable reference in Angular 2, nothing happens at all. Angular 2 fails quietly at run time instead of compile-time. It fails slowly. I load the app and wonder why my data isn’t displaying. Not fun.

React is JavaScript-Centric

Angular 2 continues to put “JS” into HTML. React puts “HTML” into JS.

I can’t emphasize the impact of this schism enough. It fundamentally impacts the development experience. Angular’s HTML-centric design remains its greatest weakness. As I cover in “JSX: The Other Side of the Coin”, JavaScript is far more powerful than HTML. Thus, it’s more logical to enhance JavaScript to support markup than to enhance HTML to support logic. HTML and JavaScript need to be glued together somehow, and React’s JavaScript-centric approach is fundamentally superior to Angular, Ember, and Knockout’s HTML-centric approach.

Here’s why…

React’s JavaScript-centric design = simplicity

{{myVar}} //One-way binding
ngModel="myVar" //Two-way binding

In React, binding markup doesn’t change based on this decision (it’s handled elsewhere, as I’d argue it should be). In either case, it looks like this:

{myVar}

Angular 2 supports inline master templates using this syntax:

<ul>
<li *ngFor="#hero of heroes">
{{hero.name}}
</li>
</ul>

The above snippet loops over an array of heroes. I have multiple concerns:

  • Declaring a “master template” via a preceeding asterisk is cryptic.
  • The pound sign in front of hero declares a local template variable. This key concept looks like needless noise (if preferred, you can use `var`).
  • The ngFor adds looping semantics to HTML via an Angular-specific attribute.

Contrast Angular 2’s syntax above with React’s pure JS*: (admittedly the key property below is React-specific)

<ul>
{ heroes.map(hero =>
<li key={hero.id}>{hero.name}</li>
)}
</ul>

Since JS supports looping natively, React’s JSX can simply leverage all the power of JS for such things and do much more with map, filter, etc.

Just read the Angular 2 Cheat Sheet. That’s not HTML. That’s not JavaScript. It’s Angular.

To read Angular: Learn a long list of Angular-specific syntax.

To read React: Learn JavaScript.

React is unique in its syntactic and conceptual simplicity. Consider iterating in today’s popular JS frameworks/libraries:

Ember: {{# each}}
Angular 1: ng-repeat
Angular 2: ngFor
Knockout: data-bind=”foreach”
React: JUST USE JS. :)

All except React use framework specific replacements for something that is native and trivial in JavaScript: a loop. That’s the beauty of React. It embraces the power of JavaScript to handle markup, so no odd new syntax is required.

Angular 2’s syntactic oddities continue with click binding:

(click)=”onSelect(hero)"

In contrast, React again uses plain ‘ol JavaScript:

onClick={this.onSelect.bind(this, hero)}

And since React includes a synthetic event system (as does Angular 2), you don’t have to worry about the performance implications of declaring event handlers inline like this.

Why fill your head with a framework’s unique syntax if you don’t have to? Why not simply embrace the power of JS?

Luxurious Development Experience

Size Concerns

Angular 2: 566k (766k with RxJS)
Ember: 435k
Angular 1: 143k
React + Redux: 139k

Edit: Sorry, I had incorrect numbers earlier that were for simple ToDoMVC apps instead of the raw frameworks. Also, the Angular 2 number is expected to drop for the final release. The sizes listed are for the framework, minified, in the browser (no gzip is factored in here).

To make a real comparison, I built Angular 2’s Tour of Heroes app in both Angular 2 and React (I used the new React Slingshot starter kit). The result?

Angular 2: 764k minified
React + Redux: 151k minified

So Angular 2 is currently over four times the size of a React + Redux app of comparable simplicity. (Again, Angular 2 is expected to lose some weight before the final release).

Now that said, I admit that concerns about the size of frameworks may be overblown:

Large apps tend to have a minimum of several hundred kilobytes of code — often more — whether they’re built with a framework or not. Developers need abstractions to build complex software, and whether they come from a framework or are hand-written, they negatively impact the performance of apps.

Even if you were to eliminate frameworks entirely, many apps would still have hundreds of kilobytes of JavaScript. — Tom Dale in JavaScript Frameworks and Mobile Performance

Tom is right. Frameworks like Angular and Ember are bigger because they offer many more features out of the box.

However, my concern is this: many apps don’t need everything these large frameworks put in the box. In a world that’s increasingly embracing microservices, microapps, and single-responsibility packages, React gives you the power to “right-size” your application by carefully selecting only what is necessary. In a world with over 200,000 npm modules, that’s a powerful place to be.

React Embraces the Unix Philosophy.

Unix has stood the test of time. Here’s why:

The philosophy of small, composable, single-purpose tools never goes out of style.

React is a focused, composable, single-purpose tool used by many of the largest websites in the world. That bodes well for its future (That said, Angular is used by many big names too).

Showdown Summary

However, Angular 2’s size and syntax give me pause. Angular’s commitment to HTML-centric design makes it complex compared to React’s simpler JavaScript-centric model. In React, you don’t learn framework-specific HTML shims like ngWhatever. You spend your time writing plain ‘ol JavaScript. That’s the future I believe in.

Comments? Chime in on Reddit or Hacker News.

Cory House is the author of “Building Applications with React and Flux”, “Clean Code: Writing Code for Humans” and multiple other courses on Pluralsight. He is a Software Architect at VinSolutions and trains software developers internationally on software practices like front-end development and clean coding. Cory is a Microsoft MVP, Telerik Developer Expert, and founder of outlierdeveloper.com.

Pluralsight Author, Principal at reactjsconsulting.com, Software Architect, Microsoft MVP, Speaker, Clean Coder, Aspiring Outlier.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store