Why I Ditched Angular for React

A few years ago, when my code started to get cluttered with jQuery selectors and callbacks, AngularJS came to my rescue.

Angular helped me with the maintainability of my dev projects. It came with a lot of functionality out-of-the-box. It was tooled for building large-scale web apps, greatly facilitating rapid development in this genre of applications.

I remember how its two-way binding and the philosophy of Model as the single source of truth blew me away. And, in practice, they reduced data-redundancy throughout my applications.

Over time though, I discovered some pain points in Angular. Eventually they caused me enough frustration that I began looking around for alternatives.

Here are the concerns I have with Angular.

DOM for execution. Angular heavily relies on the DOM for its execution flow. In the default bootstrapping of Angular apps, it scans the DOM and compiles it with priorities of directives, which makes it difficult to debug and test the execution order.

Two-way binding is a double-edged sword. As the complexity of your components grows, this approach can lead to performance issues.

How does two-way binding affect performance? JavaScript (ES5) doesn’t have any implementation to notify for any change to its variables or objects, so Angular uses something called "dirty checking" to track data changes and sync them with the user interface (UI).

Dirty-checking is carried out after any operation is performed within Angular’s scope ($digest cycle) which leads to slower performance as the amount of bindings increases.

Another problem with two-way binding is that many components on the page are capable of changing data, which means there are multiple sources of data inputs. If not managed well, this can lead to a confusing and overwhelming situation. To be fair, this is an implementation issue, not an Angular issue in and of itself.

Angular has its own world. Every operation in Angular must go through its digest cycle, or else your components won’t sync with your data models. This leads to compatibility issues with other dependencies.

If you use any third-party JavaScript library that involves data changes, you need to wrap it with Angular’s $apply function. Or you will need to convert it to a service, if it’s a utility library. This is like having to reinvent every JavaScript library you use in order for it to interoperate with Angular.

Dependency injection. JavaScript currently doesn’t have a package manager and dependency resolver of its own. AMD, UMD and CommonJS have been solving this gap well. But, until recently, Angular did not play well with any of these. Rather, it introduces a dependency injection (DI) of its own. Though, to be fair, there are unofficial Angular dependency-injection implementations using RequireJS.

Steep learning curve. Using Angular requires learning a ton of concepts including, but not limited to:

It can be very difficult to get started with Angular. It’s not for the faint of heart.

All of this led me to React.

What’s So Great About React?

React, the new open source framework for building user interfaces, is a different way of developing JavaScript apps. React is led by Facebook and Instagram.

To be clear: React isn’t an application development framework like AngularJS. It’s not fair to compare the two in an apples-to-apples manner.

When React was introduced at JSConf EU in May 2013, the audience was shocked by some of its concepts, like "one-way data flow" and "Virtual DOM".

React is for building user interfaces. In other words, straight from the official landing page of the project: "people use React as the V in MVC." However, you can write self-contained components with it, which more or less compares to Angular directives.

React rethinks our current web development concepts and best practices.

For instance, it encourages one-way data flow and believes in a philosophy that components are state machines driven by data.

Whereas most of the other similar frameworks love working with the DOM and directly manipulating it, React hates the DOM and works to shield the developer from it.

React provides the bare-minimum API needed to define a UI component. Nothing more, nothing less. It follows UNIX philosophy: Small is beautiful. Do one thing, and do it best.

You can find a more detailed comparison of Angular vs. React by Pete Hunt (who works at Facebook/Instagram).

Why Did I Switch to React?

Here are some of the things I like about React.

React is Fast

React takes a different approach to the DOM compared to other frameworks.

It does not let you work with the DOM directly.

It introduces a layer, called Virtual DOM, between your JavaScript logic and the actual DOM.

Virual Dom illustration

This concept improves web performance. On successive renders, React performs a differential (diff) on the Virtual DOM, and then updates only parts of the actual DOM that need to be updated.

Cross-Browser Compatibility

Virtual DOM also helps solve cross-browser issues because it provides us with a standardized API that even works as far back as IE 8.


Writing self-contained UI components modularizes your app, which in turn isolates issues only to the problematic component/s.

Every component can be developed and tested in isolation, and they can use other components. This equates to maintainability improvements.

One-way Data Flow Makes Things Saner

