To save you some time, let me tell you something up front: this article won’t give a clear answer on which framework is better. But neither will hundreds of other articles with similar titles. I can’t tell you that because the answer depends on a wide range of factors which make a particular technology more or less suitable for your environment and use case.
Since we can’t answer the question directly, we’ll attempt something else. We’ll compare Angular (2+, not the old AngularJS) and React to demonstrate how you can approach the problem of comparing any two frameworks in a structured manner on your own and tailor it to your environment. You know, the old “teach a man to fish" approach. That way, when both are replaced by a BetterFramework.js in a year’s time, you will be able to re-create the same train of thought once more.
Where to Start?
Before you pick any tool you need to answer two simple questions: "Is this a good tool per se?" and "Will it work well for my use case?" None of them mean anything on their own, so you always need to keep both of them in mind. All right, the questions might not be that simple, so we’ll try to break them down into smaller ones.
Questions on the tool itself:
How mature is it and who’s behind it?
What kind of features does it have?
What architecture, development paradigms, and patterns does it employ?
What is the ecosystem around it?
Questions for self-reflection:
Will I and my colleagues be able to learn this tool with ease?
Does is fit well with my project?
What is the developer experience like?
Using this set of questions you can start your assessment of any tool and we’ll base our comparison of React and Angular on them as well.
There’s another thing we need to take into account. Strictly speaking, it’s not exactly fair to compare Angular to React, since Angular is a full-blown feature-rich framework, and React just a UI component library. To even the odds, we’ll talk about React in conjunction with some of the libraries often used with it.
An important part of being a skilled developer is being able to keep the balance between established, time-proven approaches and evaluating new bleeding-edge tech. As a general rule, you should be careful when adopting tools which have not yet matured due to certain risks:
The tool might be buggy and unstable.
It might be unexpectedly abandoned by the vendor.
There might not be a large knowledge base or community available in case you need help.
Both React and Angular come from good families, so it seems that we can be confident in this regard.
React is developed and maintained by Facebook and used in their own products, including Instagram and WhatsApp. It has been around for roughly three and a half years now, so it’s not exactly new. It’s also one of the most popular projects on GitHub with about 60,000 stars at the time of writing. Sounds good to me.
Angular (version 2 and above) has been around less then React, but if you count in the history of its predecessor, AngularJS, the picture evens out. It’s maintained by Google and used in AdWords and Google Fiber. Since AdWords is one of the key projects in Google, it is clear they have made a big bet on it and is unlikely to disappear anytime soon.
Like I mentioned earlier, Angular has more features out of the box than React. This can be both a good and a bad thing, depending on how you look at it.
Both frameworks share some key features in common: components, data binding, and platform-agnostic rendering.
Angular provides a lot of the features required for a modern web application out of the box. Some of the standard features are:
Templates, based on an extended version of HTML;
Routing, provided by @angular/router;
Ajax requests by @angular/http;
@angular/forms for building forms;
Component CSS encapsulation;
Utilities for unit-testing components.
Having all of these features available out of the box is highly convenient when you don’t want to spend time picking the libraries yourself. However, it also means that you’re stuck with some of them, even if you don’t need them. And replacing them will usually require additional effort. For instance, we believe that for small projects having a DI system creates more overhead than benefit, considering it can be effectively replaced by imports.
With React, you’re starting off with a more minimalistic approach. If we’re looking at just React, here’s what we have:
No dependency injection;
Utilities for unit-testing components.
Not much. And this can be a good thing. It means that you have the freedom to choose whatever additional libraries to add based on your needs. The bad thing is that you actually have to make those choices yourself. Some of the popular libraries that are often used together with React are:
React-router for routing.
Fetch (or axios) for HTTP requests;
A wide variety of techniques for CSS encapsulation;
Enzyme for additional unit-testing utilities.
We’ve found the freedom of choosing your own libraries liberating. This gives us the ability to tailor our stack to particular requirements of each project and we didn’t find the cost of learning new libraries that high.
Languages, Paradigms, and Patterns.
Taking a step back from the features of each framework, let’s see what kind higher-level concepts are popular with both frameworks.
There are several important things that come to mind when thinking about React: JSX, Flow, and Redux.
Continue reading %Choosing between React and Angular: An in-Depth Comparison%