React vs Angular – which one to choose?
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.
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.
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 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?
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 email@example.com !
We’d love to hear your thoughts!