Back to blog home page

Angular 2 Vs. React

Posted by on Apr 21, 2016

In a previous blog post, we explored the differences between ReactJS and AngularJS, two popular front-end JavaScript frameworks. With the imminent release of Angular 2.0, we wanted to revisit this discussion and see how things have changed. Below we’ll look at how React and Angular 2.0 compare, and examine the pros and cons of each

A Quick ReactJS Refresher

If you’ll recall, ReactJS is a JavaScript web library created by Facebook with the primary goal of building performant and responsive user interfaces. React was built around one of the common problems with other JavaScript frameworks, namely working with large data sets. By making use of a virtual DOM, and by leveraging a patching method to re-render only the dirty portions of the DOM when a change occurs, React was able to achieve impressive speed improvements over frameworks like Angular 1.X, which treated the DOM in a more holistic manner.

Enhancements in Angular 2

Angular 2 adds many improvements to the innovations that were introduced in Angular 1. Firstly, Angular 2 has a much higher focus on creating reusable front-end components. While it was possible to do so using Angular 1, version 2 of the framework removes a lot of the barriers to reusability, such as reliance on $scope and on controllers. Directives were also vastly simplified, making Angular 2 code much more concise and readable when compared to Angular 1.x. Angular 2 is also intended to be used with TypeScript, removing a lot of the validation code necessary to enforce type safety. Coupled with many performance and framework improvements, Angular 2 manages to present almost an entirely new look at the declarative front-end framework pattern.

Some Caveats

It’s important to note from the get-go that in many ways comparing React to Angular (any version) is comparing apples to oranges. Angular is designed as a front-end framework, providing a full architecture for the client side of your application and allowing you to treat your client code as a robust suite of functionality. React is a library, and much less intrusive in terms of the features offered – it’s intended to be used as a part of a whole, rather than dictating your code’s structure. While this may seem to make a comparison between the two somewhat challenging to conduct, there are enough similarities between the two to drive a fruitful discussion on the advantages and disadvantages of each.

Architecture

As we mentioned above, React is a JavaScript library used to create responsive templates that can be quickly updated and rendered to the user. As such, there’s no real architectural focus in React – it is rather a tool to be used within the larger context of client-side code for an application.

Angular 2, on the other hand, builds upon the opinions introduced in Angular 1, and as a result crystallizes the framework’s view of what the “right way” of developing front-end code should look like. With the focus on components and type safety, Angular 2 allows you to focus on modularizing your code, building an object-oriented front end with a focus on reusability and encapsulation.

From this perspective, React and Angular 2 really don’t compare very strongly – React is the right choice if you’re looking for more flexibility in your code’s architecture, where with Angular 2 you are choosing to essentially adopt an architecture for your application’s front-end as a whole. Which pattern is “better” is ultimately, then, a matter of which fits your application’s design patterns better.

Templating

Both frameworks offer templating tools, but take vastly different approaches to how those are managed. React uses template objects built on top of JSX, which allows you to build templates inline and keep all of your template code in one place. Angular 2, on the other hand, still maintains physical separation between the JavaScript driving your application, and the HTML being rendered.

The focus on componentization, though, coupled with the use of TypeScript to build components as coherent functional units, allow you to write your templates in a more generic fashion that can be more reusable and flexible than was possible in Angular 1.x. Ultimately, once you’ve settled into the applicable pattern, the choice is one of aesthetics and underlying functionality – React templates will likely be more compact and quicker to render, but Angular 2 components will likely be more reusable and, through the ever-present two-way data binding, will be easier to manage as application objects.

Native Support

Angular 2 and React, having different underlying goals, understandably take very different looks at support for native device code when incorporated into mobile apps. The Angular 2 team has opted to focus on the framework itself, and left other vendors such as Ionic and NativeScript to handle translating that code into a format runnable on devices. The React ecosystem, on the other hand, has React Native – a framework designed to translate React code into a native application experience, achieving significant performance improvements over more traditional hybrid web apps.

Once again, choosing a “right” approach comes down to the goals of your application. If you’re looking for a blazing fast mobile app experience, React is the clear front runner. However, if you’re looking to maintain a componentized application architecture, and willing to sacrifice some performance to achieve a more consistent code structure, then combining Angular 2 with a framework like Ionic can provide you with all the flexibility you could desire.

Conclusion

The choice between Angular 2 and React comes down to a style preference. React, as a library focused on speed of rendering, is a useful tool for handling large and complex UI presentations in your client or native applications. Angular 2, on the other hand, takes a much broader view of the development process. As an opinionated framework, it’s looking to guide the way in which you build your apps, while also allowing you to create expressive and reusable UI experiences.

