AngularJS vs ReactJS for large web applications

On the September 2014 hack day at Liip we explored how AngularJS compares to ReactJS with Flux for large web applications.

There have been other comparisons before but none focused on larger web apps.

Summary; tldr

We like both frameworks a lot and since the choice for one library always depends on the applications requirements we won’t give a recommendation. Given its age, AngularJS is way more mature than ReactJS which results in more available libraries and widespread use. It is to be seen how ReactJS can use its traction to catch up with AngularJS.

A key difference between the philosophies of AngularJS and ReactJS is, that AngularJS relies on the browser DOM while ReactJS builds a virtual DOM which then can be converted to either a HTML string for server rending or to the browser DOM. This enables ‘isomorphic javascript’ (see also the JS Zürich event hosted at Liip Zürich) and tackles problems like first page load performance and search engine optimisation.

Getting started

We started our hack day by collecting aspects we thought are relevant for larger web applications.
Since we were four people, we decided to have each Liiper look at the framework they had the least prior knowledge. The Liipers Matteo De Micheli and Mano Speck dived into ReactJS + Flux while Bastian Feder and myself took a look at AngularJS. We felt this maximised fun and learning of new technologies. Then each team got their hands dirty until we discussed our findings at the end of the day.

For AngularJS we first tried to scaffold an example app with yeoman. After some setup issues we got an app generated, but we realised that we wanted to see the use of AngularJS in existing apps. We found an example angular-app based on ngbp which argues to contain a best-practice directory structure to ensure code reusability and maximum scalability. To understand AngularJS, we scanned and modified the code while reading the great AngularJS documentation.

For ReactJS and Flux we looked at the ReactJS and Flux documentation. With yahoo/flux-examples we found an example how the architecture works in practice.


In the following list we compare the two libraries in aspects we think are important for larger javascript web applications. We don’t claim this list to be complete but hopefully you’ll find it useful.

Community support

AngularJS: currently shows an impressive number of 870 modules. Learning resources in the form of courses are available for example form codeschool, egghead and udemy. Lots of companies build their apps with AngularJS. Support channels can be found on the AngularJS website under ‘Discuss’.

ReactJS: is growing but with under 100 components not quite there yet. The community compared to AngularJS isn’t too big but with Facebook, Instagram, Github and Yahoo (migrating Yahoo! Mail from YUI to ReactJS) there are more companies using it and we see lots of traction.
See the support channels when looking for help.


AngularJS: Because of many language constructs a develper has to learn, we experienced a steep learning curve. Previous knowledge of the MVC pattern helps. The declarative style using data binding reduces complexity and side effects compared to css selector matching in jQuery. Independence of css selectors for data binding is useful for simultaneous development of UI and business logic. AngularJS brings lots of functionallity like routing and models either build-in or as a module.

ReactJS: When it comes to ReactJS itself, things are pretty clear. Mixing template and view logic in components seemed weird at first, but it has good reasons and JSX is more familar to traditional HTML. Components reduce complexity by only caring about their own state and declarativly rendering it. State flows down the component hierarchy while events flow up. ReactJS is good for a “view” but an application also needs routing, models etc.

Looking at Flux things get more complex. The flux application architecture video and fluxxors documentation give a good overview but at the end of the day we felt that we didn’t fully grasphed the concept yet.

Interoperability (use of existing libraries)

AngularJS: Because services can be written the way the developer wants, it is no problem to write encapsulated code. For example using ReactJS in a AngularJS directive is not an issue. For Controller, Directive, Filter and Animation you have to adhere the corresponding interfaces.

ReactJS: Reusing existing libraries like for example markdown is possible as long as they don’t rely on the DOM. Unfortunately a lot of libraries rely on the DOM. When writing a component it needs to implement the Component API.


AngularJS: Modularisation is a core concept of AngularJS and automatic dependency resolution supports code-reuse. We like the dependency injection. Applications build with AngularJS seem to be highly extensible with directives, own services (…) and composable with modules.

ReactJS: Components are modular and reusable and share functionality using mixins. The use of composition over inheritance allows for composing an application.


AngularJS: Minified and compressed the size of the AngularJS core is under 36 KB which is quite reasonable. Depending on other external dependencies the download size could increase rapidly but that is not specific to AngularJS. If the functionality of jqLite is enough, a dependency on jQuery could be avoided. Modules have to be loaded or can be dynamically loaded using for example ocombe/ocLazyLoad. Key-Value observation like in Ember, Knockout, Backbone and Meteor (…) has a performance impact which will hopefully decrease in the future with Object.observe() in AngularJS 2.0.

ReactJS: About 26 KB (min+gzipped) for only the ‘view’ part of an application might seem big but given that a lot of Reacts functionality overlaps with jQuery and templating engines (which won’t be used anyway) it’s actually pretty small. The rendering performance is fast, thanks to their javascript virtual DOM. Because the virtual DOM is rebuilt every time something changes there is no need for observation. Rerendering of the actual DOM can be avoided and in many cases like the Khan Academy TeX editor or Githubs Atom Editor this greatly improves user experience.


AngularJS: AngularJS is widespread. Given it’s upcoming 1.3 release there are some breaking changes and also the API is cleaned of deprecated functions which is very normal. We would consider AngularJS as stable.

ReactJS: The library is production ready but hasn’t reached version 1.0 yet. There is a lot planned and changes to the API are to be expected.


AngularJS: Karma for continuous testing is fast and the built-in testing support in AngularJS feels great. We really like their end-to-end scenario runner and how testing works thanks to dependency injection.

ReactJS: Testing is possible for example with facebook’s inhouse framework Jest based on Jasmin or any other testing framework. Test utilities help to make this a little easier. Using Karma with ReactJS could be interesting.


AngularJS: Plugins for major ides (webstorm, eclipse, netbeans) are available. Yeoman generators and examples how to bundle an app with grunt/gulp are numerous. In general there is good tooling support.

ReactJS: There are tools and some editor support but IDE support is not there yet. Yeoman can be used to scaffold.

Thanks for reading. For a summary see the top.

Here is a nice project template which can help to get started with React.js:

(disclaimer: I’m the author)

Karma with React is indeed awesome.

WebStorm IDE (or other flavors like RubyMine) support JSX syntax nicely. Screencast –