I’ve written plenty of articles about Angular and React. Today, I want to go into six reasons why you would want to choose Angular over React. Most people who would object to this idea give a lot of examples as to why:

• Angular updates break your build
• It’s too hard to use
• Builds are too big and slow

And on and on, the whining goes. However, most of the issues people bring up are from Angular’s past rather than its present. In the early days when AngularJS was being put down in favor of Angular 2.0, these things were true. It’s also true that Google kinda messed up when they came up with the naming and branding for Angular. The truth is it had absolutely nothing to do with the old AngularJS framework. Angular was a new thing and completely rewritten for a new age of front-end development.

Even though Google had a shiny new framework with many neat features, there were plenty of hiccups at the start. It was kind of hard to get started with; trying to upgrade to the latest version broke so many things, there wasn’t as much support for it. And on and on. These were all good criticisms of Angular’s past. However, as I mentioned earlier, it’s turned into whining in today’s day and age.

That wraps up the history lesson; let’s jump right into it — 5 Reasons to choose Angular over React.

Standards

I often say that if you’ve seen one Angular project, you’ve seen every Angular project. The complete opposite can be said of React. If you’ve seen one React project, you’ve seen one React project. Angular has a set of standards that will carry over to every project you do. If you need to know where API calls are, they’re probably going to be in a service file. If you need to know where the main pages are, look at the routing file. There is a right and a wrong way to do things in Angular, which keeps projects from going off the rails.

Imagine you’ve got a team of developers who need to create and maintain an extensive web application. Angular would be the perfect choice for that. You save a whole lot of time because you don’t have to come up with and enforce a whole bunch of your own standards. You know every team member will be adhering to this standard. Since you’ve followed a standard, the application will be much easier to maintain later on.

If you have multiple web applications in your company, wouldn’t it be nice if they were all done in the same way? Wouldn’t it be great if every web application followed the same set of standards? Yes, yes, it would. It would make it effortless to move team members between projects. Imagine you have a project that needs to scale up, so you need extra help. With Angular, you could move a few developers from lower-priority projects, and they would instantly know exactly what to do. I’ve seen places that have multiple web applications that use React. It takes a while for a developer to go from one to the other because there are either no standards or significantly different standards. Using Angular, you could unify your front-end development in a way that takes almost no effort.

Extensibility

We talked about the Angular standard, and when you have something like that, you get extensibility. If you have a bunch of very similar web applications, it takes little effort to be able to share similar components across applications. Angular even makes it easy to be able to create component libraries or be able to manage a bunch of projects from a single repo using one codebase. There are even companies like Nrwl that make tools like Nx. What is Nx? Good question. Nx is built with the Angular model to be able to develop and maintain multiple full-stack applications from a single repo. If you went to the Nx website, you would have noticed you can use Angular, React, or even NodeJS. Why bring it up here? Because Nx uses the Angular standard as we talked about in the last section and gives it to you on any platform. It should come as no surprise that Nx is extremely easy to integrate with Angular. It takes more effort to do on React, especially if you have an existing React project. You may as well rewrite existing React projects, but with Angular, since the framework enforces your standards, you can easily integrate things like Nx with a simple command.

The Angular CLI

This is the answer to the question, “Why is Angular more extensive, and where do these standards come from?”. The CLI takes minutes, sometimes 30–40 minutes of works, and whittles it down to a few seconds. Let’s have a look at an example:

npm install --global @angular/cli && ng new my-app

Take those two commands, and you’ve got yourself a brand new Angular application. Everything is hooked up for you just to run npm run start. Creating and hooking up a new application takes seconds. What do you get with this out of the box?

• Build config
• Testing config
• Routing
• Lazy-loading

To name a few things. If you take a React application and try to get it to the same point with all this config and everything included, you could be looking at over an hour in some cases. If you’re a React expert, maybe it takes you 10–15 minutes to get something somewhat close to what you get here, but that’s a lot of effort for little in return. What if I want a new component?

ng generate component my-component

What if I want a new route?

ng generate module --routing my-page && ng generate component my-page

Now you got yourself a new route just like that. You may be saying, ok, but I don’t want to do all that typing. Well, there’s a shorthand for you lazy folks.

ng g c my-component

ng g m --routing my-page && ng g c my-page

I should also note, these commands don’t just create stuff; they also modify other things you may need to do. For example, in the command to create a new route, we enter two separate commands. When we generate a new component at the same path as the module, the CLI knows you’re trying to include that component inside that module, so it automatically adds it for you. This is where the enforcement of the standards comes in. When the CLI hooks your application up, it will always do it correctly. This helps to save you time and effort.

Ok, so you may be thinking, “ugh, CLI commands, what year is it?”. First off, don’t knock the CLI before you try it, and second, for those of you who don’t want to type CLI commands, there’s a GUI for you. Remember that company, Nrwl, that we talked about earlier? Yeah, them! They made a tool called the Angular Console a few years ago. Today, you can even install the Angular Console as part of Visual Studio code. Today it’s called the Nx Console, and you’re probably going, “Hey, I’ve heard that name before!”. Yep, that framework you can use for Angular, React, or a NodeJS project has a console that’s based around…. you guessed it, Angular. It gives you a nice easy GUI that helps you do things like create components, modules, services, etc.

Angular Schematics

So this is kind of part of the CLI but also not. Remember how we created an entire functional application in a few seconds with a single command? Well, Schematics does the same thing for third-party libraries you may want to add. Want to add Angular Material to your application?

ng add @angular/material

This command does a few things. First, it installs the libraries (duh), then it scaffolds them. What does that mean? Well, to fully install and use Angular Material, there are some changes you have to make to the main styles, there’s some config to be done, etc., using ng add takes all that effort away. If you’re used to using Angular material, you can do it manually in a few minutes, but using schematics only takes a few seconds.

