DEV Community 👩‍💻👨‍💻

Cover image for Angular is almost always better than React
Thomas Hansen
Thomas Hansen

Posted on • Updated on • Originally published at aista.com

Angular is almost always better than React

To understand the above sentence you'll have to read the whole article, and in fact you need to understand how most developers are working too. First of all, "most developers" are working for companies having software development as a secondary function. Some examples here are insurance companies, banks, hotels, hospitals, etc. These are companies who fundamentally don't care about software, but need software to optimise their processes and fulfil their primary objectives.

These companies typically have large turn over, and the average employee rarely works at the same company for more than 2 years. This implies that once every 6 to 12 months, a new developer starts working for the company, and need to understand the existing code base to become productive. In addition, 80% of these company's software projects are back office administration apps, not visible for customers. Examples are CRM systems, ERP systems, etc. With that in mind, let's go through how React and Angular is typically used at these companies.

How Angular is used

When you start out a new Angular project, the process is fairly straight forward. You make sure you've got the latest version of Angular, you install Material, and you start implementing your design. Each individual project therefor has a similar structure and largely uses the same components. This implies that every project becomes similar in structure, have similar components, and typically very similar markup and code - Assuming the Angular developer knows what he or she is doing. Maybe you'll need a handful of custom components for your project, but in general if you've seen one Angular project, you've seen "all" Angular projects.

How React is used

If you did the same exercise with React, you'd need to install dozens of components before you can even create a simple HTTP request and show a freakin' date picker. Every single time you install a new component, you have a myriad of choices, resulting in that you'd rarely find two different React projects using the same set of components and plugins. The structure of the project is much more left up to you as an individual developer in regards to how you want your code and project to be organised.

The problem

The above differences implies that for the most parts you can replace any Angular developer with any other Angular developer, and after an investigation phase of maybe half a week, your replacement is equally productive as the person who worked on the codebase originally. This results in an "agile organisation", able to easily move resources around between projects, without needing a longer learning period as resources are moved between projects.

With React the above is simply not true, because each React developer has his own favourite HTTP client, he's got his own favourite widget library, he's got his own favourite "whatever" library, resulting in that you'd rarely find two codebases with similarities at all.

So regardless of whether or not React is objectively "better" than Angular, it's already lost at this point, since resource management at a "React company" becomes much more rigid, and you're much more dependent upon individual resources, whom are more difficult to move around and replace if needed. You have created an unnecessary "dependency" from a business perspective, where you're much more dependent upon individual contributors, and you've got less flexibility as a company.

In addition to the above, most Angular projects ends up looking similar. For a company having dozens of in-house developed back office administration applications, this is an advantage, since back office workers used to one app, can easily understand all apps. With React this is simply not the case.

So really, which of these two frontend libraries/frameworks are better technically, is at this point completely irrelevant. As long as Angular performs at least somewhat "close" to React, the technology behind, and its ability to perform, is no longer important for you as a company.

NOW you can comment and disagree with me ... ;)

Edit - This is why we're exclusively using Angular at Aista.

Top comments (131)

Collapse
devdufutur profile image
Rudy Nappée

I disagree :D

A software project is not only about managing dependencies.

Furthermore, with current versions of React and vanilla es2021 you don't really need anything else. For xhr, fetch is sufficient. Let's say a CSS framework (as when you add angular material) if your company does't maintain one. Let's add a router and that's all !

Collapse
polterguy profile image
Thomas Hansen Author

And after you've done what you propose, your project probably ends up with a unique structure, implying there's a cognitively larger and steeper learning curve to understand it, then if you had chosen "the standard Angular solution". Henry Ford, arguably "the father" of automation was so obsessed with standardisation and time2market that he refused to paint his cars in any other colours then black. His argument was that black would dry in half the time as any other colours. If you need to spend only 30% additional time to maintain a React project than an Angular project, you're a "dead stick in the water" in the context I presume in the article's main text.

For a company with software development as a secondary function, technology is irrelevant. What is relevant though, is ease of use, and cost of maintenance. Angular wins hands down on both these two parameters ...

However, you're of course allowed to disagree ... :)

Collapse
joelbonetr profile image
JoelBonetR

Angular + Standards and then blaming React... I may lost something in the road but in React I use standard things except for the JSX while in Angular not even the templates are standard.

To drive a React project you don't even need people that "knows" React, people that knows HTML, CSS and JS is enough, understanding hooks (which are just HoF) and a couple of concepts of FP is enough to go ahead properly.

Can you please clarify?
Also I'd like to know where in this comparison Next, Vue and Svelte will sit in your opinion.

thank you

Thread Thread
jmfayard profile image
Jean-Michel Fayard 🇫🇷🇩🇪🇬🇧🇪🇸🇨🇴 • Edited on

The general principle is that the fewer decisions you have to make, the better it is.

Less is more because the paradox of choice makes you les productive and happy when you have too much of it.

If you have n binary decisions to take, that's a 2^n combinatory explosion.

Frameworks that have made by default a reasonable choice on most common topics are exponentially better than frameworks that gives you infinite flexibility.

For example git can do everything but following the GitHub programming workflow is much more efficient.

Can't speak about the specifics of JavaScript frameworks, not my field.

Thread Thread
polterguy profile image
Thomas Hansen Author • Edited on

in React I use standard things

Yup! So true. And others have "different standards" - Check out Jean-Michel's comment for further clarification ...

Also I'd like to know where in this comparison Next, Vue and Svelte will sit in your opinion

As a general rule of thumb, the less choice the better ...

Thread Thread
joelbonetr profile image
JoelBonetR • Edited on

@jmfayard is not a matter of coice because you like one thing more than the other.

