Angular and React - Why Use Angular to Build Applications ? The Biggest Reason is Not Technical

If you are choosing a framework for building you next application, there is one big reason why you might want to consider using Angular.

And that reason is not technical, it's not one single technical feature or even a set of features that really differentiates Angular.

And we will be covering that reason in this post, we will also be talking a bit about React, and why the way that we usually compare the two ecosystems does not help us to make a choice.

Table Of Contents

In this post we will talk about:

  • How to compare web frameworks ?
  • why are there so many comparisons between React and Angular, but its still so hard to get to a clear conclusion ?
  • can we compare frameworks on a higher level ?
  • Some comparison points between Angular and React, and why they usually don't help
  • Probably the biggest differentiating factor of Angular
  • is Angular really a web framework ? The current state of Angular and it's likely future
  • what type of applications and teams benefit the most from Angular ?
  • Conclusions and suggestions on how to decide

So, what is the biggest differentiating factor of Angular ? Let's start first by seeing how web frameworks are usually compared, and why that usually does not lead to a clear conclusion.

How to compare web frameworks ?

So why would we want to use Angular instead of other frameworks ? We can usually find comparisons between Angular and other frameworks based on technical aspects. These can include:

  • the way that the template system works
  • the way that change detection works
  • performance benchmarks
  • bundle size
  • and many other technical aspects

We will cover each of these, but with the main purpose of understanding why those comparisons wont help us decide. You might notice that although such comparisons are interesting to read, they usually don't end up giving us a clear choice.

We usually finish reading the comparison and end up even more confused and unable to decide than before. Why is that ?

Why are there so many comparisons between React and Angular, but its still so hard to decide ?

There are a couple of reasons for this.

One of the reasons is that we often say that React is only the V from the View in MVC, but clearly most comparisons do correctly compare the two things that can actually be compared: the Angular ecosystem versus the React+Redux/MobX extended React ecosystem as as whole, and not just the React library in isolation.

But there is a bigger reason

The biggest reason why we usually end up with no conclusion, is that the two extended framework ecosystems are actually roughly equivalent from a feature set perspective, so any technical comparison no matter how deep will not help - we are comparing internal implementation details of two nearly equivalent solutions

Both Angular 2 and React aim at solving essentially the same problems. They might use different internal technical approaches for solving those problems, but overall both the feature set and also the design patterns used in the two ecosystems overlap a lot.

Maybe the most noticeable design pattern that one ecosystem has that the other does not is Dependency Injection (more on this later).

Comparing Angular and React technically (although interesting), it's like comparing two equivalent cars by comparing the technology that they use in their internal combustion engines or in their spark plugs.

Although the technical comparison is interesting, we will probably end up deciding which car to buy based on the color.

Let's give a few examples of some frequent comparisons made about the two frameworks, and see why they don't usually lead to a meaningful conclusion that can help us decide which one to choose.

Comparison: The way that the Template system works

One of the things that gets compared a lot is the template system of both frameworks. Angular prefers an approach that favors a template that looks as close as possible to plain HTML:

And syntactically it even is HTML, although there are many Angular-specific elements in the template. And we can see why many people can say that its really not HTML anymore - but it still looks a lot like it even with all the multiple directives.

While on the other hand React uses JSX:

Although on a surface level these two mechanisms seem very different, we can make the argument that they are essentially equivalent, and that they are different implementations of the same set of patterns.

We can compare the two mechanisms very deeply from a technical perspective, but we would likely end up losing sight that they are roughly equivalent from a feature set perspective.

The two mechanisms are essentially an implementation of the same pattern. And what pattern is that ?

What are JSX and the Angular template mechanism trying to achieve ?

Understanding what patterns are being used and what problems are being solved is likely more helpful that knowing how those patterns are implemented internally.

Both Angular and React assume a clear separation between the Model and the View. In both frameworks there is a Model, which is a plain JavaScript object:

And there is a view which is a DOM representation of that model. And in both frameworks, if we provide a new version of the model there is an internal mechanism that will transform that model into a DOM representation of the data.

The browser rendering engine will then take that DOM data structure and paint it on the the screen.

