It's Angular Now
This site has gone through more framework changes than there are JavaScript frameworks. I'm not sure how that's possible either. But it's part of the fun. Maybe if I were smart, I'd just do a separate project instead of rewriting the same one all the time. Maybe then I wouldn't remove content out of laziness.
My first blog was on WordPress, eventually I wrote my own CMS with PHP. Then came NextJS. I started with version 7. And it's what propelled me into obsessing over React. Developing what other developers call "React brain."
But the longer I work with React professionally, the more tired of it I get. Like many, I'm so sick of the reactivity model in particular. Everything rerenders as a default, and to scale we have to memoize everything? We need a compiler for that now? Why is anyone excusing that as an achievement or benefit? Imagine developing a database that is famously slow and telling your users to just memoize queries to speed it up.
React server components feel more like React tucking its tails between its legs and running to the server to handle everything for it. "If you stop using our rendering model and just use renderToString() on an express app hidden behind a black triangle, you won't have render issues!"
Every day working with React means another day fighting the framework. We know its performance sucks. We know the only thing good about it is JSX (which isn't exclusive to React). And we know the only reason anyone chooses it these days is because it's popular.
The modern solutions come down to SolidJS and Svelte. I haven't used Svelte to any degree but SolidJS is fantastic. Beautifully done, it fixes the broken reactivity model of React, and keeps the JSX.
So why would I go with Angular and not Solid?
Angular 19 Is Hot
The Angular 19 release blog caught my eye for a few reasons:
Event Replay
To make a server side rendered app immediately interactable, events are captured and queued during the hydration process. The event dispatch library used for this is the same one used by Wiz which was developed for Google Search. This feels like a nice answer to Qwik's resumability. Although fine-grained hydration doesn't exist quite yet.
Route-level render mode
This has been something in the back of my mind for a long time. The NextJS model of server rendering seems to have dulled everyone's understanding of exactly what server rendering is. Someone once told me about Dan Abramov's "theory of two computers" as some brilliant innovation. The choice of the word "theory" is a stretch. And this person likely completely misunderstood his React for Two Computers talk, which was not an announcement of a profound idea, but a pitch for Reacts direction to server frameworks.
Dan's talk was not a new idea, he was reminding the people who are so afraid of anything other than SPA (and their oxymoron SPA routers) that there's more than one way to template some HTML.
Angular allowing the simple option to server render, client render, or prerender said HTML per route is amazing. And as a reminder related to the small rant above, this has no effect whatsoever on what you do with said prerendered HTML with JS after it gets to the client.
Reactivity!
The entire section on reactivity from the Angular 19 announcement reads nearly word for word as a Ryan Carniato blog. Angular, of all frameworks, seems to have beat both major players to full signal support. Vue Vapor mode is still in beta, and React couldn't care less.
SolidJS still does performance optimizations beyond simple signals that will make it faster than Angular for a very long time. But this new reactivity has skyrocketed Angular in terms of performance.
Dependency Injection is Actually Nice
Dealing with React Context for so long, it's an unbelievable relief to be able to create an Injectable service with Angular and use its shared state.
React Context is famous for poor performance and is considered bad practice to even use in most cases. The alternative is to use a third-party state-management library to instantiate an "external" store outside of Reacts lifecycles and go through a lot of effort to control Reacts awareness of changes to this external store. HUH? This means React doesn't work!
It's just HTML and classes.
Maybe the biggest turn-off for people seeing Angular for the first time is the number of files per component. Every component has a .ts file, .css file, .html file, and .test file. But add in Tailwind and you can get rid of the .css file. Now what you're left with is a simple class in which to declare signals and logic. It's not much different than every React component having a .tsx file and a hook. Which isn't a terrible idea, btw.
Any shared logic or state can be moved to services, which are again just simple injectable classes. No library needed.
Signals Are Simplifying Frameworks
While React scutters off to hide its faults behind server rendering, client-side rendering is still improving, it's still getting better. Vue has been working on "Vapor Mode", and of course, innovative libraries like Qwik and SolidJS have been driving amazing ideas.
Angular, too, has been improving on things like server side rendering and partial hydration which will also make a huge difference. But it doesn't feel like they've completely given up on the client like React has.
With Angular, Zone.js is deprecated, and RXJS is completely optional with the same simple signals used by SolidJS taking its place. Including a resource() hook to manage async data. (And yes, TanStack Query has an Angular adapter too.)
By being able to work with plain HTML, TypeScript classes, and signals, I feel like Angular is the "one of the big 3" framework that feels native but solves the problems with going pure native. Without having to deal with the tradeoffs of something like Astro.