We usually use a minimal approach with that.
Start a project with the less you need
i.e.
React, ReactDOM, Styled-Components (for styling) and Jest (for testing).

Then add things JUST when you need them, because you can't predict every need you'll face on the major part of projects, this way you avoid adding a bunch of things that you may or may not use.

Furthermore when you face a specific need you can choose the right lib (or custom implementation) that better suits this specific need and/or use-case.

There are 61702 packages tagged with "Angular" in NPM so I guess you'll need to bring this kind of decisions in Angular projects as well. It can be less amount of them or the same depending on the specific project and it will happen whenever Angular core API doesn't provide the exact tool to suit your needs.

Thread Thread
jmfayard profile image
Jean-Michel Fayard 🇫🇷🇩🇪🇬🇧🇪🇸🇨🇴

To clarify, are you saying that my principle doesn't apply in React vs Angular (possible, no opinion from my side) or are do you disagree with my principle (and why?).

Thread Thread
joelbonetr profile image
JoelBonetR • Edited on

I'm saying that to some extent you'll need to take decisions either be one or the other and that a minimalistic approach adds less burden to the project overall.

The decisions about which dependencies we should add to the project are made -in our case- by the TL (which is me in this case) regarding the technical nuances of the project, the environment, current needs, future roadmap and lib's dependencies while checking for security concerns (known bugs/security issues...).

Also we'll do a PoC with that hypothetical lib to ensure full compatibility and to define how it should be used to avoid weird implementations (which I saw whatever the language and tools are used).

Angular is not agnostic to this kind of issues ( first example I found ) thus my PoV is that it isn't that "good" and/or it doesn't release you much of this "burden".

Thread Thread
polterguy profile image
Thomas Hansen Author

Angular is (obviously!) not "perfect". Every time I need to upgrade something, I cringe from fear of breaking something. In comparison, NuGet (.Net) is a breeze compared to npm. However, you have to make a lot fewer choices when using Angular than React. Which is Jean-Michel's primary argument here, and also mine too, since fewer choices equals higher amount of standardisation, leading to more easy recognisability for others, etc, etc, etc - Basically a good spiral upwards ...

Thread Thread
joelbonetr profile image
JoelBonetR • Edited on

Yes it is like that in most cases, agree with that

My question though goes through a different path: Does fewer choices compensate the lack of being able to choose the right tool for each job?

I've worked on a couple of projects with Angular and it was fine but speaking of frameworks I do like Next more from the dev point of view (flexibility, fine-grain the results regarding the needs...).

In most companies we standarize some sort of libs to use and when something is more convenient to a project we simply add them as option, so you'll end up with few options (or just one) whenever you want to fill a need. On the other hand, JS core API is quite good for quickly overcoming needs without the need of libs.