The main feature of the View part of Angular and React

The key thing about this mechanism, is that in both frameworks this transformation between data and DOM is taken care for us automatically. We don't ever have to write this model-to-view generation code ourselves.

Both frameworks provides us a mechanism for transforming Model data into a View on the client side.

It's true that this transformation is done in different ways if we compare the two frameworks, but the most important thing is that this synchronization is done automatically and its designed to be transparent for application developers.

It's easy to forget that these are just two different implementations of the same pattern.

A more meaningful comparison would be to compare both Angular and React to previous frameworks where that the model was NOT a plain JavaScript object, but instead the Model had to be some special type of object and why that didn't work well.

Some differences between the two template mechanisms

Now there are differences between the two mechanisms, but lets see if digging into those differences would help us decide.

We could say that JSX generates virtual DOM, which is a plain JavaScript representation of the view that then is going to be applied to the real DOM by React itself in an optimized way.

While Angular takes the template and generates code that transforms the data to DOM directly (either at startup time or at build time via AOT), so there is no intermediate step to generate an intermediate view format - the virtual DOM representation of the view.

But where would that comparison leads us in terms of helping us decide which one to choose ?

Another example - Advantages of JSX

We could say that JSX is better, because it allows us to validate our templates at compile time. Note that this is the case because the current versions of IDEs support JSX very well out of the box. They compile JSX in the background and display any errors messages transparently.

But let's notice that the Angular AOT mechanism is designed to allow us to do the exact same thing, so eventually IDEs will catch up.

We can start to see why in-depth technical comparisons don't help as much as we thought

We could do other similar comparisons and we will give a couple of other common examples, but did you notice that by going too deep into the technical comparison of internal mechanisms, we are further and further from a decision ?

For example, concerning the template mechanism example above, from the point of view of an application developer the important part to be aware is that:

  • we can declare our view using something that resembles HTML
  • if we provide new data to the framework under the form of a plain JavaScript object, the framework will take care of displaying the data on the screen
  • this is transparent for us, it just works
  • we get error messages that identify where our view declaration is wrong

And all those things are available in both frameworks. There is no real fundamental difference between the Angular template mechanism and the React template mechanism other than its design philosophy, right ?

One system prefers to use HTML and extend it with a lot of extra features, the other prefers to replace HTML with something with a minimal API, making it clear that its just another way of writing your View in JavaScript directly - which the Angular template mechanism also is, its just that it feels a more like HTML, with the trade-off of a more extended API.

Another possible comparison - unidirectional data flow

A more helpful comparison between the two View generating mechanisms would be to talk about the Angular development mode that prevents the generated model-to-view synchronization code from updating the model.

Imagine how confusing it could be in certain cases if the data-to-view synchronization process could during that same process update the Model multiple times ?

This is a great feature, but is it a reason to choose one ecosystem over the other for a given project ? Probably not.

For example, AngularJs did not have this feature and there are a large number of projects that use it and they still work great.

Let's see another frequent comparison, and see if it helps make a decision.

Comparison: the way that change detection works

Another way that the two frameworks get usually compared is based on how its change detection mechanism works. Again this is an internal mechanism that implements a certain pattern.

The goal is to detect data changes automatically and decide if re-render is needed in a transparent way.

Both frameworks have built-in mechanisms for detecting when the data changes, and the goal is to only update the UI if the data changed.

The way that these internal mechanisms work is different, but the end goal is the same and these mechanisms are transparent from the point of view of the application developer - the default change detection mechanisms of each ecosystem simply just works out of the box.

An important feature of a change detection system

Now what is important in Angular and React is that the change detection mechanism is customizable. This is unlike the case of AngularJS (or Angular 1), where the change detection mechanism was not customizable out of the box - now that is a very important difference.

It means that teams that choose AngularJs are limited in the UI performance optimizations that they can make - this will be important for some applications if for example they have to run on constrained mobile devices.

In both Angular and React we can configure or customize the change detection mechanism so that we can decide to re-render a given component by simple reference comparison of its input data.

Comparing the two mechanisms is interesting, but on the process of comparing them we can easily lose sight that the two mechanisms are feature-wise roughly equivalent.