Want a PWA?

ng add @angular/pwa

Want a Server Side Rendered (SSR) application?

ng add @angular/universal

These are some examples of really common libraries to use, but schematics can be used anywhere. I will also add, once you wait a few seconds for these commands to complete, ALL of the work you would typically do to integrate and hook everything up is taken care of for you. You can run this command and have a 100% functional PWA or SSR application a few seconds later. It takes out the guesswork, reduces mistakes, and gives you a much better experience using it. It’s that easy. You can also run these commands at any point in your development. If you have an existing Angular application and want to make it a PWA running, that command will make your existing app a PWA. You get the point. It’s dead simple to use and maintain.

If you try to build a React application and then you get a requirement to make it a PWA or use SSR, you’re looking at a very big problem in front of you. Since your React application didn’t follow a clear standard and you just kinda did whatever you thought would be best, you’ve got a rigid application that’s going to be harder to transform if need be. You have to do all the leg work yourself, and if you make any mistakes along the way, you have to go back and fix those. Even with new React projects, it can be a pain to integrate SSR or PWA capabilities.

Upgrading

Difficulty upgrading is one of the biggest gripes I hear, and it’s not reflective of what Angular is now. It’s effortless to upgrade to the latest version of Angular nowadays.

ng update @angular/core

Yep, that’s all you have to do. If you think that this looks similar to how Schematics is used, you’d be right. It works the same way. It will install the latest version of all the Angular core libraries and do any updates it can. For example, if there were an update to the way routing works, it would make those updates for you. If the CLI can’t do an update for you, it will tell you what file to update and what to do. What’s difficult about that? Not a darn thing, that’s what.

You can also use the ng update command to update ANY Angular library that uses Schematics. React really doesn’t have anything that even touches the capabilities of Schematics. With React, you’re up a creek without a paddle while us Angular folks are cruising by in a speed boat.

Build size and Runtime speed

This is one of the other most common things I hear from React people. The build is too big, and the runtime is slower. This used to be true, but not so much anymore. In the modern world, any production-ready Angular project and React project will be roughly the same size. For example, if you were to make the same application twice, once with React and again with Angular, the build would be comparable. If we’re talking about simple Hello World applications, yes, your React application will be smaller. But will it be faster? Not necessarily.

We talked about things that are given to you out of the box with Angular, and routing is one of them. Not just routing, you also get lazy-loading with that. What does lazy-loading do? Lazy-loading will delay the loading of certain components until they need to be used. So if you have a large build, you won’t render that whole build all at once. You’ll render the parts as the user requests them. This will reduce the amount of time it takes to load your application. I should mention that lazy-loading can be used in React, so it’s not unique to Angular. However, it’s so much easier to do in Angular. The effort will take to make your application lazy-loaded in Angular is so much less than in React. How is that so? Well, we talked about how Angular generates routing files for you with the --routing flag. Let’s have a look at one.

https://gist.github.com/shadow1349/df47f70a72f32907b3786197d3d94af2

So this is an example of a routing file that does not have lazy-loaded routes. Let’s say we wanted to lazy-load the main route. What change would we need to make?

{
    path: 'main',
    loadChildren: () => import('./main/main.module').then(mod => mod.MainModule)
}

That’s it! All you have to do is change the component attribute in the object to use loadChildren and then use the same path to import it. This is a super simple one-liner that could save you a lot of time when it comes to loading the application. Here’s the thing too, this applies to EVERY Angular project. Every straight Angular project will do routing like this. Once again, you don’t get the same thing with React. There are TONS of different routing libraries and even different strategies and implementations with the same routing library. I think this makes React far more frustrating to use and far more error-prone while you’re trying to decide what you need.

Another thing that modern Angular has given us is the Ivy Renderer. I’ve talked about Ivy before and linked to this article by the Nrwl folks before, but it is again.

[embed]https://blog.nrwl.io/understanding-angular-ivy-incremental-dom-and-virtual-dom-243be844bf36[/embed]

That article was written a while ago, and Ivy has only become more prevalent in the Angular ecosystem. With every release, it gets integrated deeper into the framework. If you didn’t read the article, I’ll give you a brief recap. Ivy compiles your components into a set of instructions. These instructions create DOM trees and update them in place. This means that the memory footprint will be proportional to the update being made. Another cool thing about Ivy is that the instructions are the rendering engine. This makes the rendering engine itself tree shakable. If the rendering engine doesn’t need things for your component, it will tree shake it out. By contrast, React uses the Virtual DOM as its rendering engine. The Virtual DOM is basically a memory hog. On every change and update, it will re-render whole DOM trees quite needlessly. This gives it a larger memory footprint, even for small changes. The Virtual DOM is not tree-shakable like Ivy. This means you always have to ship the whole Virtual DOM no matter what. This does not mean you cannot tree-shake your React application. I’m comparing RENDERING ENGINES so, please don’t comment telling me that React is tree shakable. I know that, but the Virtual DOM is not.

Wrapping it up

I’ve done Angular projects and React projects personally and professionally. I’ve worked by myself and as a part of a team, and I can tell you Angular makes your life 100 times more manageable in the long run. Having the CLI and Schematics there to automate most of the tedious tasks that come with adding things to your project makes it easier to focus on the development of your project. Having a right and wrong way to do things also makes your life easier because you don’t have to spend time coming up with standards for your project because they already exist. Hopefully, this has encouraged you to pick up Angular. Version 12 was released a few months ago, and it has some pretty cool changes to it.

If you’ve enjoyed this article I’d love for you to join my mailing list where I send out additional tips & tricks!

If you found this article helpful, interesting, or entertaining buy me a coffee to help me continue to put out content!