Flux is an architecture for creating one-way data layers in JavaScript applications. It was conceptualized by Facebook along with the React view library. The Flux concept makes large-scale app development simpler.

Flux is a concept rather than a tool-specific implementation. It can be incorporated into other frameworks. For instance, Alex Rattray has a nice implementation of Flux using Backbone Collection and Model in React.

Just JavaScript

Modern web apps work in a different way compared to the traditional Web.

For example, the View layer needs to be updated with user interactions without hitting the server. And hence View and Controller need to rely on each other heavily.

Many other frameworks use templating engines like Handlebars or Mustache to deal with the View layer. But React believes that View and Controller are so interdependent that they must reside at a single place without the use of any third-party templating engine, and, on top of that, without leaving the scope of JavaScript.

Isomorphic JavaScript

The biggest drawback of single-page JS web apps is that it has limitations when crawled by search engines. React has a solution for this.

React can pre-render apps on the server before sending it to the user agent. It can restore the same state into the live application from the pre-rendered static content on the server.

Because search engine crawlers rely on the server response rather than JavaScript execution, pre-rendering your apps helps with SEO.

It Plays Well with Others

Loaders and bundlers like RequireJS, Browserify and Webpack are much needed when you’re building large applications. They make the arduous task surmountable.

Unfortunately, the current version of JavaScript doesn’t provide a module bundler or loader. (Though there’s a proposal to address this in the upcoming version, ES6, with System.import).

Fortunately we have some alternatives like RequireJS and Webpack, which are pretty neat. React is built with Browserify, but if you’re looking to inject image assets and compile Less or CoffeeScript, then probably Webpack stands as a better option. The point is: You are afforded that choice.

Do I Need Another Development Framework with React?

Using React, you can build user interfaces, but you still need to make AJAX calls, apply data filters, and other things that Angular already does.

So if we need an additional JavaScript app development framework, why ditch Angular?

Frameworks are a set of modules and rules. If I don’t need some of its modules, or want to swap out a module for another one that does the job better, how do I do it?

One of the ways to achieve modularity and better dependency-management is through package managers.

But then, how do we manage packages in Angular? That’s up to you, but know that Angular has its own world. You will most likely need to adapt third-party packages into Angular’s world.

React, on the other hand, is just JavaScript. Any package written in JavaScript won’t need any wrapping in React.

For me, using package managers like npm and Bower is better. We can pick and choose our components and craft custom toolsets. To be clear: This is more complicated compared to just using a comprehensive app development framework like Angular.

On this front, the saving grace is that React encourages the use of npm, which has a lot of ready-to-use packages. To get started building apps with React, you can, for example, use one of these full-stack starter kits.

Switching to React is Not Painless!

Since Angular is an app development framework, it comes with a lot of goodies. I’m giving up great features like an AJAX wrapper in the $http service, $q as a promise service, ng-show, ng-hide, ng-class, and ng-if as controlling statements for template — all that amazing stuff.

React isn’t an app development framework, so you need to think about how to deal with the other aspects of building applications. For example, I’m working on an open source project called react-utils which can be used with React to ease development.

The community is also actively contributing similar reusable components to fill in the blanks, so to speak. React Components is an unofficial directory website where you can find such open source components.

React’s philosophy does not encourage you to use two-way binding, which brings a lot of pain when you’re dealing with form elements and editable data grids.

However, as you start understanding the Flux data flow and Stores, things become clearer, simpler and easier.

React is new. It will take some time for the community around it to grow. Angular, on the other hand, has already gained huge popularity, and has a relatively large number of extensions available (e.g. AngularUI and Restangular).

However, although React’s community is new, it is growing fast. Extensions like React Bootstrap are a testament to this. It’s just a matter of time before we have more components available.


If you love the Angular approach, then you may hate React at first. Mainly because of it’s one-way data flow and lack of app development features. You end up needing to take care of many things by yourself.

But as soon as you get comfortable with the Flux design pattern and React’s philosophy, I guarantee that you will begin to see its beauty.

Facebook and Instagram both use React (because they are leading the project).

GitHub’s new source code editor, Atom, is built using React.

The upcoming Yahoo! Mail is being rebuilt in React.

React already has large-scale apps and big tech companies betting on it.

Related Content

About the Author

Kumar Sanket is a freelance full-stack web developer/engineer at Toptal. He specializes in modern, scalable web app development.

This was published on Jan 16, 2015


