DEV Community

Matthieu Lux
Matthieu Lux

Posted on • Originally published at medium.zenika.com on

Wrong comparisons between React and Angular

For a while now, I’ve been used to switch between Angular 1, Angular 2 and React in different projects. I’ve also been talking to many different people which are fans of one or another framework. I’m able, now, to compare each solution for what they really are.

The purpose of this post is not to make another comparison between these frameworks in order to define which is best. It’s to point out that the most common comparison arguments I heard are wrong.

Most of this post will not differentiate Angular 1 and 2 as the points are valid for both. There are more similarities between Angular 1 and 2 than people tend to agree, but that’s a subject for another post!

Angular is Fullstack, React is a tiny UI library

That’s a bit of a joke, sorry for the strong words. By considering the initial design of both solutions, perhaps, yes. But today React is a complete platform. Who, recently, has ever included React as a tiny brick of their bigger Web application? Most of the times, the UI framework is the first choice for your frontend app: will you choose Angular or React (or something else)?

Once you chose React, you’re almost forced to use Babel and Webpack, nowadays you’d use create-react-app, you’d use react-router because it’s almost the only solution out there. Your code base will certainly be completely shaped by the choice of React. So basically it has the role of a “framework” and not a tiny lib whether you want it or not. Regarding the logic structure of your app in React I suggest you to wait for the second section below.

On the other hand, nobody asks questions about Angular as it’s sold as a full-featured framework. As a side note, Angular 2 supports server side rendering via a different project (Angular Universal) while React supports it out of the box. So the position of both frameworks are a bit different for sure, but in the bigger picture, they are both “big frameworks”.

People defending this difference often bring a strange last argument. It’s the question of “the requester lib” (you know, fetch, $http, Http, axios, superagent). Ok, React doesn’t provide one, Angular does. It’s almost the only real freedom you have with React so I think this is not a sufficient point to keep this strong line between the two solutions…

Angular organizes your logic, React doesn’t and you have to use Flux

If you look at most of the open source projects with Angular or React, it’s true. Most of Angular apps are organized with “Angular services” and most of React apps use a Flux implementation. However, I spent some time recently to really analyze the conception differences between React and Angular on this question.

My results are very different from the common acknowledgement. Angular is not organizing your logic. Angular provides you dependency injection system which allows you to manage singleton easily and improves testability. But your logic is still contained in a whole bunch of singletons. People whoever have developed a big Angular application knows that singletons are not sufficient to a logic organization.

This singleton approach is perfectly doable with React and JavaScript modules. You define a class and export an instance of it and… voilà, or you can event just export an object literal. You perfectly “can” develop pretty big React interfaces just with this.

But in the real world, motivated by Facebook intents, the React “Community” started to consider that this is not enough and wanted more. They added the Flux pattern and now, (almost) everyone agrees on using Redux. But Redux is not at the same level as Angular services, it’s a new paradigm, and I’ve seen many Angular apps which could/would/have benefit of using this new paradigm too.

My point is: an Angular app can have an architecture fully based on dependency injection singletons. In the same way, a React app can also be managed by JavaScript module singletons exclusively. Flux and Redux are cutting edge patterns which are interesting for any app, whatever the framework it uses.

Zone.js is the revolution of change detection

I’m not a true expert of how Zone.js works, but its main feature is to monkey-patch (replacing built-in functions) of all browser events to let a framework, in this case Angular 2, know if it happens anything that requires a new rendering.

To trigger a rendering, in Angular 1, you have to call $scope.$apply(), generally, the framework does this for you and you don’t have to do it yourself but basically it was the mechanism. In Angular 2, with Zone.js, you don’t have to worry at all: Zone watches if something append without any explicit call. What about React? React API makes things a lot easier by making you change props or call setState, so basically, it’s completely explicit. React re-render nothing if you don’t say to.

So my point is that you can like or dislike Zone.js. But you have to understand that is not where change detection magic is happening. It’s a convenience for triggering change detection but nothing else.

Finally, back to Redux (or NgRxStore), if you use a solution like this, no matter the framework you use, Redux will be aware of any change happening in your application state and will be able to trigger a rendering. In this context, there is no need setState, $apply … and Zone.js as well.

So… Are there any difference?

Yes, of course, there are. Just not these ones! The one I value the most these days is the global design and API. The API is the thing you’ll deal with the most of your time, you’d better like it. I was about to sum up both React and Angular with 2 or 3 main ideas but I realized it was way too risky. Take a look at the key features of each frameworks and choose the one which fits the best for you.


Top comments (0)