Ultimately, the decision will vary based upon the goals of your application, as well as the opinions of your development team. If you favor performance of large complex user interfaces, React is a good choice, while if you want to focus on enhancing the development process and your code’s architecture, Angular 2 will be the right way to go. As always, by understanding your problem space and the needs and desires of your development team, you ultimately won’t be able to make a wrong decision.

Before we end, a shameless plug for Backand. Our backend-as-a-service supports both Angular 2 and React. If you don’t have a free account yet, get one here.

  • Thanks so much for this! I really appreciate the effort to delineate between the two on their more fundamental differences as a library and framework and evaluate them 🙂

    I especially appreciate this:

    > React is a library, and much less intrusive in terms of the features offered – it’s intended to be used as a part of a whole, rather than dictating your code’s structure.

    Spot on!

    There are, however, a few things I wanted to push back on though and help clarify, especially since this went out in ng-newsletter and will potentially proliferate some inaccuracies.

    > React uses template objects built on top of JSX, which allows you to build templates inline and keep all of your template code in one place.
    This isn’t actually true .React doesn’t have “templates”, which are usually plain HTML strings with some sort of binding/interpolation syntax. The classic example is the handlebars syntax {{ foo.bar }}, which you see everywhere and isn’t a bad thing at all. However, JSX is a preprocessor that lets you create ReactElements (what DOM elements are to the DOM, but in React and w/ respect to the virtual DOM) more easily. So when you write out , you’re actually using syntactic sugar that will eventually become React.createElement(MyComponenyt, {}, ...children). There’s no templating language at work here, it’s all just regular old JavaScript.

    > Ultimately, once you’ve settled into the applicable pattern, the choice is one of aesthetics and underlying functionality – React templates will likely be more compact and quicker to render, but Angular 2 components will likely be more reusable and, through the ever-present two-way data binding, will be easier to manage as application objects.

    It would have been great to explore more of the differences between React and Angular components. One key difference is in composability; you can’t as easily express simultaneous “has a” and “is a” relationships with Angular components, which you can with React. In my experience, this makes React components *far* more reusable and decoupled.

    However, all-in-all, the component-driven design of both *in addition* to the inclusion of lifecycle methods makes reusability much higher than ng 1.x and a non-component-driven model(s).

    > React is a good choice, while if you want to focus on enhancing the development process and your code’s architecture, Angular 2 will be the right way to go.
    “Enhancing code architecture and development process” is a bit too tidy here, I think. Angular provides a set of opinions that have the potential to enhance your architecture, but that doesn’t also necessarily mean that you can’t or won’t be able to do that with React — it’s just that Angular has a set of opinions it enforces, while React has broader opinions (one-way data flow, immutability, &c.). https://github.com/reactjs/react-basic is a great overview of some of the core principles of/behind React.

    The mental model afforded by React coupled with one-way data flow actually makes architecting applications much easier, not more difficult. If your engineering team isn’t deeply familiar with broader design patterns or don’t have the resources/abilities to form your own opinions about an architecture, than picking up the opinions Angular gives you will help establish some structure. And I don’t mean this disparagingly — many companies prioritize speedy development over theoretically-elegant design. IMO, the latter yields the greatest long-term gains, but there’s always a need, well, for speed 🙂

    > However, if you’re looking to maintain a componentized application architecture, and willing to sacrifice some performance to achieve a more consistent code structure, then combining Angular 2 with a framework like Ionic can provide you with all the flexibility you could desire.
    2 things here. 1) React _is_ highly performant, but the consensus within the community and the team behind is that what in part enables that fast performance virtual DOM, is secondary to the simplicity of the design and the static mental model that it affords. It’s more about thinking well than being fast. 2) Angular 2 will be quite performant, especially as we take advantage of observables and the right sort of change detection use-cases that won’t force Angular to perform updates.

    I know that was long, but I just hoped to add some clarity to the some of the suppositions made about React and, indeed, Angular 2. Thanks!

    • Jeffiekins

      Thank you, Mark for putting some more “meat” on the bones. It was quite a good review, already; your additional comments kicked this page up a notch.

      • Certainly 🙂 I really like both frameworks, but am working on a book for Manning about React and so wanted to make sure things here get a well-rounded treatment

  • Stefan Aerts

    I don’t here any body speaking about Progressive Web Apps?
    Is react good for that? I only used Angular2, no Angular1, no React.
    I am not an expert in javascript,but i try to become one the last couple of months, i can handle it.
    I believe if you get used to writing typescript and the modular way in Angular2 (or maybe React also?),
    and you combine that with the usage of a service worker + webpack + firebase(hosting+ auth+ nosql database(push keys)).
    What else do we need? What else do you need with React to create such a progressive
    web/mobile application that can handle offline working and deploy on every platform easily based on a manifest file?
    Nativescript is not the way to go i think , i played with it a little bit, i don’t see much future in that.
    But making a progressive web app, thats the future i believe.