Angular vs React

February 17, 2016

Choosing technologies to build your next app is always difficult. Weighing up the various pros and cons can seem daunting. Usually however, it comes down to a few fundamental concerns when making considerations around your technology choices.

This post will focus on the important concerns when trying to decide between two of the hottest web technologies to build your next HTML5 application and attempt to de-mystify this crucial decision. As there is abundance of comparative opinions and debate around the technical aspects of these two libraries, in this post we’ll focus more on the higher level considerations that would be considered important for any key decision makers about to embark on a new project.

We’ll cover this topic by looking at the following considerations:

  • How do the tools differ and what kind of projects do their strengths play to?
  • Resourcing — how much readily available experience is out there or how adaptable your existing team is.
  • Maturity/success — how long it has been let loose out in the wild, the success stories behind its use and typically nowadays with more focus on open source frameworks, the popularity and weight of the community around it (e.g. github stars)
  • Knowledge bases — does it explain itself well, is there plentiful documentation and guides that are kept up to date, training etc. (e.g. stack overflow questions)

First, a note on Angular 2. I’m aware that there are two versions of AngularJS and that Angular 2 fixes many of the problems of Angular 1.x, however I’m going to be looking at this from an architectural level.

What’s the difference and why do I care?

First up, technically speaking Angular is actually a framework whereas React is a library. The difference is like comparing the choice when buying a PC:

Choosing between Angular and React is like choosing between buying an off-the-shelf computer and building your own with off-the-shelf parts.”

Angular is opinionated, choosing Angular means conforming to its structure, its view on how your application should be architected and very often its choice of internal components such as routing, http services etc. With React you’re very much free to choose your own internal components and your own application architecture. This is why there are so many ‘starter kits’ that bundle react with a bunch of other off the shelf components and frameworks such as Flux, Reflux, Redux etc.

Depending on your project this is a blessing or a curse, with Angular you know that you can get off the ground quickly and other Angular developers are going to be able to join your team and contribute very quickly. With React you might have to spend time bringing new team members up to speed on whatever architecture decisions the project started with, and the choice of components is a minefield of immature components or incompatibilities.

On the flip side, you may find that being able to cherry pick the most optimal tools for your project is more important. If you’re building a product that has a long lifespan and is likely to grow in features and depth you don’t want to spend time wrestling with a component or architecture that doesn’t quite fit. Angular 1.x is very much a ‘one size fits all’ deal and if that size doesn’t quite fit you’re going to have a long painful problem on your hands. Angular 2.x however will modularise this choice so you can cherry pick the parts form a cohesive whole which you are guaranteed works well together.

Being quality focused in today’s climate where agile is becoming more popular, the ability to test code quickly and thoroughly depends heavily on what’s available. Although you can unit test successfully for both Angular and React through existing libraries like Jasmine and Karma, Angular does have a slight edge in what’s provided out the box in this area, which, if critical for your project, could be a game changer.

Aren’t all web developers just web developers?

Unsurprisingly, most developers will prefer one approach to the other. This is usually down to their own experience (people prefer stuff they know) but some devs have vocal opinions on which camp they fall into, this doesn’t mean that the platform they don’t choose is bad, but that they value one platforms perks over the others.

Despite there being an initial steep learning curve with Angular a lot of beginner developers have picked it because of its ‘batteries included’ approach — they have one framework, coded in one style with all the documentation in one place and a guarantee that all the components will play nice together. Over time these beginners become more rounded experts and the availability of Angular developers reflects this.

Angular has also been a ‘thing’ for a lot longer than React. This is shown in the number of people using it across the web and the number of people hiring positions in React. This is the case now, it may not be this way in future.

Maturity, stability and success

There’s no debate that Angular has been around for a lot longer than React, at least in version 1 form. This means the APIs used to build an application are far less prone to being changed as the platform develops, saving in developer overhead just keeping libraries up to date.

However, at this point I have to discuss Angular 2.x and how this fits into the picture.

Angular 2.x has been on the horizon for a very long time and is now approaching a state which could be considered stable enough to use on a commercial project. While the codebase just now is probably not stable, Angular 2 is the culmination of a long period of thought and careful architecture. Whereas Angular 1.x and React were built almost ‘as they went along’ Angular 2.x is a clean sheet approach taking all the learning and all the feedback from 1.x into account.

In contrast to Angular 1.x stability and dependability React is very much in flux, it’s still only on version 0.14.7 at time of writing and while it is owned by Facebook they are not averse to completely refactoring and changing the way internals work when they feel things could be improved. If you choose React you accept this occupational hazard and factor this overhead into your code development and maintenance plan.

While there is a vast wealth of information, tutorials, code examples and QA resources for both Angular and React, Angular developers more often than not find most problems they have during the development of a project have been asked and answered before. React projects due to their very nature tend to have more issues with edge cases, component compatibilities and API version changes.

So which do I chose?

Much like anything, pick the tool that fits the job. Angular can produce something very powerful very quickly whereas React gives you the flexibility to pick the architecture and collection of components that best suits your project outcomes.

  • Looking to build something quickly that can be picked up by new developers without long lead times? Pick Angular.
  • Building a long term project that requires a specific set of components and a componentized architecture? Pick React.
  • Prefer Angular? Pick Angular.
  • Prefer React? Pick React.
  • Interested in using a set of compatible components without being locked in and don’t mind using something in it’s early days? Investigate Angular 2.0.

Originally published at waracle.net on February 17, 2016.

Show your support

Clapping shows how much you appreciated Waracle’s story.