Signals: I Was Wrong. Kinda.

A while ago, I wrote an article called Signals: The Enshittification of Angular.And I still agree with a lot of it.

The first iterations of Signals felt unfinished, awkward and weirdly ideological. Performance issues, endless update loops, another reactive abstraction on top of Angular’s already fragmented architecture and a community suddenly acting like the default was a historical mistake.

At the time, Signals didn’t feel like Angular becoming simpler. They felt like Angular having an identity crisis. But with the recent updates: Signals work now. The endless update loops from the first iterations seem to be gone, the performance issues are no longer a real concern and Angular finally started building the framework consistently around the concept: httpResource, forms as signals and the overall direction finally make Angular feel coherent again.

And that’s the part where I was wrong. Kinda.

Angular created a reactivity war

One of Angular’s biggest ironies is that its original default change detection worked perfectly fine for most applications.

Then the community overwhelmly decided it was unacceptable.

OnPush, Async pipes, Subjects, manual detectChanges() everywhere. Entire components looking like handcrafted RxJS operators just to handle a loading state. Angular developers spent too much time writing boilerplate to replicate behavior Angular already handled automatically. And somehow this became “clean architecture”.

Everyone had a different definition of “proper Angular” and Signals didn’t really introduce a revolutionary new paradigm for me. Just made it look like another Wannabe-React.

Signals made Angular coherent again

This is the part I genuinely underestimated. Signals unified Angular’s mental model in a way Angular desperately needed. State changes update the UI. That’s it.

No async pipe ceremony for synchronous state. No manually triggering change detection because Angular randomly missed another case. No weird “reactive but not reactive enough” social media post every week.

Signals made a kinda straightforward solution the standard again.And honestly, that alone improved Angular more than most technical features ever could.

Because for years, Angular’s biggest problem wasn’t really performance. It was that the ecosystem normalized complexity and called it scalability. Signals quietly killed a massive amount of unnecessary abstraction.

Angular didn’t need this shift. The community did.

This is the one thing I still struggle with. I’m still not fully convinced Angular itself needed such a massive architectural shift in the first place. A lot of the problems Signals solved were arguably created by Angular culture itself. Overusing OnPush, pushing reactive purity over developer experience and normalizing increasingly convoluted boilerplate as “enterprise best practice”.

Angular probably could have solved a large part of this by enforcing simpler standards and better defaults much earlier. Instead, the ecosystem slowly drifted into a place where developers manually optimized everything while recreating behavior the framework already had.

So maybe Angular didn’t need Signals as much as the community did. Signals became the escape hatch from that complexity. Ironically by introducing another reactive primitive.

The weird part is that it worked, so I'm not against Signals anymore.