Jon Knight

Nov 19, 2021

Angular vs. React: Which Is Better for Web Development?

There are countless articles out there debating whether React or Angular is the better choice for web development. Do we need yet another one?

The reason I wrote this article is because none of already—although they contain great insights—go in-depth enough for a practical front-end developer to decide which one may suit their needs.

In this article, you will learn how Angular and React both aim to solve similar front-end problems though with very different philosophies, and whether choosing one or the other is merely a matter of personal preference. To compare them, we will build the same application twice, once with Angular and then again with React.

Two years ago, I wrote an article about the . Among other points, the article argued that Angular had become the victim of “death by pre-announcement.” Back then, the choice between Angular and almost anything else was an easy one for anyone who didn’t want their project to run on an obsolete framework. Angular 1 was obsolete, and Angular 2 was not even available in alpha version.

On hindsight, the fears were more-or-less justified. Angular 2 changed dramatically and even went through major rewrite just before the final release.

Two years later, we have Angular 4 with a promise of relative stability from here on.

Now what?

Some people say that comparing React and Angular is like comparing apples to oranges. While one is a library that deals with views, the other is a full-fledged framework.

Of course, most will add a few libraries to React to turn it into a complete framework. Then again, the resulting workflow of this stack is often still very different from Angular, so the comparability is still limited.

The biggest difference lies in state management. Angular comes with data-binding bundled in, whereas React today is usually augmented by Redux to provide unidirectional data flow and work with immutable data. Those are opposing approaches in their own right, and countless discussions are now going on whether mutable/data binding is better or worse than immutable/unidirectional.

As React is famously easier to hack on, I’ve decided, for the purpose of this comparison, to build a React setup that mirrors Angular reasonably closely to allow side-by-side comparison of code snippets.

Certain Angular features that stand out but are not in React by default are:

Data Binding

Data binding is arguably easier to start with than the unidirectional approach. Of course, it would be possible to go in completely opposite direction, and use or with React, and with Angular. But that would be a topic for another post.

Computed Properties

While performance is concerned, plain getters in Angular are simply out of question as they get called on each render. It’s possible to use from , which does the job.

With React, it’s possible to use from MobX, which achieves the same objective, with arguably a bit nicer API.

Dependency Injection

Dependency injection is kind of controversial because it goes against current React paradigm of functional programming and immutability. As it turns out, some kind of dependency injection is almost indispensable in data-binding environments, as it helps with decoupling (and thus mocking and testing) where there is no separate data-layer architecture.

One more advantage of DI (supported in Angular) is the ability to have different lifecycles of different stores. Most current React paradigms use some kind of global app state which maps to different components, but from my experience, it’s all too easy to introduce bugs when cleaning the global state on component unmount.

Having a store that gets created on component mount (and being seamlessly available to this component’s children) seems to be really useful, and often overlooked concept.

Out of the box in Angular, but quite easily reproducible with MobX as well.

Routing

Component-based routing allows components to manage their own sub-routes instead of having one big global router configuration. This approach has finally made it to react-router in version 4.

Material Design

It’s always nice to start with some higher-level components, and material design has become something like an universally-accepted default choice, even in non-Google projects.

I have deliberately chosen over the usually recommended , as Material UI has serious self-confessed with their inline-CSS approach, which they plan to solve in the next version.

Besides, used in React Toolbox is starting to replace Sass/LESS anyway.

Scoped CSS

CSS classes are something like global variables. There are numerous approaches to organizing CSS to prevent conflicts (including ), but there’s a clear current trend in using libraries that help process CSS to prevent those conflict without the need for a to devise elaborate CSS naming systems.

Form Validation

Form validations are a non-trivial and very widely used feature. Good to have those covered by a library to prevent code repetition and bugs.

Project Generator

Having a CLI generator for a project is just a bit more convenient than having to clone boilerplates from GitHub.