Adamatti Jan 18 2015

Great article!

For me, Angular is great because you have the HTML file with new attributes in the tags and an external JS file to do the magic.

With React, we need to move HTML code to the JS file and it seems ugly.

But React is definitely something I want to check deeper. You know, Facebook is using it, so it should be good :-)

Andrew Flint Jan 19 2015

React.js has Virtual DOM, but it isn’t faster than Angular.js, you can look at this benchmark:

Have you tried Angular Light? It’s easier than Angular.js, it doesn’t have DI, services and other excess things. It’s faster than Angular.js and has a few unique features.

Cathy Mayhue Jan 19 2015

Hi Kumar,

Very informative article! Did not know about React, so wondered how to ‘react’. Well jokes aside, it seems to be a very promising tool and if it is as effective as you have mentioned then you have just made me very happy! Many thanks!

Christophe Jan 19 2015

Thanks for your article.
What do you use for routing? A library such as Grapnel.js?

Kumar Sanket Jan 20 2015

@Christophe, I use React-router

Dwayne Charrington Jan 23 2015

Let me prefix this by saying I love React.js and have used it a bit and I am also a fan of AngularJS and used it a bit as well (I have used both together in the same project before).

You make some pretty fair criticisms about AngularJS. One of the biggest issues with Angular is its “dirty checking” which as you point out can cause serious headaches when using tonnes of two-way bindings in your application. Every blog post you read highlighting Angular’s flaws will mention this. Through experience using Angular at scale, I have seen this issue first-hand, but it isn’t entirely a deal breaker either. The way I see it, Angular has just as many flaws as any other front-end framework utilising similar tricks to get two-way binding working. After using it for a while, you eventually learn how to build applications that run into these kind of issues less and less.

One of the biggest improvements you can make to an Angular application is NOT using two-way bindings for everything. In Angular 1.3 one-way bindings were introduced, because lets face it, not everything needs to be dynamic and changed. Sometimes you just want to render certain things once and not change them. This new way of having one-way binding frees up performance considerably.

I honestly don’t see the problem with Angular working directly with the DOM. For years we were using jQuery and YUI to build applications that relied heavily on DOM manipulation, many of those who still use jQuery extensively are interfacing with the DOM (in the form of reads and writes). If managed correctly, there is nothing wrong with working with the DOM, React itself actually works with the DOM, it just does it in a more efficient and batch-processed way (like good practices have recommended for years now). Changes are merely managed in memory, comparisons and checks done in memory, it saves some heavy DOM lifting, but people shouldn’t think that React forgoes touching the DOM entirely (in React you even get a method called getDOMNode which allows you to use jQuery with React and modify the DOM).

Don’t get me wrong, I love React and coupled with Flux, it is a solid way to build an application and undeniably the future, but you don’t need to replace one with the other. As you point out yourself Angular provides you with so much that a modern application needs like routing, working with API’s via factories, providers and services. All of those exist for React as well. But in this instance, both have trade-offs.

The syntax of building a React component using JSX might feel messy to some, especially Angular users who are accustomed to using a framework that is essentially an extension of HTML utilising existing concepts and adding an additional Javascript API layer over the top to manage it. I personally like how Angular works with existing HTML, isn’t a mixture of Javascript and HTML and keeps everything nice and separated. I like the JSX syntax in React, I know many do not and for newcomers especially existing Angular fans, this might feel like a weird concept.

As I pointed out initially, I have used React with Angular before and it worked extremely well. Sometimes when you’re dealing with tonnes of UI elements dropping something like React in can save you a tonne of performance migraines (all without having to replace one with the other). The beautiful thing about React is its ability to work with almost any existing framework or library. So if you ever find yourself running into Angular performance issues and you have optimised as best as you can, maybe the next step isn’t replacing it with an entirely new framework/library, but rather looking at implementing something like React to help alleviate performance issues.

Nonetheless, great article Kumar. A nice thought provoking read.

Kumar Sanket Jan 24 2015

Dwayne, thanks for such a comprehensive comment. I understand your point and I agree with that.

One thing you misunderstood regarding DOM is that I didn’t mean DOM manipulation but I meant DOM for execution which is sometimes a pain and you don’t actually understand which part of your code executed first. But with React components, its all JavaScript and it executes like any other JavaScript snippet.

