What you are about to read is much more in the vein of musings and ramblings than it is some sort of structured and coherent argument about Angular and what the future might look like for frontend frameworks in general.

To start off with, here are a few points of things I think likely to be true about coding with LLMs and of Angular. Keep in mind that I don’t have much in the way of evidence to back any of these claims up, and I also think that is true of just about any claims anyone makes about the current software development landscape or where it is heading:

  • I think the vast majority of coding will be done with AI (i.e. we won’t write syntax anymore)
  • I think software architecture, planning, and maintenance will remain important and require experienced software developers for anything non-trivial
  • I think Angular is fundamentally structured in a way that can support good architecture and can work well with LLMs
  • I think React will gain more market share anyway as it is already solidified as the default approach, and LLMs will only reinforce that since models are trained on a lot more React data
  • I think existing companies that use Angular, and where the architecture required for the software is significant, will largely stick to Angular
  • I think projects with simpler requirements will switch to React
  • I think practices will evolve around React to support more rigorous engineering with LLMs, and I don’t think there will be compelling reasons for people to switch to/adopt Angular
  • I think framework choice will not have the same significance it had in the past, and people will be more focused on general architecture and management than on the specifics of frameworks

This brings me to something I’ve been thinking about for a while which is…

Why I’m not excited about Angular (or any frameworks) any more…

I, frankly, used to obsess over new features and ideas in Angular. Fundamentally, for me, what I found most exciting and what I actually think was the most important aspect of new features in Angular was not performance but developer experience improvements.

There are probably two key reasons why I had this view:

  • As much as our job is to deliver good results, I don’t want to be miserable writing the code
  • Happy developers care more about the code and write better code anyway, so in many cases a developer experience improvement might actually result in better and faster apps than a performance improvement would

Developer experience is still the thing I value most, it’s just that now the place to obtain that has shifted away from frameworks and into LLMs, loops, harnesses, prompting, and workflows…

…and so I find that specific implementation details in Angular don’t feel all that important to me anymore. Double imports is something we’ve all (or at least most of us perhaps) whinged about for a long time. It was a constant minor annoyance. The exact kind of developer experience thing you would want to optimise away.

But, if the LLM is handling it anyway, it really doesn’t bother me that much.

Signal Forms in Angular v22 has been another great example of this. In the past, this is something I would have been extremely excited about. Forms are one of the most annoying things to work with: by their nature they are just kind of complex and annoying.

Recently I had a client agree to switch to Signal Forms, which I would have been excited about in the past. A chance to modernise the codebase and unlock better developer experience moving forward.

But now, it mostly just seemed like a somewhat insignificant implementation detail. It’s the better solution so we should use that, but I’m not actually the one typing out forms by hand now. An LLM is going to be doing that, and I’m going to review the code. When I’m reviewing code produced by an LLM, or anybody, really, I’m not typically looking at it line by line, character by character. I’m looking at the bigger picture, how things connect, and so the lower-level details of more developer-friendly syntax don’t matter as much.

So, I plug in the official Angular skill for Signal Forms, get Claude to handle the migration… and that’s that. Any future changes to the forms an LLM is going to handle as well. The improvement isn’t really being felt by me anymore, and so naturally I don’t care as much about the change.

I don’t think this is a bad thing

It was never specifically dependency injection, or OnPush change detection, or observables, or signals, or control flow syntax, or anything else about Angular that I liked.

I liked that they facilitated a better developer experience, and a better developer experience facilitated better software.

Those concerns are just moving somewhere else now.

I’ve tried to avoid tribalism and dogmatism, but to a degree I don’t think we can help building some of our identity around the tools we use. As the importance of those tools fades, so does a part of ourselves and a community that was built around this shared pursuit.

I don’t think Angular is going anywhere any time soon, and I foresee myself continuing to use and advocate for it for a long time to come. But, times have changed, and it feels like there won’t be any going back to the way things were before, which fills me with hope and excitement, but also a sense of loss and nostalgia for what coding used to be.