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 thearticlespublished 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.

Angular’s Untimely Announcement

Two years ago, I wrote an article about the React Ecosystem. 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?

Angular vs. React: Comparing Apples and Oranges

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 React developers 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.

A Level Playing Field

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 Redux or mobx-state-tree with React, and ngrx 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 BehaviorSubject from RsJS, which does the job.

With React, it’s possible to use @computed 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 React Toolbox over the usually recommended Material UI, as Material UI has serious self-confessed performance problems with their inline-CSS approach, which they plan to solve in the next version.

Besides, PostCSS/cssnext 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 BEM), but there’s a clear current trend in using libraries that help process CSS to prevent those conflict without the need for a front-end developer 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.

Same Application, Built Twice

So we are going to create the same application in React and Angular. Nothing spectacular, just a Shoutboard that allows anyone to post messages to a common page.

You will notice we have used TypeScript for the React app as well. The advantages of type checking in TypeScript are obvious. And now, as better handling of imports, async/await and rest spread have finally arrived in TypeScript 2, it leaves Babel/ES7/Flow in the dust.

Also, let’s add Apollo Client to both because we want to use GraphQL. I mean, REST is great, but after a decade or so, it gets old.

Basically, all components we want to use in the application need to go to declarations. All third-party libraries to imports, and all global stores to providers. Children components have access to all this, with an opportunity to add more local stuff.

The <Provider/> component is used for dependency injection in MobX. It saves stores to context so that React components can inject them later. Yes, React context can (arguably) be used safely.

The React version is a bit shorter because there are no module declarations - usually, you just import and it’s ready to use. Sometimes this kind of hard dependency is unwanted (testing), so for global singleton stores, I had to use this decades-old GoF pattern:

Angular’s Router is injectable, so it can be used from anywhere, not only components. To achieve the same in react, we use the mobx-react-router package and inject the routerStore.

Summary: Bootstrapping both applications is quite straightforward. React has an edge being more simple, using just imports instead of modules, but, as we’ll see later, those modules can be quite handy. Making singletons manually is a bit of a nuisance. As for routing declaration syntax, JSON vs. JSX is just a matter of preference.

Like what you're reading?Get the latest updates first.No spam. Just great articles & insights.

Links and Imperative Navigation

So there are two cases for switching a route. Declarative, using <a href...> elements, and imperative, calling the routing (and thus location) API directly.

The router module can be injected to any service (half-magically by its TypeScript type), the privatedeclaration then stores it on the instance without the need for explicit assignment. Use navigate method to switch URLs.

React Router can also set the class of active link with activeClassName.

Here, we cannot provide the class name directly, because it’s been made unique by CSS modules compiler, and we need to use the style helper. More on that later.

As seen above, React Router uses the <Switch> element inside an <App> element. As the <Switch> element just wraps and mounts the current route, it means that sub-routes of current component are just this.props.children. So that’s composable too.

The mobx-router-store package also allows easy injection and navigation.

Summary: Both approaches to routing are quite comparable. Angular seems to be more intuitive, while React Router has a bit more straightforward composability.

Dependency Injection

It has already been proven beneficial to separate the data layer from the presentation layer. What we are trying to achieve with DI here is to make data layers’ components (here called model/store/service) follow the lifecycle of visual components, and thus allow to make one or many instances of such components without the need to touch global state. Also, it should be possible to mix and match compatible data and visualization layers.

Examples in this article are very simple, so all the DI stuff might seem like overkill, but it comes in handy as the application grows.

By registering the HomeService to the component’s providers, we make it available to this component exclusively. It’s not a singleton now, but each instance of the component will receive a new copy, fresh on the component’s mount. That means no stale data from previous use.

In contrast, the AppService has been registered to the app.module (see above), so it is a singleton and stays the same for all components, though the life of the application. Being able to control the lifecycle of services from components is a very useful, yet under-appreciated concept.

DI works by assigning the service instances to the component’s constructor, identified by TypeScript types. Additionally, the public keywords auto-assigns the parameters to this, so that we don’t need to write those boring this.homeService = homeService lines anymore.

Angular’s template syntax, arguably quite elegant. I like the [()] shortcut, which works like a 2-way data binding, but under the hood, it is actually an attribute binding + event. As the lifecycle of our services dictates, homeService.counter is going to reset every time we navigate away from /home, but the appService.usernamestays, and is accessible from everywhere.

HomeComponent uses the @observer decorator to listen to changes in @observable properties.

The under-the-hood mechanism of this is quite interesting, so let’s go through it briefly here. The @observabledecorator replaces a property in an object with getter and setter, which allows it to intercept calls. When the render function of an @observer augmented component is called, those properties getters get called, and they keep a reference to the component which called them.

Then, when setter is called and the value is changed, render functions of components that used the property on the last render are called. Now, data about which properties are used where are updated, and the whole cycle can start over.

