I am retiring the rest of my Angular libraries. I have already marked many of them as archived or deprecated, but this is the last wave. The issues pile in and I have no reason to maintain them anymore.

What’s weird is that with access to AI, you’d think I’d have more time to maintain them. Or that I could just point an agent at the repo and have it maintain them for me. But what it actually creates is more issues—you still need someone to keep up with the ecosystem and have a vision for the project. Should ngx-toastr migrate to Angular signals? Could your agent implement a better toast component in one or two prompts?

The first Angular 2+ and TypeScript commits I found in my repos are from July 28, 2016. I owe much of my career to Angular turning me on to TypeScript, and it’s been a great 10+ years.

Fast-forward to today: I haven’t used Angular in over 5 years, and I don’t see myself shifting back. I’m mostly using React and TanStack Start on side projects. At a certain point, it becomes a detriment to an ecosystem to have half-maintained projects, as the forks can’t thrive. I’m not even sure what version Angular is on anymore.

I got to see some of these libraries make their way into interesting places. ngx-emoji-mart was used in some form in ClickUp, and ngx-toastr was used in the Angular documentation for a while. I also got to see some of these projects get forked and maintained by other people, which is really cool. I hope they continue to thrive.

What I’m Retiring now

• ngx-toastr (2.6k★)
• ngx-emoji-mart (460★)
• ngx-color (444★)
• ng2-adsense (139★)

Where should people go now? I’m not sure. Fork it and make your own.

What changed

When I started these libraries, the default move was “install a full component suite,” and you saw libraries like Angular Material and PrimeNG getting millions of downloads. Now the center of gravity is headless primitives plus composition. Teams want control over markup, styling, and behavior instead of inheriting a giant, opinionated package.

AI shifts that default again. More people will type “make a color component” before installing an off-the-shelf color picker. And frankly, they should. For many apps, that generated component is already good enough and faster to adapt.

I still think there’s room for good, battle-tested headless primitives, but the bar is higher.

If you opened issues, sent PRs, or used these packages in production: thanks. I mean that.