The Angular v22 announcement centers on a few headline changes that make the framework feel more modern and less dependent on older Angular-specific patterns. The big ones are signal-based forms becoming usable enough that people who had been waiting on them are ready to adopt, resources maturing for async state, Angular Aria launching as an accessibility component library, and official AI-facing tooling like an MCP offering. For people whose mental model of Angular froze around v2 through v14, the reaction was surprisingly upbeat. Several developers said the accumulated changes through v21 and v22 make it feel like a different framework. Signals, new template control flow, less boilerplate, and zoneless defaults have chipped away at a lot of the pain that used to define Angular work.
Angular is repositioning itself as the structured, batteries-included option for large web apps, and if the team can keep reducing RxJS and tooling friction, it becomes a more credible enterprise alternative to the React stack sprawl.
Mostly positive and a little surprised. Many commenters said modern Angular is much better than its old reputation, especially after signals, new control flow, less boilerplate, and zoneless defaults. The negative comments focused on Angular’s rigid compiler and CLI, lingering RxJS complexity, and skepticism that the ecosystem or accessibility story is fully polished.
01 Angular’s RxJS problem was never that observables are bad.
It was that Angular pushed them into places where they added ceremony without adding leverage. Commenters called out HTTP and older forms APIs as the clearest examples, since most app code there wants simple request-response or local state, not stream composition. The rise of signals is valuable because it narrows observables back to the cases where they actually fit, while making everyday state and form handling feel normal again.
Signals are not just a new primitive. They are Angular’s escape hatch from years of unnecessary RxJS exposure in ordinary app code.
02 Angular’s tooling lock-in is a strategic limitation, not a cosmetic annoyance.
The tight coupling between Angular’s compiler, TypeScript flow, and CLI makes custom build setups harder and makes gradual migration into or out of Angular much more painful than it should be. That matters most in real companies, where greenfield purity is rare and teams often need Vite-style integration or partial adoption inside an existing app.
The biggest thing holding Angular back is not developer ergonomics anymore. It is poor interoperability with the messy reality of mixed stacks and incremental rewrites.
03 Angular’s best selling point is opinionated structure.
People framed it as the frontend equivalent of Rails or Django, where the framework gives you conventions for components, state, and data flow instead of making you assemble them from a library ecosystem. That is why it keeps resonating with teams building complex internal or enterprise apps, where reducing cognitive load across many developers beats maximizing flexibility for any one developer.
Angular wins when standardization is the product. Teams that want fewer architectural choices may get more leverage from it than from the usual React stack.
04 Accessibility libraries live or die on trust, and trust is fragile.
Even with enthusiasm for Angular Aria and its richer examples like autocomplete, a commenter quickly found keyboard behavior in the showcase that appeared inconsistent with expectations and possibly with W3C guidance. That does not prove the library is weak, but it does show that accessibility claims are judged against exact interaction details, not marketing language.
Shipping accessibility components is not enough. The docs and demos have to be correct at the level of keyboard behavior or confidence drops fast.
01 The idea that Angular is obsolete looks stale if you have touched a recent version.
Developers who upgraded from v14 to v21 or had not used it since the early years said the cumulative change is large enough that it feels like a different framework. Dismissing Angular based on its v2-era reputation now misses how much friction has been removed.
A lot of Angular hate is lagging indicator sentiment. Recent Angular should be judged as its current product, not as a memory from 2016.
02 Not everyone accepts the premise that a richer frontend framework is the right answer at all.
One comment argued that server-rendered apps with Django or another backend plus htmx can deliver much of the SPA feel without inheriting the complexity of modern JavaScript framework ecosystems. That reframes Angular’s improvements as optimization within a problem space some teams should avoid entirely.
The strongest alternative to Angular may not be React. It may be doing less frontend framework work in the first place.
03 Angular’s closed tooling story is also a feature for some teams.
One commenter said the inability to swap in a custom toolchain is exactly the appeal, because it removes a whole class of local optimization and stack fragmentation. For organizations that value consistency over experimentation, Angular’s rigidity can lower operational entropy.
What feels like lock-in to one team feels like enforced discipline to another.