This requires iterative checking and it's some burden but it's mostly decoupled of the devs day to day job (devs can suggest whatever they like, then everything is checked, including the license of course and added or not whether it's convenient).

By the way the "current" situation is a lack of available human resources aligned with a high demand and React is known by much more people (and is way easier to learn), which makes it a good choice.

On the other hand Google did deprecate AngularJS once ... vad vibes 😆 it was a good decision for several reasons back those days of Angular2 but the big G has a big graveyard of projects and I wouldn’t risk my neck for they not doing it again.

TLDR; tech decisions are not made only from the tech point of view.

Thread Thread
polterguy profile image
Thomas Hansen Author • Edited on

Does fewer choices compensate the lack of being able to choose the right tool for each job?

Wrong question, it's like asking if your car is married. The correct question is; "Does fewer choices leads to higher quality, better performance, and less resource requirements?" - At the end of the day, the only thing the companies I am referring to in the article care about is quality, time2market, and resource requirements.

tech decisions are not made only from the tech point of view

Correct, and once realising that, what the individual developers "feels is better", and or "wants to use" becomes irrelevant. Standardisations will force itself unto us, one way or another, and as it does, less power to the individual developer, and more power to the business decisions makers are a natural consequence. The only reason why business even cares about what devs "wants" is because they're terrified of devs quitting. That is a "local evolutionary optimum" destined to end, sooner and not later - Like it or not ...

Thread Thread
joelbonetr profile image
JoelBonetR • Edited on

Hmm nice PoV, I've not enough data to answer this, would need to check whether Angular projects have more quality than React ones through different metrics.

On performance and resource requirements I'm confident saying NO, Angular produces heavier applications due to the many features of this framework, that can burden projects, translating into a heavier application with slower performance. I've tested it a couple of times; I prefer the minimal approach I explained before just for that reason.

I definitely need to check the quality thingy, I'll come back if I get an answer on that.

Thread Thread
polterguy profile image
Thomas Hansen Author

On performance and resource requirements I'm confident saying NO, Angular produces heavier applications due to the many features of this framework, that can burden projects, translating into a heavier application with slower performance

If the app spend 0.4 seconds or 0.8 seconds to initially load is irrelevant. When I speak about resource requirements, I am talking about manpower required to maintain the project, not CPU and RAM. The latter is (for the most parts) no longer of much interest due to Moore's law ...

I definitely need to check the quality thingy, I'll come back if I get an answer on that

Quality is erronously perceived here I presume. "Quality" from a business perspective is rarely the same as quality from a software developer's perspective.

Quality from a business perspective might for instance imply;

  1. How many hours will it take to train my staff for the new app?
  2. How is the recognisability factor of the app, and what effect does it have on context switches as my back office workers are switching between apps?

Etc ...

Thread Thread
joelbonetr profile image
JoelBonetR
I am talking about manpower required to maintain the project, not CPU and RAM

My bad but still the answer is no, in my experience, the amount of devs you need depends on what the client wants, at what speed and with the budget.
Of course the answer is usually "Everything", "Now" and "as low as possible" respectivelly but I mean after a refinement and viewing it from a realistic point of view 😂

But if you want X and it requires 3 people in average it will be the same in Angular, React or whatever. The amount of people is mainly due to parallelization of tasks, on the other hand if we talk about delivery speed, developing in React is faster than using Angular (according to my experience as dev and as TL).

Quality from a business perspective might for instance imply; 1. How many hours will it take to train my staff for the new app? 2. How is the recognisability factor of the app, and what effect does it have on context switches as my back office workers are switching between apps?

Those seem design factors to me and not related with the tech stack used.
If you design a bad application it will be crap either be Angular, React, Vanilla JS, Java, PHP, C or whatever 😅

I was thinking more on "how many bugs appear into production", "time to solve them" and so on.

Thread Thread
polterguy profile image
Thomas Hansen Author

developing in React is faster than using Angular (according to my experience as dev and as TL)

I suspect that's a highly subjective observation. I would say the exact opposite. However, the point is that Angular projects have less differences, implying moving people around from one project to another, and/or hiring new devs is by the very definition of the term easier ...

Those seem design factors to me and not related with the tech stack used

Not correct. All Angular apps (assuming they're using Material) ends up more or less the same. For enterprise back office administration apps that is a good thing ...

If you design a bad application ...

True ... :)

Thread Thread
joelbonetr profile image
JoelBonetR • Edited on
Angular projects have less differences, implying moving people around from one project to another, and/or hiring new devs is by the very definition of the term easier

That's undoubtedly true.
The only showstopper is the popularity of the framework. From my closest friends 5 are able to work in React but only 1 coded with Angular, counting me that's (+1 on each) 6 vs 2 and more or less the same can be observed in new hires. For each 10 frontend devs, ~2 have used angular.

To some extent it also has been recently (since the beginning of the pandemic) influenced on juniors due to the rise of several tens of codecamps teaching MERN stack around the world (see the increase in npmtrends).

Not correct. All Angular apps (assuming they're using Material) ends up more or less the same...

My bad, I meant the product design.

If you decide to have a button here or there, to have a 4 step process to reach some functionality instead on optimizing it to 2 (if possible), how many features it will have, how they interact between each other, which are the user journeys... and this kind of things.

On the other hand if you use Material and don't put a hard work on editing/overriding Material components it will look pretty much "stock" (Using a pre-built theme). Changing the colors for the corporate ones in the config neither make it an application designed for the purpose so you end up using Sass API to style as much as you can and then Overriding styles (bad yada yada) because it wasn't enough.

Contrary to that if your app is meant to be used in-house (corporate) which is the target of every single Angular App I worked in, using Material is a straightforward way to deliver considerably faster and lowering the maintenance (if you are able to say "that's not possible" when the designers want something that's out of Material's capabilities).

Earlier I forgot to mention that

If the app spend 0.4 seconds or 0.8 seconds to initially load is irrelevant.

This is not applicable to public web apps. It has been well proved that lowering load and response times increases conversion rates. After checking, @angular/core alone weights 76.2 kB kb (minified and GZIPed) which is ~2 times React's entire weight (~40k).

Worth mention, If you need SEO I'd rather use Next JS (79.46 kB) for the SSR and SSG thingy and/or if I need to code a monolith so I've Node and React in the same place, lightweight and smooth (a good option for PWAs as well).

Thread Thread
polterguy profile image
Thomas Hansen Author

For each 10 frontend devs, ~2 have used angular

Is this true? I know React is more popular, but I suspect the above is slightly inflated ...

This is not applicable to public web apps

Of course not, my bad, I should have specified back office apps ...

Thread Thread
joelbonetr profile image
JoelBonetR

Well It was said by a colleague that usually handles tech interviews, I don't know if he was exaggerating or not and
if yes, to what extent 😂

Thread Thread
polterguy profile image
Thomas Hansen Author

The last figures I saw was that React was 1.5 times as popular as Angular. These numbers are a bit old, and I know React has a lot of momentum though, so things might have changed since then ...

Thank you :)

Thread Thread
joelbonetr profile image
JoelBonetR • Edited on

Speaking more seriously with the same guy that's what I can extract:

  • Depending on the niche you'll find more Angular than React devs.
  • Sometimes there's a company with projects already made with Angular so they want the same stack on following projects.
  • It's happening a new wave of React projects (the pandemic increase is being reflected into the market thus the amount of React projects and clients that prefer React are increasing as well).
  • This increase in React projects in big companies also retro-aliments the community (which makes sense).
  • Some of projects that require a framework are now being made with Next, which is chasing Angular.
  • Depending on the country you'll find more people that is used to Angular than React or vice-versa (so that's a point to check if you need new devs with Angular for any new project in Aista 😁).
polterguy profile image
Thomas Hansen Author

Bingo! Thank you. No further questions ... ^_^

Collapse
ch4nd4n profile image
Chandan Kumar

People inexperienced in driving large scale product implementations may not realise the point made here. For large enterprises software is a tool to derive profit. Angular definitely knocks out a lot of contentious issues. React is like core Java. Spoilt for choices. For enterprises what matters is what gets the job done. It doesn’t matter if it’s the best breed as long as it’s above average.

Thread Thread
polterguy profile image
Thomas Hansen Author

Word!

Collapse
devdufutur profile image
Rudy Nappée • Edited on