A very simple mechanism, and quite performant as well. More in-depth explanation here.

The @inject decorator is used to inject appStore and homeStore instances into HomeComponent’s props. At this point, each of those stores has different lifecycle. appStore is the same during the application’s life, but homeStore is freshly created on each navigation to the “/home” route.

The benefit of this is that it’s not necessary to clean the properties manually as it is the case when all stores are global, which is a pain if the route is some “detail” page that contains completely different data each time.

Summary: As the provider lifecycle management in an inherent feature of Angular’s DI, it is, of course, more simple to achieve it there. The React version is also usable but involves much more boilerplate.

Computed Properties

React

Let’s start with React on this one, it has a more straightforward solution.

We need to define all values that serve as a basis for a computed property as a BehaviorSubject. The computed property itself is also an BehaviorSubject, because any computed property can serve as an input for another computed property.

Of course, RxJS can do much more than just this, but that would be a topic for a completely different article. The minor downside is that this trivial use of RxJS for just computed properties is a bit more verbose than the react example, and you need to manage subscriptions manually (like here in constructor).

Note how we can reference the RxJS subject with the | async pipe. That is a nice touch, much shorter than needing to subscribe in your components. The input component is driven by the [(ngModel)] directive. Despite looking strange, it’s actually quite elegant. Just a syntactic sugar for data-binding of value to appService.username, and auto-assigning value from user input event.

Summary: Computed properties are easier to implement in React/MobX than in Angular/RxJS, but RxJS might provide some more useful FRP features, that might be appreciated later.

Templates and CSS

To show how templating stacks against each other, let’s use the Posts component that displays a list of posts.

This component just wires together HTML, CSS, and injected services and also calls the function to load posts from API on initialization. AppService is a singleton defined in the application module, whereas PostsServiceis transient, with a fresh instance created on each time component created. CSS that is referenced from this component is scoped to this component, which means that the content cannot affect anything outside the component.

In the HTML template, we reference mostly components from Angular Material. To have them available, it was necessary to include them in the app.module imports (see above). The *ngFor directive is used to repeat the md-card component for each post.

Local CSS:

.mat-card { margin-bottom: 1rem; }

The local CSS just augments one of the classes present on the md-card component.

Global CSS:

.float-right { float: right; }

This class is defined in global style.css file to make it available for all components. It can be referenced in the standard way, class="float-right".

In compiled CSS, we can see that the local CSS has been scoped to the rendered component by using the [_ngcontent-c1] attribute selector. Every rendered Angular component has a generated class like this for CSS scoping purposes.

The advantage of this mechanism is that we can reference classes normally, and the scoping is handled “under the hood.”

In React, again, we need to use the Provider approach to make PostsStore dependency “transient”. We also import CSS styles, referenced as style and appStyle, to be able to use the classes from those CSS files in JSX.

Naturally, JSX feels much more JavaScript-y than Angular’s HTML templates, which can be a good or bad thing depending on your tastes. Instead of *ngFor directive, we use the map construct to iterate over posts.

Now, Angular might be the framework that touts TypeScript the most, but it’s actually JSX where TypeScript really shines. With the addition of CSS modules (imported above), it really turns your template coding into code completion zen. Every single thing is type-checked. Components, attributes, even CSS classes (appStyle.floatRight and style.messageCard, see below). And of course, the lean nature of JSX encourages splitting into components and fragments a bit more than Angular’s templates.

As you can see, the CSS Modules loader postfixes each CSS class with a random postfix, which guarantees uniqueness. A straightforward way to avoid conflicts. Classes are then referenced through the webpack imported objects. One possible drawback of this can be that you cannot just create a CSS with a class and augment it, as we did in the Angular example. On the other hand, this can be actually a good thing, because it forces you to encapsulate styles properly.

Summary: I personally like JSX a bit better that Angular templates, especially because of the code completion and type checking support. That really is a killer feature. Angular now has the AOT compiler, which also can spot a few things, code completion also works for about half of the stuff there, but it’s not nearly as complete as JSX/TypeScript.

GraphQL - Loading Data

So we’ve decided to use GraphQL to store data for this application. One of the easiest ways to create GraphQL back-end is to use some BaaS, like Graphcool. So that’s what we did. Basically, you just define models and attributes, and your CRUD is good to go.

Common Code

As some of the GraphQL-related code is 100% the same for both implementations, let’s not repeat it twice:

The GraphQL query is an RxJS observable, and we subscribe to it. It works a bit like a promise, but not quite, so we are out of luck using async/await. Of course, there’s still toPromise, but it does not seem to be the Angular way anyway. We set fetchPolicy: 'network-only' because in this case, we don’t want to cache the data, but refetch each time.

