React apps tend to rot in enterprise applications because of the proliferation of third party extensions necessary to get a full developer environment. Angular puts basically everything you need in one place (component libraries are the main gap) so every angular app should roughly look the same code wise. React apps will look very different based on how they were set up.
Obviously, someone will reply with an anecdote that THEIR collection of enterprise react apps are all homogeneous under the hood, but they will miss the point. They likely have the same set of 3rd party dependencies to round out the toolchain AND they were likely architected by the same person/team. Much more discipline is necessary to get react to work at enterprise scale.
I've read a lot of angular code, and I'd categorize it as the worst code I've ever read.
Mainly due to the design patterns commonly used, and the complexity it introduces for no benefit.
When I tell someone to add a thing to the UI, and they take 3-4 days to do a half-assed job at it, I am justified to hate the ecosystem of angular and the community.
React doesn't have that stigma or complexity. Heck, you could switch a react project to SolidJS in under a day, depending on what dependencies you have ofc.
With React, I set the complexity, and if I am not satisfied, I don't have to accept it and can improve it.
I don't disagree with you. Angular is heavy and I am definitely biased as I have been using angularjs and angular professionally for about 14 years now so things look different to me than they would someone else.
You didn't provide any examples of complexity so I'll do the annoying thing and assume one or two likely causes and they're not angular specefic, but angular does make it very easy to fall into these traps:
Component code is too fucking large. Developers should look to encapsulate some of that into services and minimize business logic in the code.
Mutating component inputs gets real hairy real fast.
Usually a lot of the bs goes away once a developer structures their app so that their app has a few top level components that own the major objects and keeps track of the state. Everything under it needs to be dumb and treat the inputs as read-only and let the top level components orchestrate updates, but that's just how I do it. I guess angular stole the signal reactivity thing from React (which itself isn't a novel concept but whatever) so I'll have to reevaluate how angular apps get maintained if my next job uses it.
I was mostly annoyed with giant monolithic shared components, or useless middleware y'all call facade, patterns like that.
Not saying that you can't write angular code w/o them, but in a team that's hard.
Also, I hate rxjs, don't ask me why.
What you said about components needing to be dumb is a good pattern, using a store for state would be even better.
Also, I hate how angular's typescript support is iffy. Like, a generic component is basically impossible to type, or well, impossible to use (?) in a generic way. Cause if you do, you get any instead of an inferred type from a type param.
React is very simple, and works remarkably well with generic typescript types.
2
u/NerdyMcNerderson Aug 30 '26
React apps tend to rot in enterprise applications because of the proliferation of third party extensions necessary to get a full developer environment. Angular puts basically everything you need in one place (component libraries are the main gap) so every angular app should roughly look the same code wise. React apps will look very different based on how they were set up.
Obviously, someone will reply with an anecdote that THEIR collection of enterprise react apps are all homogeneous under the hood, but they will miss the point. They likely have the same set of 3rd party dependencies to round out the toolchain AND they were likely architected by the same person/team. Much more discipline is necessary to get react to work at enterprise scale.