Well i'm not that sure... Angular is highly verbose, so you'll have to maintain a larger codebase. Besides, the heaviness of angular come with a cost when you have to update your dependencies every 6 months (even if it's adds consistent in dependency management). And have you include the cost of migrating from AngularJS to Angular2 when Google guys decided to break compatibility?

Thread Thread
polterguy profile image
Thomas Hansen Author

And have you include the cost of migrating from AngularJS to Angular2 when Google guys decided

That would be an argument for legacy code bases, not for decisions related to starting out a new project - However, yes, that was a nightmare ... :/

Collapse
leob profile image
leob

I clicked "like" but what you say isn't true ... well for a hobbyist it might be, but the author of the article talked about professional development at enterprises.

So, most serious apps need state management, so we'll probably add Redux (please don't get me started about cobbling together your own "poor man's Redux" with Context and Hooks). Then you find out that fetch is rather limited, so you add Axios. Once you find out that you keep repeating yourself writing Ajax calls and managing that, you'll add React Query and the like. And so on, and so forth.

The problem is really that React is not a framework, but a "library". But, something like Next.js is a framework (well more so than React is), so that would be an option.

Collapse
devdufutur profile image
Rudy Nappée

So why did you like if you disagree ? 😅

Next.js does not reduce that much the number of dependencies, excepts for routing.

In my experience, you don't need redux in 95% of projets. Axios and React Query as well (the only missing feature in fetch would be interceptors, but it's easily overcome). But the main point is even if core angular dependencies are consistent in term of versionning, you still need to add them (@angular/router, rxjs, @angular/material)... So is there so much difference ?

Thread Thread
leob profile image
leob • Edited on

Well I can see that you made an effort to formulate a coherent argument, so that's why I put a like, not because I completely agree :)

I don't know what kind of projects you have in mind, but in 95% of serious apps you do need some sort of "global" state management for the whole app, i.e. above the component level. Whether you do that with Redux or in another way is a different discussion (don't tell me that you don't need Redux coz you'll do it with Context and Hooks, lol) - the point is you'll need some sort of state management other than component level "setState".

Axios, yes okay, you can emulate all of its features with fetch, so if you want to be super minimal on bundle size you can skip Axios.

But state management, in my experience you'll need it not in 5% of the cases but in 95% of the cases. No idea where the Redux hate comes from, TBH.

But what exactly was the debate about again?

Thread Thread
polterguy profile image
Thomas Hansen Author

But what exactly was the debate about again?

ROFLMAO :D

Thread Thread
devdufutur profile image
Rudy Nappée

I was just joking don't worry.

Global state is kind of a antipattern in React, excepts for user preferences or authorization it should be use with extreme care. I saw many projects starting with redux for no specific reasons which involve overengineering and maintenance issues.

Not sure what was the debate 😅

Thread Thread
leob profile image
leob

That's good, I like jokes as well :)

I agree that you shouldn't start with Redux per se, but if you do some prior analysis then in most cases it's simple to find out whether or not your project will benefit from global state management.

But, what's funny about us having this debate is that we're lending credibility to the author's narrative that Angular is "better" - because, apparently, in the Angular world they don't need to have these kind of debates :)

Thread Thread
devdufutur profile image
Rudy Nappée

Sure, damn angular users 😁

Collapse
neo7bf profile image
neo7bf

I'm a fun of React but the fact that you take theese decisions is a confirmation of what said in the article. To change this fact an official voice should collect all standards "the-facto" and promove an official way of how to do apps with React. For example Next.js It moves in this direction.

Collapse
leo_calvin profile image
leo calvin

Exactly

Collapse
leob profile image
leob

I think you made a very convincing argument for the limited and specialized use case that you're describing (building internal apps at a company/enterprise) - as soon as this company is building a public facing app, then the discussion already changes.

P.S. the whole point is that Angular is a framework, React is a library, so you could say it's bit of an apples-to-oranges - comparison - a more apples-to-apples comparison would probably be Angular versus Next.js?

Collapse
polterguy profile image
Thomas Hansen Author • Edited on

I think you made a very convincing argument for the limited and specialized use case that you're describing (building internal apps at a company/enterprise)

Yes, bit it's the by far most common use case I have seen in my life. And 80% of the world's software developers are in similar positions as me, so instead of claiming it's the "special use case", I'd say it's the "general rule of thumb".

as soon as this company is building a public facing app, then the discussion already changes

That's true. I'm not entirely convinced the argument changes enough to justify React, but here I'm on slightly more shaky grounds I admit ...

As to apples versus oranges? Devs typically choose between two things when they start out new projects; React and Angular. Even though Angular is a framework and React a library, I don't really agree here. These are two different competing technologies where users choose one of them when starting out new projects.

Collapse
leob profile image
leob

You made a (very) convincing argument for the use case that you state, however the title of your post ("Angular is almost always better than React") is of course a little bit click bait, lol ... it should have read "Angular is almost always better than React for building internal enterprise apps", but well that's not going to generate the clicks & views and comments that it generated right now, so I don't blame you haha ;)

What has bugged me about React for a long time (so I'll give you that as well, no doubts there) is that React is definitely NOT "batteries included", and that everyone seems to be endlessly reinventing the wheel.

Case in point: we have Redux as a mature state management solution, but no, we get dozens of articles how it's "better" to build your own Redux using Context and Hooks (hint: false claim, it isn't "better" at all).

That's very telling when it comes to a certain mindset, and at some point it induced huge "React fatigue" in me. I'm now back to being interested again in React, now that it has matured and there's a bit more of "de facto" standards, but please React people, can we stop reinventing the friggin' wheel? It's a waste of time.

P.S. something like Next.js might be a candidate for the 'framework' that we need - another good option is to use Redux Toolkit - I think if you combine these parts then you have a pretty complete and mature solution which could compete with Angular:

  • Typescript
  • React Router v6
  • Redux Toolkit with RTK Query

Just declare it "the React standard" and get it over with, lol. You need SSR then choose Next.js, and again done & dusted.

Thread Thread
polterguy profile image
Thomas Hansen Author