Let's give another common example of a comparison point that is usually made, and see if it helps to get to a decision.

Comparison: performance benchmarks

There are many performance comparisons between Angular and React.

And it's true the next probable implementation of React (React Fiber) will provide an internal scheduling engine that will allow the framework to give priority to animations over the rendering of data.

We can imagine that the zone micro task mechanism that Angular uses internally is probably designed from the beginning to allow something like that in a future evolution of the framework transparently ? Its too soon to tell.

But we can see one thing, comparing Angular and React performance-wise wont help us decide: they are both much faster than the vast majority of applications will likely ever need, and just keep getting faster.

Its like deciding between two cars based on their maximum speed - we will probably never need to go that fast, so we end up deciding based on other factors.

Let's talk about one last example that is often mentioned: bundle size.

About the bundle size comparison

The bundle size comparison is another comparison that is done often, but its less helpful to decide between frameworks than we could think. The average web page payload of the internet web pages that we surf every day (mobile included) has passed the 2M mark in 2015.

The average Javascript payload today on the web is well over 300K. And this does not include private dashboards, which we are all used to wait a few seconds while they load - for example Gmail:

The 300k plus of Javascript is for publicly available pages only

Bundle size and perspective

To get a better perspective on this issue, I invite you to take your favorite productivity tool and check its Javascript payload size using the Chrome Dev Tools or something else, and post it on the comments below.

You will be surprised to see how many of the tools you use every day have sometimes megabytes of Javascript. The bundle size is of course important, and its important to reduce it especially to get a better mobile experience.

But the bundle size its less useful as a comparison criteria than we might be led to believe.

If you are building a dashboard application for desktops or an enterprise application, the bundle size will likely not make any noticeable difference for your application.

Taking a web page made in Angular and rewriting in for example React is unlikely to give any noticeable difference in performance due to differences in bundle size.

Choosing between technical ecosystems based on the ever changing bundle size is comparable to choosing between two cars by comparing their weight - it helps less than what we could think to come up with a decision.

How to decide then ?

But if we are building an application we do need to take a decision. I am going to propose to decide based on non-technical factors, because essentially the two frameworks have an overlapping feature set and even use internally many of the same patterns.

To help decide, its probably better not to include Typescript into the discussion, because its a great choice also for React applications and it has JSX support directly at the level of the compiler itself, check for example the reactNamespace compiler flag.

Why choose Angular ?

The biggest reason to choose Angular or not might be philosophical in nature. The philosophical goal of the Angular ecosystem is to provide a set of tools and building blocks that used together can provide to developers a complete solution for building their application.

Those blocks although loosely coupled and still interchangeable with other alternatives are really designed from the ground up to be used together.

The router integrates with Angular Core, which integrates with Forms, the HTTP library is easily used with the other framework modules. Everything is glued together using the dependency injection system.

Everything has been designed from the beginning to be used together and furthermore all these modules although interchangeable are all tested together at Google across many internal projects.

Building blocks designed and tested together

Every version of Angular that is released to the outside world is being tested in probably a large number of internal applications of different sizes at Google and it has worked and it has been iterated upon and fixed multiple times.

React has also been tested at Facebook and Instagram of course. But the difference is that only a part of the modules used to build Facebook are available publicly. With Angular we know that we have all those blocks available and tested together by many teams of all sizes, and applications of all sizes.

The Angular building blocks are designed to build many different types of applications, from dashboards to CRUD apps to anything in between.

So if you like this idea of having a set of building blocks that where designed to be used together and tested all together, if you like this "Batteries Included" philosophy you will probably like Angular.

But there is nothing that you could do in Angular that you could not do in React and vice-versa - these are two essentially technical ecosystems that solve the same problems in different ways, and with different philosophies.

And different teams and organizations will likely have different needs.

About the current Angular ecosystem and the parts in progress

Please notice that many of the building blocks that we mentioned: Angular Core, the Router, the HTTP Module, the Forms Module: those actually lower-level building blocks for building an application, but even those blocks together don't provide a complete solution.

These are the main pieces of the puzzle, but they are the core building blocks that other higher level tools can be built upon.

