84C69042-0571-4E30-A2A5-FF2385BABDF7@3xCreated with sketchtool.


React vs Angular – which one to choose?

A couple of years ago, the running joke in the web development community was that JavaScript had a new framework coming out every week.

The massive paradigm shift started by the likes of Node and Angular, however, has finally settled down. Instead of having to navigate a confusing landscape of new, untested software, developers now have plenty of mature, well-established solutions for many different problems.

Of course, as is always the case in the world of software, there’s an alternative to everything. Sometimes, feuds between two applications become so infamous, they gain historical relevance. A 1980s discussion between the relative merits of two text editors (Emacs and vim), for instance, is still raging on – thirty years later!

In fact, the React vs Angular debate has many parallels to the infamous Editor Wars. Ostensibly, both have the same use case: they are used to build interactive user interfaces within the browser. However, their respective approaches are very different from each other.

In this article, we’re going to take a closer look at what makes React and Angular different from each other.

Libraries versus frameworks

One of the most common points raised in the React vs Angular debate is the self-adorned descriptor each respective solution uses, and the implications it carries. React styles itself as a “library” – and like any other software library, it can be added to any project to accomplish a certain task. That means if you have an old codebase and want to spice it up with some modern UI goodness, React allows you to do that without having to commit to a full rewrite.

Angular, however, is a framework. You can’t add it to an existing project. If you want to take full advantage of its features, you have to start from scratch. In return, however, you get access to many more features than React offers.

This is the main difference: as a library, React focuses on doing one thing (creating user interfaces) and doing it well. Angular, as a full-blown MVC framework, comes with many additional features out of the box. Aside from allowing the programmer to take care of the UI, it offers an AJAX request handler, a router, tools for building forms, and more. That’s not to say you can’t do the same thing with React – independent libraries offering the same functionality exist and are just as good. The responsibility to pick the right one, however, lies in your hands.

Virtual versus regular DOM

The Document Object Model, or DOM, is an in-memory representation of every element on the webpage. In simple terms, it’s a tree structure in which every node represents a HTML element. It’s simple, and it works.

Or rather, it works well for the purpose it was designed for: displaying largely static HTML documents. Things get a little bit less comfortable once we start playing around with the DOM in Javascript.

Web interfaces are different than they were even a decade ago. Back then, completely refreshing a page to display new information wasn’t anything unusual. These days, we can spend hours on the same instance of Twitter or Facebook, never once having to refresh the page, because that feels “faster” to us. 

In order to accommodate this need for speed in users, web developers even started faking movement between different pages on a website. You may think that by clicking on a Twitter profile you’re taken to a completely different page – after all, the URL in your browser’s navigation bar changes and the page looks entirely differently! In fact, this approach (called, rather creatively, Single Page Application) is used by the majority of the most popular websites.

This is all possible thanks to DOM manipulation. Instead of requesting a complete page, we simply replace the DOM tree nodes with the relevant content pulled through AJAX requests. The problem with this method, unfortunately, is that it’s slow. Each manipulation requires the browser to go through the entire tree structure in order to find the relevant element (or elements). It’s not a huge problem – unless you’re on a low-powered mobile device or your UI needs to perform a lot of updates.

That’s where the virtual DOM approach comes in. A copy of the entire DOM tree is kept in memory as a JavaScript object. Every time a new manipulation is made, another copy is created, with the renderer comparing the two trees in order to find the differences between the two trees, which allows it to redraw the screen much more efficiently. It’s not unlike how Git works, really.

So, why are we talking about this? Simply put, this is React’s killer feature (and, arguably, its main advantage over Angular). Look up any React vs Angular discussion and it will be brought up: React comes with virtual DOM out of the box. Angular still uses regular DOM trees.

That’s not to say that Angular applications can’t be fast – they simply utilise different methods to achieve similar results. Angular has its own change detection algorithm which allows it to keep up with React, and even outrun it in certain edge cases. What’s more, the upcoming Ivy project promises even more performance gain due to its complete rewrite of the rendering pipeline.


Data binding: one-way, or two-way?

The concept of data binding is one of the more daunting ones to newcomers to frontend programming. Simply put, it refers to the way data is manipulated by the application. Data binding can either be one-way or two-way.

As you can probably guess, the React vs Angular war is also fought on this front. Angular has two-way data binding, React prefers one-way.

What does that mean in practice? Let’s look at a simple example: a text input box.

When creating a data-bound text input box through Angular, a “watcher” is attached to it. This watcher observes the text box and notifies the rest of the scope about any changes to its value – whether by the user in their browser, or by the application itself. The framework’s ability to detect changes made by the user is what makes this approach “two-way”.

In React, no native mechanism for detecting changes made by the user exists. You can still – pardon the pun – react to changes: simply add an onChange parameter to your input to call a JavaScript function to update what needs updating. If you’re an avid React user, but you miss two-way binding, worry not! Like with everything else, there’s a library for that: just look for “state management”.

In the end, the choice boils down to your personal preference in how you prefer handling user input.

The learning curve

Seeing as React and Angular are currently the two most popular solutions for frontend development, it would seem like a good idea to be familiar with at least one of them. Which one, though? Which one requires less time to learn?

Well, the answer really depends on your own ability to adapt and previous experience. React may be simpler at first – after all, it’s just another JavaScript library, not unlike jQuery. Sure, it requires you to write components in this weird syntax called JSX, but that’s not too much of a hassle. Plus, unlike Angular, everything’s in plain JavaScript – if you’re familiar with the language, you’re good to go.

Angular, on the other hand, requires you to get familiar with its entire ecosystem, starting with TypeScript – a statically-typed superset of Javascript. We will have an entire article about TypeScript and what advantages it offers over plain old JS out soon, but in the meantime, suffice it to say that it has a dedicated following. Once you get comfortable with TypeScript, the sheer amount of concepts new Angular users must learn (models, directives, dependency injection, et cetera) can be daunting at first. Unlike in its early days, however, the Angular support ecosystem has matured significantly. Well made tutorials, articles, videos, and books are available to help you get to get up and running in no time at all.

Personal preferences

The learning curve, however, may not be as much a factor as your own preference. This is what most of the React vs Angular fight boils down to, after all – personal preferences. 

While both solutions ostensibly solve the same problem, they go about it in wildly different ways. One is deceptively simple, yet powerful. The other is a hulking juggernaut of functionality.

…wait, are we still talking about Angular vs React, or Emacs vs Vim? 

The point is: while you will obviously choose one over the other, the best way to truly make sure which one is the right fit for you and your needs is to simply give them a try.

Create a simple project in either one – or both of them! Play around! Although you may have already developed an opinion after reading this article, you may surprise yourself by finding out one option felt better to use for you.

As for us, we decided to go with React for most of our web development needs. If you’d like to learn more about what made us go with it over the competition, read our previous blogpost about what makes web development with React awesome.

If you feel like using React technology is a good way to go for your project let us know on hello@appnroll.com !

We’d love to hear your thoughts!

Clutch logo 4.8stars

2020 Appnroll Sp. z o.o.

All rights reserved

Privacy policy
We are we rock IT
footer_svgCreated with Sketch.

Hey, our website uses cookies.
We hope you’re cool with that? Read more