but well that's not going to generate the clicks & views and comments that it generated right now, so I don't blame you haha

Shhh ... ;)

Sure, the header could have been more correct, but it's not incorrect either ...

Just declare it "the React standard" and get it over with, lol

I suspect that train has left the station, but I might be wrong ...

Collapse
shmulyeng profile image
Shmuly Engelman

This article is pretty much an exact summary of why I chose angular as the platform of choice for the company I work for. People always bring up the fact that other platforms provide better performance than angular. In many cases this is true. But companies that use software in support of their main business, don't always need the increased performance. Human resources are usually more expensive than losing out on other performance increases.

Collapse
polterguy profile image
Thomas Hansen Author

Thank you Shmuly :)

This is the exact reason why we choose Angular as our primary goto tool ourselves, and also produces Angular code in our data grid generator ...

Collapse
alohci profile image
Nicholas Stimpson

The question that is nagging away at me is are you measuring the right human resources? In internal applications, the cost of the human resources of the developers is (hopefully) dwarfed by the cost of the human resources of the users. So if the application is markedly slower in use, or clunkier because a component had to be written in house, rather than taken from a pre-written library, in a way that absorbs more of the users time, that could work out far more important.

I've never coded in either React or Angular, so have no horse in the race, and don't know whether there is significant difference in the proportion of the application that would typically have to be written in house.

Thread Thread
polterguy profile image
Thomas Hansen Author

In internal applications, the cost of the human resources of the developers is (hopefully) dwarfed by the cost of the human resources of the users

Actually, many of these enterprise in-house applications are typically used by a handful of people, so the word "dwarfed" is probably slightly exaggerating, but obviously yes, that's a valid point, and I touch upon that in other comments here, where I say that "the fact that all Angular apps typically ends up similarly in UI and UX is an advantage since once the user has learned one app, the user has effectively learned all apps, and the context switch requirements between different apps created in Angular is hence smaller than the context switch requirements if these apps were created in React" (roughly ...)

because a component had to be written in house

I suspect this is a problem that's not more frequently happening in Angular than React.

Collapse
ethanstandel profile image
Ethan Standel • Edited on

I worked in Angular for four years before moving over to React. What I found was a breath of fresh air. React is not perfect, but Angular is an inherently hazardous architecture to lean into.

The main feature of Angular that you lean into is standardized ecosystems. I have no qualms with standardized ecosystems, but it's everything else about Angular that make it a bad technology and that nullify the advantages of standardized ecosystems.

The core problem is that Angular requires so much boiler plate code to maintain it's standardized model that sending a seasoned Angular developer out to understand a code base just takes more time than sending out a seasoned React developer to a modern React code base.

First reason: simple use cases require obtuse tooling that average Angular developers aren't familiar with. In general the component API has several different flows for getting and managing data and events. If you told an Angular developer to make you a button component, 9/10 times your developer would make you a standard @Component which forwards an onClick event from the template directly. This means it inherently fails to scale. Rather than creating a button selector like my-button, they were supposed to create a selector button[my-button] as is done in Angular Material. But why use that, when @Directives exist? Because you can't add style sheets and templates to a @Directive. Then why use @Directives at all? Oh because you can't put more than one type of this @Component selector on an element. So if your team wants a standardized button component that wraps the @Angular/material button... well that's not really something you can do in a scalable way.

React doesn't have these arbitrary rules and different types of APIs. A fully featured and scalable button component uses the same component API because props (React's version of @Input/@Output) are just an object, so you can just use JavaScript spread (...) syntax. Angular hides this complexity from developers, behind rarely used APIs of the framework.

Second reason: performance. React performance is nothing to write home about. In fact, if performance is a primary requirement for you then I recommend you look to other options like SolidJS. But what I can say for React is that state updates in React are intentional and puts the developer in control. When you need to update a piece of state you run some kind of setState update. Angular on the other hand is an absolute mess of automated internal event handlers and proxies. The ZoneJS library is itself a nightmare, not even to mention NgZone that maps it to Angular. I've never worked on an Angular application that didn't scale to the point of having to have it's change detection turned off. And you'll notice this happens with every major library. This is indicative of the authors of Angular knowing it's bad and having to write special use cases to make Angular work at scale. This is not standardization, it is the opposite of standardization.

I can talk all day about why Angular is bad but I will leave it at this third reason: Google knows Angular is bad. Google has made two other frameworks which follow Reacts patterns exactly: Flutter follows the same patterns as pre-React@16 class components where you have a render method on each class that returns an object tree and rerenders are managed by a state update method. And then there's Jetpack Compose which is so outright similar to modern React that here's a 1:1 mapping of almost all React patterns as they are implemented in Compose. Google could have leaned into a technology like Angular + NativeScript for mobile development, but they made a choice not to do that.

React has 11m installs this time last year on NPM, now 16m, 45% growth. Vue 2.4m to 3.3m, 37% growth. Svelte 170k to 340k, 100% growth. SolidJS 15k to 37k, 146% growth. Angular 2.5m to 2.9m, 16% growth. In no way should popularity dictate tech decisions but looking at popularity is indicative of looking at overall tech decisions made in the industry. It's obvious that the tech industry is choosing Angular less often year over year and it's worth considering the reasons behind that.

Collapse
polterguy profile image
Thomas Hansen Author • Edited on

Great points. One detail though; JavaScript is the by far worst programming language in the world, still the by far most popular language. If popularity was a measure of quality, we’d still be coding VB6 using WinForms … 😉

One more detail; If you’re creating your own button in Angular, you’re probably doing something wrong … 😉

Collapse
jmfayard profile image
Jean-Michel Fayard 🇫🇷🇩🇪🇬🇧🇪🇸🇨🇴

