What are we going to compare?
The answer to this question isn’t the most straightforward. On the one hand, we have a relatively small ReactJS library for building user interfaces and a comprehensive AngularJS web application development framework, while on the other hand, AngularJS 1.x differs a lot from AngularJS 2.x, and the latter is only in the Release Candidate 2 state at the moment. I’ll sometimes refer to ReactJS itself, and other times I’ll refer to the ReactJS ecosystem. As for AngularJS, I’ll mention both versions were appropriate.
Framework vs Set of Libraries
AngularJS is a web application development framework, and like all other frameworks, it provides many out-of-the-box solutions, so many functional design decisions are just prescribed by the framework. It doesn’t mean that starting a new project with AngularJS is a piece of cake. But after spending some time reading and playing with the framework, you’ll know what parts it consists of, what their responsibilities/purposes are, what conventions are in place, where things have to be go, etc.
The dark side of the moon here is that you may find yourself fighting with the framework at times rather than dealing with project tasks. If something goes wrong, or you need something that the framework isn’t designed to do, you may end up spending a large amount of time figuring things out. This isn’t, however, something exclusive to AngularJS. AngularJS is a good framework for developers with a huge community full of useful tips and handy extensions.
In contrast to AngularJS, the ReactJS ecosystem is a solution built of many composable, single-purpose tools in which ReactJS is just one building block. You’re free to add only what’s needed for your application, which is good because you can build a light-weight high-performance solution that addresses exactly the issue you need to address.
This approach, of course, has its disadvantages. At the early stages of working with ReactJS, developers will need to spend a good deal of time finding out what library you need to use for a particular task, how to integrate it with other libraries, and finally learn the libraries that are probably written by different teams and developers, and may use different conventions and philosophy.
Newcomers are likely to ask questions that might seem strange, like “Where do I write API calls?”, which are, in fact, not that obvious. Of course, with hands-on experience and newcomer learning roadmaps, things will get better soon.
To conclude, AngularJS and ReactJS offer different approaches to building applications for development companies, and none of them is better than the other. Depending on application use cases and specific system requirements, you’ll go from AngularJS development to ReactJS, and back. When you go for AngularJS, it usually means that it’s going to be the core framework for a frontend application, while ReactJS can be used to enhance particular parts of the application. For example, you can use it only for a single page on your website, or you can integrate it with other frameworks, such as Backbone or even AngularJS (that’s right, head over here for an example).
We’re talking about frontend development here, so the way a particular tool builds UI is very important.
“We strongly believe that components are the right way to separate concerns rather than "templates" and "display logic." We think that markup and the code that generates it are intimately tied together. Additionally, display logic is often very complex and using template languages to express it becomes cumbersome.
In order to make this easier, we've added a very simple, optional HTML-like syntax to create these React tree nodes.”
Without JSX, I would definitely vote for the AngularJS approach. However, JSX helps to build more readable UI component code which makes life significantly easier. Still, developers will take some time to get comfortable with JSX.
The second difference is that ReactJS has been a “one-way binding” tool from the very beginning. AngularJS 1.x was a “two-way binding” tool. While “two-way binding” was an approach loved by many developers, in AngularJS 2.x (surprise!), it was dropped. Because of this, I’m not going to compare these approaches. I’ll just mention that “one-way binding” in AngularJS 2.x and in ReactJS isn’t the same thing. The binding mechanism is completely different. It provides wider functionality in AngularJS 2.x compared to ReactJS. We’ll have to wait and see how it works in AngularJS 2.x. In ReactJS, the one way rendering flow is very straightforward, fast and easy to understand, debug and trace in comparison to “two-way binding” implemented in AngularJS 1.x.
In AngularJS 2.x, the new change detection approach (and dom manipulation approach) is coming. It’s meant to be based on change detector classes generated in runtime. They also say it’s going to be very fast. The ReactJS change detection approach is based on Virtual DOM, which means that ReactJS diffs the DOM of the new state with the previous state and only renders the difference. This approach is easy to understand and trace with ReactJS debug add-ons. Even if the AngularJS 2.x approach has better performance, I still think the ReactJS approach will remain simpler and better.
To sum it all up, it’s possible to build a working development environment for all of these options, but some amount of effort will have to go into it. It does seem like this year, things are going to change. Many IDE vendors are working on ES6 support, and Microsoft Visual Code is coming.
Based on my personal experience, the learning path of the ReactJS ecosystem isn’t all that easy, but it’s still easier than the learning path of AngularJS. To be more precise, it’s easier to get started with AngulaJS, but the second stage, where you come across complications and sometimes fight with the framework/libraries, is much easier with ReactJS development. For example, in our projects we had rendering and routing issues, and it was much easier to find the causes of these issues in React projects than in AngularJS 1.x projects.
As for AngularJS 2.x, I believe that the situation won’t change since the new version is going to be as comprehensive and complex as the predecessor, if not more complex (at least internally).
One More Thing
AngularJS is maintained by Google and is used in some Google projects, but that doesn’t make it a crucial mission for the tech giant. ReactJS was developed by Facebook for their own needs and it still plays a very important role in the company. So right now we can expect more smooth improvement from the ReactJS library and the related ecosystem.
It seems that AngularJS 2.x will be ready for production at the end of 2016, however, we can’t be 100% sure about it. Unfortunately, the date of the first release isn’t set yet. This is big because launching a new project with a release candidate version is quite risky. In addition to that, it’ll take some time to adapt the rich set of components developed by the community to the 2.x version. Starting a new project with Angular 1.x also doesn’t look attractive since migration to version 2.x might be very tricky. At the moment, Angular 1 to Angular 2 Upgrade Strategy is a fifteen page document in “draft” state. And this is only strategy, you can’t really predict how many actual tasks you’ll need to complete in order to migrate, what tasks will be automated, and what you’ll have to do manually.
The ReactJS development ecosystem, on the other hand, provides everything you need to develop full-featured web applications, plus isomorphic rendering (including server-side rendering and native UI rendering) and a great level of performance.
Considering everything we’ve just described, we currently give our preference to the ReactJS ecosystem in our projects, and are eagerly waiting for AngularJS 2.x, which looks very promising. We also think that both will continue to improve, and we’re definitely going to use both of them in the future.