What are we going to compare?
Things are more complicated than they may appear at first partly due to the differences between the versions of AngularJS. On the other hand, ReactJS isn’t also as simple as you may suppose. It has acquired such components like React Router and Redux, which altogether with the library itself work as a serious ecosystem. In this article, sometimes I’ll refer to ReactJS itself, while other times I’ll mention ReactJS ecosystem. As for AngularJS, I’ll refer to different versions including new AngularJS 4 (became available on the 23 of March, 2017), which is backward compatible with Angular 2.
This is an updated article of the one that was published on the 8 of July, 2016. Therefore, I would like mention the main news that have taken place since the first article. Angular 2 came out with semantic system versioning that was meant to make switch between versions more meaningful. However, later when the time to switch to Angular 3 came, this improvement partly caused the problem. Finally, due to misalignments in Angular versions, package router was unable to find Angular 3. This is how third version had been skipped and after a number of beta-versions, Angular v4 was recently launched.
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, 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 lightweight 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.
The ReactJS development team described the rationale behind this decision very well:
“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.”
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 Angular 2.x, it was dropped. Because of this, I’m not going to compare these approaches. I’ll just mention that “one-way binding” in Angular 2.x and in ReactJS isn’t the same thing.
The binding mechanism is completely different. It provides wider functionality in Angular 2.x compared to ReactJS. 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 Angular 2.x, there is a new change detection approach (and dom manipulation approach), which is meant to be based on change detector classes generated in runtime and speed up the performance. Angular v4 is made to become smaller and faster at the same time, yet by means of different approach: the size of AOT-generated code was reduced by more than a half.
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 Angular 2.x approach has better performance, I still think the ReactJS approach will remain simpler and better.
With ReactJS, you can see code written in ES5, ES6 or even TypeScript, plus you’ll probably have to write JSX. This great variety may cause issues with decision making – what scripting language should you use and how about IDE support?
It looks like right now, the best IDE that supports all these things is WebStorm. If this one isn’t an option, and you, for instance, use Microsoft Visual Studio, just install necessary extensions (just to note, Web Essentials do make life easier) available for both Angular and ReactJS.
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. Many IDE vendors are working on ES6 support. For instance, Microsoft Visual Studio Code already supports ES6.
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 AngularJS, 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 the rendering and routing issues, and it was much easier to find the causes of these issues in React projects than in AngularJS projects. However, Angular 2 already had an option to use server-side pre-rendering possibilities by means of Angular Universal, while in Angular 4 - even better - it’s included into the framework.
Indeed, server-side rendering support, available in Angular 4, is meant to significantly improve performance and help with optimization for search engines.
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.
Semantic versioning in Angular has brought meaning to the way versions are coming out and ease to the way one switches between versions. Comparing to the painful way of switching between AngularJS and Angular 2, upgrade to Angular 4 seems to be different according to what Angular team says. Moreover, such features like server-side rendering and reduction of AOT-generated code are rather promising for solving rendering and performance issues.
At the same time, the ReactJS development ecosystem has been providing everything you need to develop full-featured web applications for a good while, plus isomorphic rendering (including server-side rendering and native UI rendering) and a great level of performance.
Considering everything we’ve just described, both Angular 4 and ReactJS would be a great fit for single-page applications. At the same time, Angular 4 would be also a number one choice for more complicated cases, where ReactJS would most likely not become a great match. Anyway, both Angular 4 and ReactJS deserve giving them a try and find out which one fits better for your purposes.