Anyway, I like AngularJS and React both but ReactJS will be my preference over AngularJS, at least until Angular 2.0 releases.

SylvainPV Jan 30 2015

So in short, Angular is a beautiful framework that does not work so well, while React looks ugly but works very well.

And what about this fresh new Aurelia ? It looks like Angular without its flaws.

Damien Jan 30 2015

About AngularJS modules, they are very different than AMD modules. Angular module are only used for component initialisation. AMD modules are used for lazy async loading of javascript files.

Beside, RequireJS development took place at the same time than AngularJS.

The only alternative to angular modules for testing is Jest and its auto mocking, and it’s rather recent.

But I doubt they would drop their modules; they would lose the possibility to extend component at runtime (overwriting components or decorating them). In Angular 2 they will simply their registry (no more factory-service-provider-value alternative way to create a service I hope) and make them easier to write using es6/atscript syntax.

Tomek Jan 31 2015


The terms like “looks pretty” and “looks ugly” are very subjective.

I wouldn’t say that AngularJS looks pretty – for my POV, it looks really ugly. It’s hell complex (many concepts to learn), difficult to use (controlers, services, modules, directives…), difficult to learn, difficult to master. This is both opinion of mine, and of my students.

And I would say that React is dead simple, and therefore looks really pretty to me. I was able to learn React in one day, and become more productive, that I was after using AngularJS for months.

Aurelia? Is it supported by so powerful company like Facebook? Is it already used in so many apps like React? Because if it isn’t, it can’t be compared with either AngularJS or ReactJS in apples-to-apples manner.

Personally, I’m looking with some hope on Riot 2.0. Although it looks strange, it uses concepts from React (so it’s simple), and it’s more lightweight. Yet, since it’s not supported by so powerful companies like Facebook, and it’s not used in so many apps like React, I wouldn’t dare to use Riot 2.0 in any prodction application. Riot 2.0 looks promising, yet it’s not ready for the real world.

React is Fast

React is definitely faster due to to reduced layout thrashing, but is Angular not fast enough for you? Short of some very specific and rare cases(rendering with large datasets client-side), the performance impact of dirty checking is negligible. I worked on a number of performance intensive applications where I had to workaround some of issues that arise when some things trigger digest cycles irresponsibly, but for just about all of them there are known practices to avoid them.

Cross-Browser Compatibility

Angular is compatible with every modern browser


You essentially described Angular Directives

One-way Data Flow Makes Things Saner

You can do two-way binding, one-way binding and even bind-once style binding in angular

Just JavaScript

Thats the beauty of angular, its just javascript, even its scope inheritance follows the prototypical model.

Isomorphic JavaScript

There are pre-rendering solutions for angular as well. is supported

It Plays Well with Others

So does Angular. Need to integrate with a jquery plugin — Wrap it in a directive and do a $scope.$apply on the neccessary dom/model changes

Hamish Feb 25 2015

Hi – you had me thinking when you were talking about the unix approach and the small components doing one thing and one thing well – where it is easy to swap something out if it isn’t working so well.

However you then lost me when you started talking about react utils and react components and a community of people writing “extensions” to react to fill the missing parts. Wouldn’t you just end up in the same position where if you remove react you now have to remove all of these as well, and hence no better than angular in that respect?

Bobby Apr 02 2015

The problem with Angular is that the documentation is vague, all the blog postings about it have varying syntax for everything, there are way too many different versions of the libraries, and they are all split up in different ways and named differently from version to version without any good explanation of whats going on. I eventually got it up and working partially and had an app half done, but then everything stopped working for no apparent reason and I backtracked and re-did everything and tried many many many different variations of code I found on blogs, and I tried downloading every version of the libraries and I could not get it to start working again. I dont feel like buying some book, and I don’t feel like joining the Google group to badger the developers about it, so I give up. The *idea* of what angular is *supposed* to be is good, dont get me wrong. But lack of clean, clear, consistent documentation is a serious problem. I dont have time to waste guessing at all this crap. Google FAIL. OH WELLLLLLLLLLLL GUESS ILL TRY SOMETHING ELSE LIKE MAYBE REACT……

lucifer Jun 17 2015

OK, angular is a framework, while react is a tool. They are not counterparties.
besides, angular is easier for full-stack developer, while react is easier for pure frontend developer.

This comment section is closed. Please contact us if you have important new information about this post.