The answer that stayed the same for a decade
For the past ten years, whenever someone asked how they should build a frontend, the answer was remarkably stable: reach for a framework. The only open question was which one — React, Vue, Angular, later Svelte or Solid. That you'd take one at all was never up for debate. A framework wasn't the choice; it was the starting point from which you chose.
That reflex isn't an accident. Frameworks earned their dominance with concrete arguments that held up for over a decade. But the very arithmetic that let them win is now being redrawn by AI code generation. When a model scaffolds an entire interface in any stack you like within seconds, the ergonomic lead that carried the whole argument shrinks — and the costs a framework always dragged along come into sharper focus. So the honest question isn't whether the next framework will unseat the last one. It's this: is the era in which a heavyweight framework was the obvious answer coming to an end?
Why the frameworks won
You only understand the shift if you take seriously why frameworks won in the first place. It wasn't hype, and it wasn't fashion. It was three very real advantages.
The first was component reuse. Before React, you built interfaces by manipulating the DOM by hand — a button here, an event handler there, and the truth about the page's state scattered across a dozen places you had to keep in sync. React turned that into a model: state in, UI out, as a function. You build a <DatePicker /> once and use it a hundred times, and it behaves the same every time. That was a genuine step forward in how you think about interfaces.
The second was the ecosystem. Choosing a framework never meant just choosing a library. It meant buying into a whole universe: routers, state management, form libraries, component kits, testing utilities, thousands of answered Stack Overflow questions. Decide on React and you were deciding on Next.js, on a deployment story, on ready-made answers to problems you didn't even have yet. The ecosystem was the real moat, not the library at its centre.
The third, and for companies often the most important, was the recruiting pool. Choosing React meant you could draw from a sea of developers who already knew it. You didn't have to retrain anyone. A new hire was productive in days, not months, because they'd seen the same patterns three times elsewhere. For an organisation that isn't a side issue — it's the difference between a team you can scale and one that hinges on exotic knowledge locked in a few heads.
Those three advantages bundled into a single selling point that towered over the rest: developer velocity. A framework made teams faster. It took the same old plumbing off your plate and let you build the product instead of the infrastructure. That was the promise, and it was largely true. And it's precisely that promise the AI is now attacking.
What the AI changes in the arithmetic
The crucial point is unspectacular and consequential all the same: generation has become cheap, and cheap regardless of the stack. A model scaffolds you a table view with sorting, pagination and loading states just as fast in React as in Vue or in plain HTML with a handful of event handlers. The effort of standing up an interface for the first time has, for the human, fallen to roughly nothing in every stack alike.
That does something to the framework's headline argument. If "developer velocity" meant the framework gifting you the fast first version — then the model now gifts you that, in every stack. The speed that used to be the framework's edge is no longer a distinguishing feature. It's become table stakes, available everywhere. The ergonomic gap between "with a framework" and "without a framework" shrinks at the exact moment the human is no longer the one typing the first version.
And once speed of writing is levelled, the costs the framework always carried — the costs you were willing to pay because the speed outweighed them — step into the light. The bundle size. The build pipeline with its five tools. The dependency trees with their thousand transitive packages. And above all the churn — the fatigue of anyone who has migrated over the years from class components to hooks to server components, from Webpack to Vite, from one data-fetching paradigm to the next. Every one of those migrations cost weeks and delivered the user of the site: nothing. As long as the framework made you faster, you accepted that bill. When the speed is the same everywhere, the other side of the ledger weighs heavier.
There's a twist here, though, that you can't afford to miss. Models aren't equally good in every stack. They're best at whatever appears most in the training material — and that is, by a wide margin, React and Next.js. A model writes more reliable React than Svelte, simply because it has seen a thousand times more React. That produces an entrenchment paradox: the very AI tool that in theory makes every stack equally cheap, in practice makes the already-dominant stack even more attractive. Let the model help you, and you're nudged — gently but relentlessly — towards exactly where everyone already is. The AI doesn't democratise the choice of stack. It centralises it.
The countertrend: smaller, closer to the standards, more boring
In parallel, and not by coincidence, a counter-movement is gaining ground that points away from the framework — back to the platform itself.
There are Web Components: components as a web standard, running straight in the browser, with no framework underneath. Custom elements and the shadow DOM deliver the encapsulation that used to be the reason to lug a framework along — only now it's built in, with no expiry date. There's HTMX, which simply inverts the premise of the single-page app: instead of fetching JSON and rendering in the client, the server sends finished HTML and a few attributes in the markup swap the right fragments in. For a whole swathe of applications — forms, lists, dashboards, CRUD — that isn't less capable, it's radically less complicated. There's the HTML-first stance in general, and the formula "vanilla plus a bit": modern browsers now do natively much of what you used to pull in a package for, and you fill the gap with a few lines instead of an ecosystem.
What unites these approaches isn't nostalgia. It's the observation that a large chunk of what we bought frameworks for has either migrated into the platform or been made cheap by the AI. The churn of the JS ecosystem — that feeling that what you learned last year is already the wrong thing this year — carries a cost that more teams are now openly booking as a loss. And a standard doesn't age the same way: HTML from 2015 still renders in 2026. A frontend toolchain from 2015 is archaeology.
The real question has moved
Pull those threads together and it's less the answer that changes than the question. For a decade it was: "Which framework?" You chose between React, Vue and Angular, and the choice defined everything that followed.
The question that matters today is a different one: "What is the smallest thing that ships and stays maintainable?" That's not a rhetorical downsizing but a different starting point. For a marketing portfolio with three interactive elements, the honest answer might be HTML with a pinch of JavaScript — and a model will write you that just as happily as a React app, except there's no build pipeline to maintain afterwards. For a highly interactive application with complex shared state, the honest answer might still be React — not out of habit, but because the problem genuinely justifies the machinery. The point is that the framework turns from a default assumption into a decision you have to justify. You no longer reach for it because you always do. You reach for it when the task earns it.
Just so we stay honest: the frameworks aren't dying
And now the part you mustn't skip, because otherwise the wrong lesson sticks. Nothing said above means React and its peers are going away. Quite the opposite — several of the forces I've described push the other way, and the most honest analysis has to name that.
The training-data entrenchment I introduced as a paradox is the strongest reason the established frameworks are getting stickier, not looser. A model produces, by a wide margin, the most reliable code in a popular, broadly represented framework. It knows the idioms, the pitfalls, the typical mistakes and their fixes, because it has seen millions of examples. In an obscure or brand-new stack it hallucinates APIs more often, reaches for outdated patterns, and produces code that looks plausible and breaks subtly. Anyone choosing an exotic stack today on the reasoning "doesn't matter, the AI can do anything anyway" is betting against the very tool they mean to work with. That bet backfires more often than the tale of the boundless AI would suggest.
On top of that, the three original advantages haven't gone anywhere. React's recruiting pool is still enormous. The ecosystem is still deep. And component reuse still solves a real problem no generator, however fast, can conjure away — namely consistency across a large, long-lived codebase. A model can generate you a button ten times; whether it generates the same button ten times is another matter. That is exactly what the component model was invented for.
So the pragmatic move is often the opposite of rebellion. It's this: to lean on the well-supported mainstream — because the model is most reliable there, because you can find people to maintain it, because in five years someone still understands what's written. "The framework is dying" is a snappy headline. "The framework is no longer the reflexive default, but in many cases still the right call" is the true, more uncomfortable version.
Conclusion
The era in which "reach for a framework" was the complete answer is coming to an end — but not because the frameworks are dying. It's ending because the question has changed. As long as the human typed the first version, developer velocity was the decisive argument, and the framework delivered it. Now generation delivers it in every stack, and what's left is the old costs — complexity, churn, bundle weight — on one side, and the new entrenchment of the mainstream on the other. Both pull in opposite directions, and that's precisely why there's no blanket answer any more, only a better question: what is the smallest thing that ships and stays maintainable?
That is exactly how we make the call at NH Labs. We don't pick a stack because it got a standing ovation at a conference, and we don't throw React overboard because a blog declares it dead. We weigh two things against each other: how maintainable is this over years — and how reliably do the models we build with support this particular stack? Sometimes the answer is HTML with a pinch of JavaScript and no build pipeline. Sometimes it's React, because the problem earns it and because the tooling handles it best. What it's never is a reflexive default chosen by the latest hype. That's why our clients can count on what we ship not only running today, but still being understood and changed by someone in five years' time.