Not a front end dev or a project manager but I completely agree.

Less is more and people should Google "the paradox of choice".

Collapse
polterguy profile image
Thomas Hansen Author

I once heard a scientist more or less explain why Americans are 60% over weight, which is because as you go to SafeWay, you get 176 choices of salat dressing ... ;)

Collapse
devdufutur profile image
Rudy Nappée • Edited on

You could become fat easily when each time you go for a salad, the waiter forces you to order an entree, a dessert, some cheese and a glass of wine

(Just trolling, you got my point 😁)

Thread Thread
polterguy profile image
Thomas Hansen Author

Hahaha :LD

Thread Thread
jmfayard profile image
Jean-Michel Fayard 🇫🇷🇩🇪🇬🇧🇪🇸🇨🇴 • Edited on

Drinking red wine is good for your health.
Ok, this has been debunked on the scientific level,
on the ground that the main factor is that France has universal healthcare and the US doesn't.
But I choose to belive it anyway :)

Thread Thread
polterguy profile image
Thomas Hansen Author

But I choose to belive it anyway :)

ROFLMAO :D

Me too ...!! ^_^

Collapse
seanblonien profile image
Sean Blonien

Agreed - so choose a React framework that makes more prescriptive choices for you!

Collapse
bofcarbon1 profile image
Brian Quinn • Edited on

Angular is a superior option. The React option started with resistance on the part of facebook and continues to tear down and recreate the code approach. Artificial inclusion of state management, reducers and premature browser rendering all part of problems with React. Add to the recent rewrite in React Hooks which forces you to throw away entire code bases and start over. React is a hot mess.

Collapse
polterguy profile image
Thomas Hansen Author

Thank you, I didn't know about these problems, I'm just another Angular dev tired of hearing "React is much better than Angular" ... :/

Collapse
seanblonien profile image
Sean Blonien

Artificial inclusion of state management

Angular has state managemnet too. What are you saying here?

reducers

Optional feature. I've built production grade eCommerce complicated apps that never once touched a reducer and it scaled very well.

Add to the recent rewrite in React Hooks which forces you to throw away entire code base

Hmm, sounds just like AngularJS. I agree it's bad, and yet it's a problem all of web technology experiences, most importantly Angular itself.

Collapse
hayk94 profile image
Hayk Safaryan

As someone who is more of a React dev but also has some experience with Angular and others I agree with your point. Lack of standards and flexibility is a double-edged sword for react apps.

With React the above is simply not true, because each React developer has his own favourite HTTP client, he's got his own favourite widget library, he's got his own favourite "whatever" library, resulting in that you'd rarely find two codebases with similarities at all.

It gets even worse when instead of using some popular library for some common problem they go with “we will make our own solution”. And this “solution” at least in most cases I’ve seen after a couple years later turns into “there is some shitty, undocumented piece of code some guys that don’t work here anymore wrote and we can’t just refactor it because all of the project is dependent on it and if we change something in there, many unforeseen bugs may come up”. So new functionality is being piled up on that as they go making it even worse.

Now that being said I’ve also seen similar situations in Angular projects I worked on (which aren’t that many) where the devs have just completely missed the point of some pattern and butchered it in such a way it’s just unbelievable. But of course I’m sure there are good Angular projects and developers.

Collapse
silverium profile image
Soldeplata Saketos

My experience in all Angular or AngularJs projects: developers didn't know the standards + didn't "have time for search for the patterns of Angular". Outcome: crazy custom convoluted patterns and solutions doing what Angular already does (with their standards), so they ended up under using Angular. With workarounds including creation of handful useless files, like empty services, providers, views, controllers or whatever Angular likes to call them.

My feeling: Angular is a crap that forces devs to create 25 files for a "hello new page with i18n and infinite scroller and a custom layout".

But of course, that was my experience with lousy Angular developers. Because they were not Angular developers but "full stack developers" with PHP or .Net background (No JS background, of course... so you can expect a lot of "class" objects). Angular is as bad as the developers implementing it.

The difference with React, in my opinion, is that React is a library that extends JS with HTML (JSX) and extends JS with CSSinJS (Styled-Components). So at the end of the day I become a better JS developer (with functional programming approach, btw, because JS is not good for OOP and "this" and "class"), which will improve my coding skills.

Angular on the other hand, extends HTML with logic tricks (ng-for) which do "black magic behind the scenes" and devs can get better in Angular, but not necessarily better JS programmers (or Engineers).

I honestly prefer to become a good JavaScript developer, which will also help me to be a better programmer in any language (FE or BE), than being a good Angular developer.

Collapse
polterguy profile image
Thomas Hansen Author

Thank you 😊

Collapse
simontol profile image
Simone Tolotti

Anyone who disagrees here has never maintained a big project written in React by someone else, and on which, over time, several developers have succeeded.

Collapse
polterguy profile image
Thomas Hansen Author

Word! I'd like to repeat myself here ...

If your code makes me think, there's something wrong with it ... ;)

Collapse
darkeye123 profile image
Matej Leško

Now I agree with this on some level. But it is worth to mention that React is not a framework. It is a library. Sooo, you know. You can't really compare these two.

Your argument is basically comparison of x custom react based self-made 'frameworks' against angular framework.

Where I agree - every React based project will be different out there in the wild. None of these are same. Thus initial burden to get into development is for juniors higher and you consume more manpower to watch their steps. It is usually not so steep learning curve as with whole framework.