The React version is almost identical, but as the apolloClient here uses promises, we can take advantage of the async/await syntax. There are other approaches in React that just “tape” the GraphQL queries to higher order components, but it seemed to me as mixing together the data and presentation layer a tad too much.

Summary: The ideas of the RxJS subscribe vs. async/await are really quite the same.

The purpose of mutations is to create or update records. It’s therefore beneficial to declare some variables with the mutation because those are the way how to pass data into it. So we have name, title, and messagevariables, typed as a String, which we need to fill each time we call this mutation. The createPost function, again, is defined by Graphcool. We specify that the Post model’s keys will have values from out mutation variables, and also that we want just the id of the newly created Post to be sent in return.

So the formstate library works as follows: For each field of your form, you define a FieldState. The passed parameter is the initial value. The validators property takes a function, which returns “false” when the value is valid, and a validation message when the value is not valid. With the check and checkRequired helper functions, it can all look nicely declarative.

To have the validation for the whole form, it’s beneficial to also wrap those fields with a FormState instance, which then provides the aggregate validity.

To get bindable validation messages to the right place, we need to do some processing. This code is taken from the official documentation, with a few small changes. Basically, in FormService, the fields keep reference just to active errors, identified by validator name, so we need to manually pair the required messages to affected fields. This is not entirely a drawback; it, for example, lends itself more easily to internationalization.

The most important thing is to reference the formGroup we have created with the FormBuilder, which is the [formGroup]="postForm" assignment. Fields inside the form are bound to the form model through the formControlName property. Again, we disable the “Submit” button when the form is not valid. We also need to add the dirty check, because here, the non-dirty form can still be invalid. We want the initial state of the button to be “enabled” though.

Summary: This approach to forms in React and Angular is quite different on both validation and template fronts. The Angular approach involves a bit more “magic” instead of straightforward binding, but, on the other hand, is more complete and thorough.

Bundle size

Oh, one more thing. The production minified JS bundle sizes, with default settings from the application generators: notably Tree Shaking in React and AOT compilation in Angular.

Angular: 1200 KB

React: 300 KB

Well, not much surprise here. Angular has always been the bulkier one.

When using gzip, the sizes go down to 275kb and 127kb respectively.

Just keep in mind, this is basically all vendor libraries. The amount of actual application code is minimal by comparison, which is not the case in a real-world application. There, the ratio would be probably more like 1:2 than 1:4. Also, when you start including a lot of third-party libraries with React, the bundle size also tends to grow rather quickly.

Flexibility of Libraries vs. Robustness of Framework

So it seems that we have not been able (again!) to turn up a clear answer on whether Angular or React is better for web development.

It turns out that the development workflows in React and Angular can be very similar, depending on which libraries we chose to use React with. Then it’s a mainly a matter of personal preference.

If you like ready-made stacks, powerful dependency injection and plan to use some RxJS goodies, chose Angular.

If you like to tinker and build your stack yourself, you like the straightforwardness of JSX and prefer simpler computable properties, choose React/MobX.

Again, you can get the complete source code of the application from this article here and here.

Choose Your Programming Paradigm First

Programming with React/MobX is actually more similar to Angular than with React/Redux. There are some notable differences in templates and dependency management, but they have the same mutable/data binding paradigm.

React/Redux with its immutable/unidirectional paradigm is a completely different beast.

Don’t be fooled by the small footprint of the Redux library. It might be tiny, but it’s a framework nevertheless. Most of the Redux best practices today are focused on using redux-compatible libraries, like Redux Saga for async code and data fetching, Redux Form for form management, Reselect for memorized selectors (Redux’s computed values). and Recompose among others for more fine-grained lifecycle management. Also, there’s a shift in Redux community from Immutable.js to Ramda or lodash/fp, which work with plain JS objects instead of converting them.

A nice example of modern Redux is the well-known React Boilerplate. It’s a formidable development stack, but if you take a look at it, it is really very, very different from anything we have seen in this post so far.

I feel that Angular is getting a bit of unfair treatment from the more vocal part of JavaScript community. Many people who express dissatisfaction with it probably do not appreciate the immense shift that happened between the old AngularJS and today’s Angular. In my opinion, it’s a very clean and productive framework that would take the world by storm had it appeared 1-2 years earlier.

Still, Angular is gaining a solid foothold, especially in the corporate world, with big teams and needs for standardization and long-term support. Or to put it in another way, Angular is how Google engineers think web development should be done, if that still amounts to anything.

As for MobX, similar assessment applies. Really great, but underappreciated.

In conclusion: before choosing between React and Angular, choose your programming paradigm first.

mutable/data-binding or immutable/unidirectional, that… seems to be the real issue.

UNDERSTANDING THE BASICS

Is React a framework?

React is a JavaScript library for building user interfaces. It deals with the views and lets you choose the rest of your front-end architecture. However, a strong library ecosystem has developed around it, allowing you to build a complete framework around React by adding a few libraries to it.