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.
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 … 😉
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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 selectorbutton[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.
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 … 😉