Initial investment to Angular (or different framework, it doesn't matter) is initially higher - but it will make you more productive for the long run --> given that there is already decided flow in majority of the projects

Nevertheless - it is worth to know multiple approaches and technologies. So in the end it really is about how you enjoy your work and how much you are paid.

Collapse
joelbonetr profile image
JoelBonetR • Edited on

And a Scania Trailer Truck is better than a Mercedes-Benz CLA 220.
It has more horsepower, much higher load capacity, the cabin should be more comfortable, you've more visibility while driving... but is slower.

React and Angular are joining in a single need which is building user interfaces.
Angular provides a huge toolkit to tackle other needs while React doesn't.

If you need anything that's not covered by Angular API (mostly any middle to big project) then you need to come up with something custom which will allegedly differ from any other angular project. 🤷🏼‍♂️

I get your point though, the complexity is the same it's just that in an Angular project it's already defined how to deal with a good part of it through the framework API while in react it needs to be defined each time. That also opens the door to a more fine-grained result regarding the project needs on the other hand.

Collapse
polterguy profile image
Thomas Hansen Author • Edited on

This article was written for project managers, and developers just starting out learning software development. And as the title says; "Angular is almost always better than React" - Which I still stand by, given the context the article describes ...

Notice the word "always" and the article's context ... ;)

Edit - However, when that's said, a Volvo is almost always better than a Ferrari (for the same reasons) ...

Collapse
santunu23 profile image
Joy

I completely agree with you.Angular is a complete framework for software development. And it’s pretty straight forward.I have been using Angular from last 3 years for all of my software development projects.Frankly speeking I have never thought to replace Angular with any other framework or library(like reactjs) because what ever my requirement I can easily fullfill with the Angular.

Collapse
thiguet profile image
Thiguet

Companies have software as a mean not an end. So they might take decisions like:

  • Business : I need an app.
  • Dev: I can do one in React.
  • Business: Let's go and please add these 1000 features.

Some projects doesn't follow good software design principles in their start, which could help create a set of candidates and take out the ones that doesn't make sense. I mean more like having diagrams and extension points, rather than having all the scope at first. It should be scalable in this scenarios.

I've had the opportunity to work at a company that created its own framework, maintained it and we couldn't move forward with it. It was written in Angular with the idea of forcing common practices to ensure interns wouldn't f*** things up.

You take out all of the "dev power", and trust your designs and code to a structure too simple to do what we needed.

When you block others to use different technologies you start to dive in you own code as a company and you have to fix the framework bugs, which I can tell that it takes way more time, than redoing my simple page in React as an example.

We shouldn't put the blame of bad project design choices in technologies.

It is not fair.

They all can coexist even in a company.

It takes one good Software Engineer to do it.

Collapse
polterguy profile image
Thomas Hansen Author

Word! However, this is a different debate ...

Collapse
danielkucal profile image
Daniel Kucal • Edited on

Totally agree, every React app is different on the architecture level, so you need weeks to get familiar with all that stuff. With Angular, you just jump into the project and start coding. But the worst part of it is keeping everything up-to-date with React, because you're way more dependant on 3rd party libraries, which need to be updated and compatible with each other.
Oh, right, and TypeScript. With React you don't have the guarantee that the project is using it.

Collapse
ozzythegiant profile image
Oziel Perez

I don't like either of them. React used to be great when we used classes. Now everyone has to use hooks for everything and treats functions like classes when we should have just stuck to that to begin with. Absolute mess of a framework. Angular has excellent organization but I have several gripes: file hell, too many directives, bloated bundles, and webpack is awful (wish you would migrate to vite instead). I use Vue and even that's starting to suck becase Vue 3 just wants to copy react with Composition API. If I'm gonna be writing declarative code, I might as well just use Svelte; much cleaner, very light weight and simple to use

Collapse
polterguy profile image
Thomas Hansen Author

I have never really looked at Vue or Svelte, and they might be the holy grail of SPAs for all I know. However, this article wasn't about what me and you "like", it was about the sensible decision for companies when starting out new projects.

Collapse
leolozes profile image
LeoLozes

Any serious company would set up a list of usable libraries, and probably their own component library for their projects and a set of rules and guidelines on how and where to use them. If every developer can choose their libraries, dependencies and coding style, any project in any language would be a maintenance disaster.
You may have had a bad experience, but you're generalizing way too much. In a very poorly managed software department, maybe you've got a point, but then again choosing a more generic framework will only fix so much. The real problem is elsewhere.

Collapse
polterguy profile image
Thomas Hansen Author

The real problem is elsewhere

That's true, and the problem I am illustrating is only a symptom, but that's the subject for another article ...

Collapse
aldine_ruturi profile image
Aldine Ruturi

I agree with you, I've faced similar problems with react and ended up settling on angular for exactly the same merits above. Developers naturally focus on the tools they like, how they perform etc but ultimately the bottom line is the business which needs to exist long after developer x or y has left. Less is indeed more

Collapse
almostconverge profile image
Peter Ellis • Edited on

I can see where you're coming from but the difference really just boils down to this: React is essentially a templating library while Angular is a full-on framework.

Saying one is better than the other is not really a comparison of their respective merits in areas they both cover, it's just arguing that one covering a lot more is an inherently good thing.

And in the right context (which this post does provide) that's a very persuasive argument. In other contexts the flexibility of choice may be preferable, and for me that's fine too.

If there is one thing we may all be able to agree on is that we as a profession tend to over-emphasise the value of flexibility and choice, while understate the value of familiarity, even when it comes at the cost of flexibility.

Thank you for the post, Thomas!

P.s.: For the record, having worked with both, I'd personally choose React any day of the week, it's so much closer to the way my mind works. Which is another factor that may be worth considering, as I've also seen people "get" Angular easily and struggle (relatively speaking) with React.

Collapse
polterguy profile image
Thomas Hansen Author

If there is one thing we may all be able to agree on is that we as a profession tend to over-emphasise the value of flexibility and choice

Bingo! Thx Peter :)