One of those higher-level blocks that gets us closer to be able to build the full application is for example Angular Material. Angular Material is more than a widget library, it contains itself other foundational blocks that can be used to build other widget libraries on top of them - like for example solutions for UI Accessibility.

Angular Universal

Another higher-level block that leads us on the direction of being able to build a full application is Angular Universal. It essentially leverages the Dependency Injection system to plug-in a server side rendering layer that is not DOM-based.

The output of the rendering in Angular Universal is not DOM code, its HTML that gets sent over the wire.

In principle, we could even use the Universal HTTP module on the backend to do REST calls, take the dependency injection system and build parts of the server on top of Angular - this might be an interesting option sometime soon, have a look at a demo of the dependency injection container on the server.

Which leads us to a very interesting question:

Is Angular really a web framework ?

Because AngularJs is a web framework, and given the new name which is now simply Angular, it would be easy to conclude that Angular is also a web framework.

But it does not look like its the case, Angular looks more like a Full Stack development platform. With Angular and Typescript, we can see a future where only one team could do the UI part of the application, mobile development and in the future maybe even the server using one common set of opinionated tools - which is something that is really needed by a lot of teams and does not exist yet.

It is still today quite hard to build applications, even with all the technology available so a solution like that is really needed.

Conclusions and suggestions on how to decide

Technical comparisons between Angular and React are interesting but they probably wont help you decide, because both ecosystems have a roughly equivalent feature set.

So the biggest reason for choosing Angular for your project or not is one and the same: the "Batteries Included" philosophical design approach of the whole ecosystem, where everything just works and there are some clear choices already made.

If you like this philosophy you will take the most out of Angular, if you need full flexibility then you can still use Angular but wont reap as many benefits.

Depending on your team you probably want to use Angular or not depending on how much of the design decisions and choices of your application you prefer to take at the level of the team.

What type of applications and teams benefit the most from Angular ?

It's sometime said that Angular is only viable for large scale applications. But I would reason that smaller teams with less resources would benefit a lot from having a set of building blocks that where designed to be used together already.

Because otherwise someone in that small team will have to spend a lot of time choosing those building blocks, making experiments, taking the risk that they don't work well together and choosing a combination of technologies for which the developers in the team might not find much help for in programming forums.

There would likely be a lack of medium sized examples for that particular combination of technologies, which would make development more difficult for the team.

Is Angular only for single page applications ?

Another thing that is often mentioned is that Angular is only for single page applications, and not for incremental development of existing web applications.

It's important to realize that the Router module is optional, as well as other modules. We could take Angular Core only, and use it in their existing applications.

Angular Core is very close to be just the V in MVC - actually its essentially the V plus a dependency injection system that allows to glue other modules together.

So in that sense, technically Angular is as good of a choice for doing incremental improvements of existing applications as just about anything else - its just not the sweet spot for reaping the most benefits out of it, and there are other tools much simpler to use and learn for that use case.

Angular and enterprise teams

Enterprise teams would definitively benefit from Angular, but of course consumer large scale organizations as well. In the enterprise, its hard to convince management to let us spend more than a week on prototyping for a new project in most companies.

So having a well tested and well-integrated set of building blocks would be a big plus in that scenario - its probably easier to convince management to use Angular that probably any other equivalent solution.

Angular would be beneficial for applications and teams of all sizes: small, medium and large.


Angular and React are roughly equivalent in their feature set, so if you have to choose between both I would suggest to not invest a lot of time in in-depth technical comparisons.

This is because you will likely run out of time before seeing the bottom of that rabbit hole.

Instead I suggest to use mainly non-technical criteria: such as the availability of developers in your region if remote work is not an option, or how the overall ecosystem philosophy matches the development philosophy of your company and team.

I hope you enjoyed the post. What solution did your team choose and why, React, Angular, VueJs, something else ? Please let me know in the comments below.

Free Lessons Available on YouTube

I invite you to have a look at the Angular University Youtube channel, we publish about 25% to a third of our video tutorials there, new videos being published all the time.

Subscribe to get new video tutorials:

Other posts on Angular

If you enjoyed this post, have also a look also at other popular posts that you might find interesting: