Blog 17.1.2017

Angular 2 vs React – the final battle – round 1

Good to see you here! We have no doubt this post has good information, but please keep in mind that it is over 7 years old.

My last blog post discussed Gofore’s projects from different angles. One of the blog infographics compares front-end technologies used in our projects. Two of the most desired technologies were Angular 2 and React. But how do we know which is better?
Two talented front-end professionals from Gofore will tell us. Roope Hakulinen has taught Angular 2 to tons of developers and uses Angular 2 daily. Henri Heiskanen is a hardcore React advocate and a 24/7 coder. So let’s get down to business and give the microphone to Roope and Henri.
Q1: Tell us a little bit about yourselves and when you became fans of Angular 2/React?
Henri: I’ve been building JavaScript applications for the past ten years and during that time I’ve seen a slew of different JS frameworks come and go. React first caught my attention shortly after it was open-sourced back in 2013 when it started to make waves in the community. At the time, React was a game-changer because it really forced developers to think about their UIs as a function of a one-way data stream where state is more centrally managed and DOM updates done by React itself. For me, this was the biggest shift in the frontend landscape ever since jQuery & co.
Roope: I have been a full-stack developer several years on various web applications. Earlier on my career I was working for really long time on a project that was built on top of its own “framework” and when it got more complex, the development itself got really tedious and repetitive. Most of the code was just boilerplate and two-way data binding was made by hand over and over again. Then I found this new, hyped framework called AngularJS 1 that totally opened my eyes on how should the things be done. I quickly realized that there are some problems with the framework, but still it was much better than anything I had seen before.
Time went by, and a new hype arose, this time called React. React, and the ecosystem around it (yes, looking at you Redux), did many things better than AngularJS 1. React is great, but it’s not perfect for everyone. More about that on Q3.
The way I see it, Angular 2 has learned a great lesson from both AngularJS 1 and React. It fixed the performance problems and obscure change detection of AngularJS 1, while at the same time applying the pattern of components made famous by React. I have used Angular 2 from the first beta releases for our major project, and even though working on the bleeding edge wasn’t always such a joy ride, it sure was a love at first sight. You can read more about those experiences with early Angular 2 versions on my blog post from last spring.
Q2: What are the top three advantages of React/Angular 2?
Henri: For one thing, React is just a view library as opposed to a full-featured framework like Angular 2, giving developers more choice structuring and architecting their web apps. If need be, React would be easy to swap out for a another view library, especially an API-compatible alternative like Inferno or Preact.
Second, React does a very good job of guiding newbies toward using it effectively — there really aren’t too many ways you can go wrong with React even if you’ve never used it before. Now this is important when you have a team with different levels of exposure to frontend development. You can read through the official docs in a few hours and immediately get a good grasp of how to work effectively with React — there’s really not much to learn when it comes to the API.
Third, React is very universal as you can pair it with a number of different renderers and target different rendering platforms like the canvas, WebGL or mobile platforms (with React Native). Obviously, choosing to go native with React Native would allow you to build high-quality native apps with potentially significant chunks of code carrying over from your web app.
Roope: First, and foremost, I’d say that it is a complete solution. This doesn’t mean that you couldn’t fine-tune it as you wish, but the batteries are included which makes starting with it a pleasant experience. What I mean by complete solution here is that you don’t need to first analyze all libraries, such as routing, available and how they suit to your needs. Instead you get a full package with everything to get far. It still leaves a lot of control for developer. Good example of this is the @ngrx/store which implements the pattern of Redux with RxJS enabled, thus allowing seamless integration with your application. Also starting a new application is piece of cake with Angular 2 CLI which is also supported by the large core team from Google.
Q3: What are the top disadvantages of the rival technology?
Henri: One thing that I’ve never really liked about Angular is the fact that it is an all-encompassing framework with very limited scope for architectural customization. There’s always been “the Angular way” of doing things which may not be instantly obvious let alone well communicated by the official docs.
There’s also some degree of framework-specific syntax to learn with Angular 2, and if you take a look at the A2 API reference you’ll see there’s a whole bunch of enterprisey-looking APIs to learn. Investing your time to learn a ton of framework-specific APIs might not seem like a very attractive idea especially when most alternatives provide a minimal API that’s easy to work with right from the get-go.
And speaking of syntax, one thing that personally puts me off Angular is its heavy reliance on the OOP (read: dark) side of the ECMAScript spec with regular A2 code being littered with classes and decorators in preference to more functional alternatives. If your development team is OOP-influenced and coming from a non-JS background, the typical A2-TypeScript setup makes it easy to architect the app around familiar OOP anti-patterns resulting in a codebase with excessive class inheritance, needlessly generic typed interfaces and other forms of unwarranted indirection. Some of Angular’s core concepts that have their roots with enterprise IoC containers, such as dependency injection and providers, only add to the feeling of familiarity with enterprise backend environments, making the issue all the more relevant.
Roope: These claims aren’t too original as they are all the common arguments against React. First thing that really makes a clear difference between Angular 2 and React is of course the fact that Angular 2 is a complete platform whereas React is just a library with ecosystem built around it with a lot of opinionated choices to be made. This can be really tedious for newcomer or even for a little more experienced developer. It also takes a lot resources to keep track all the new things happening and at the same changing from project to project becomes harder. In Angular 2, if the recommended (not enforced) Angular 2 CLI is used, it is extremely easy to dive into projects never seen before. I can tell that based on the huge amount of Angular projects I’ve had the chance to help people with.
Even though related to the previous one, the second point is that it is really easy to go wrong with React since it gives you so little guidance. There are plenty of examples of these. Also it seems that every project needs to invent the wheel again by starting with plain React, then realizing that X is needed for something, and then the whole app needs to be refactored again. This happens again and again and leads to a lot of developers’ precious time wasted.
Although it has its pros along the cons, React’s JSX is a little less abstract way to describe the view. It forces developer to think in JavaScript terms whereas Angular 2 provides more controlled environment with no need to repeat `this` or do any binds. Then again, with Angular 2 you can easily have different renderers that have totally different syntax for templates than the default one provided. Angular’s default template syntax clearly indicates what properties set actually do. This is of course one thing to learn (though there is only 5 additions to HTML syntax), reading templates comes really efficient and easy to follow.
Q4: React is just a web library and Angular 2 is a full framework. Is this going to be a dealbreaker for Angular 2?
Henri: This is obviously something you need to consider before committing to either one. I don’t see it as a dealbreaker, but you have to accept the fact that you need to go all-in for Angular 2 if that’s your choice. This can limit your customization options further down the line, but it can also be easier to get started if you’re willing to go with one popular set of opinions, not having to do all the plumbing yourself. This can be a good starting point if you have a less experienced team (or a team with a background in backend development) building the app.
There’s also create-react-app, which can give you a similar quick start with a React-based stack while retaining the option for more architectural control in the future.
Roope: I don’t actually think so. I do believe there is a place for both of them. Angular 2 is ideal for many things, but it is extremely useful for getting to speed as fast as possible while still providing the performance and architecture needed for enterprise applications.
React on the other hand concentrates on a little bit different angle. The core is kept minimal and easily extensible. JSX also is a somewhat different approach than the one used in Angular 2.
And who knows, maybe this will be the year of Vue instead?
Thanks Roope and Henri for your time for now! Part two will dig deeper into technical details. Read more about the battle from Angular 2 vs React- the final battle – round 2.
Author: Juhana Huotarinen
Experts: Henri Heiskanen & Roope Hakulinen
Graphic design: Ville Takala

Angular 2


Back to top