Collapse
hadley8899 profile image
Ryan Hadley

I agree. Ive found with multiple Devs, react codebases become a mess. With angular they tend to stay nice and straight. Albeit some very large components appear sometimes. As react gives more freedom it tends to lead to differing opinions on how things are done. I agree that walking into an angular project is much easier than trying to navigate a React project

Collapse
ayyash profile image
Ayyash

Totally agree, I even shared some of the love here dev.to/ayyash/angular-a-shift-in-p...

Collapse
polterguy profile image
Thomas Hansen Author

Luvely writeup, and I (obviously) agree :)

Collapse
santunu23 profile image
Joy • Edited on

I completely agree with you.Angular is a complete framework for software development. And it’s pretty straight forward.I have been using Angular from last 3 years for all of my software development projects.Frankly speeking I have never thought to replace Angular with any other framework or library(like reactjs) because what ever my requirements are I can easily fullfill with the Angular.

Collapse
elsyng profile image
Ellis • Edited on

you'd need to install dozens of components before you can even create a simple HTTP request
Factually and simply incorrect. You can write almost everything yourself, and hey, with React it's a breeze. I rarely need to install a 3rd party lib.
:o)

Collapse
polterguy profile image
Thomas Hansen Author

Thank you for proving my point ;)

Collapse
elsyng profile image
Ellis • Edited on

I don't need to install dozens of components, because:

  1. Most stuff I can already do very simply, easily, optimally with html, css, js and React. It can be customised and will use less resources as such.
  2. Our projects usually require, or benefit from, custom UI and behaviour. In that way we have more control over how they look and behave, and we can do that with minimal resources.

If the project is happy to be built like a lego, then Angular might be a better fit :)

As someone else wrote here, the use case for Angular and React might not be exactly the same.

Collapse
aakarshchopra profile image
Aakarsh Chopra • Edited on

As a frontend developer who has mostly worked with React and would almost always prefer it as the first choice, I largely agree. Although the simplicity and unopinionated nature of React might be a good developer experience for personal projects, setting up a quick MVP, or even at start-up product with very specific technical requirements (that can benefit from a totally customized setup), that same lack of predictability can be a administrative headache at large organisations with a decent developer churn rate, and in that regard, I do concur that Angular can be the better choice in the long run.

I was the sole developer working on a project at work, where I created some good code structuring, common utilities, and development practices. That eventually led to me being assigned to another project in parallel that wasn't as well maintained, and lo and behold, it turns out to be an entirely different beast with a radically different set of libraries used, despite it still being React. Typescript was missing too, much to my annoyance. I need to maintain two headspaces for each project. Each projects's code reviews are different due to the difference in coding practices established initially.

I know that this all can be solved by a global standardisation spec across the organisation, and the projects can be migrated to that. But that's the point, it requires deliberate effort, and that standardisation will only remain as good as the diligence and commitment of most people working on it.

Working in an organisation where code quality and development flexibility are a secondary could benefit from rigid scaffolding and standard patterns of code. I believe this is more of a managerial decision than a technical one, but in the end, you need to cut unnecessary costs to have a well-paid team of developers if you're in a in industry that operates in a sector without enormous profit margins but with a well-defined frontend application requirement at scale.

Collapse
polterguy profile image
Thomas Hansen Author

Word!

Collapse
karanveersp profile image
Karanveer Singh

Makes sense. Goes back to the whole idea that React is a library and Angular is a framework.
I also think Elm is similar to Angular in this regard since I just started learning it.

Collapse
mramadanahmed profile image
Mohamed Ramadan

Not fair comparsion. As a React developer it is easy to follow the application struture starting from the index file. So structure is not a big deal

Anyway what makes it unfair comparsion, if we consider the structure is one factor to choose one technology and Angular is good in that. You have also to consider performance, typescript utilization, code reusiblity, SSR for SEO, community support and third parties packages for common functionalities. In fact React is much better in these factors

Collapse
polterguy profile image
Thomas Hansen Author • Edited on

As a React developer it is easy to follow the application struture starting from the index file

That's the whole point. You say it yourself, as in; "It is easy to follow ..." - If you need to "follow" to understand things, you've added cognitive requirements that are not needed in an Angular app. In an Angular app, "following" is not required, because all apps have more or less the same structure. I love the following quote illustrating the problem ...

Don't make me think. If your code makes me think, there's something wrong with it

As to ...

You have also to consider performance, typescript utilization, code reusiblity, SSR for SEO

In backend administration apps (the use cases referred to in the OP) this is 100% irrelevant. Except reusability, which I suspect is just as good in Angular as in React ...

Edit - As to community support. Angular's community support is amazing, although React's community support might be larger. However, if you need community support, you've already forced me to "think". I don't want to think. Maybe I've got 20+ backend administration apps I am maintaining. Spending 30 seconds context switching between different apps as I jump around my codebase is 30 seconds too much ... :/

Collapse
mramadanahmed profile image
Mohamed Ramadan

@polterguy thanks for your clear reply. I just have some concerns about that

1- if we are speaking about admin apps only, so it should be clear in the title of the post because the title is more general for web development

2- I am not underestimate Angular and its community as I used both React and Angluar and I know both are big. But flexiblity of react and wider third patries packages can help the team to solve business requirements easier and faster.

Anyway I guess in big companies they have a guidelines for boilerplate new react projects so the structure will be the same among different projects and developers can easily swap between projects. Also I think new developers always need some kind of orientation even with Angular as you have the freedom to set a strategy of what goes as components and what goes as servies for example

Finally technologies selection has different factors depend on the requirements so I am not say I will always choose react but most probably I will

I hope that make sense. Thanks

Thread Thread
polterguy profile image
Thomas Hansen Author