The Last Framework — Will Frasier

If you built for the web around 2015, you remember the meeting. Someone had drawn two columns on a whiteboard, Angular on one side and React on the other, with Ember written small in the corner by whoever was still angry about the Angular 2 announcement. There were spike prototypes. There was a senior engineer who had read the source of one of them and wanted you to know it. There was talk of two-way binding and the virtual DOM, of hiring pools, of what Google might do next. The decision took weeks, and it deserved to. You were going to live inside it for five years.

Nobody holds that meeting anymore. The people who used to sit in it have been replaced by a sentence.

Just build me a website.

It's what a friend says when they want a site for their bakery. Type it into any of the tools people now use to make software and you get the same thing, every time: React, Next.js or Vite, TypeScript, Tailwind, shadcn/ui. Sascha Becker went down the list this spring, Claude, GPT, Gemini, Grok, DeepSeek, Qwen, and found the same stack at the bottom of every one. v0 doesn't offer an alternative at all. Lovable ships the same stack with Supabase bolted on.

Your friend never saw a decision. "A choice was made on their behalf," Becker writes, "and presented as the only option." They didn't pick React over Svelte. They didn't know there was a list.

Before I go on: React is fine. I've shipped a great deal of it, and it was winning long before any model wrote a line of it. What I keep coming back to is what happens to a field when its biggest decisions stop being made by anyone in particular.

Who makes the decision?

The framework still gets chosen. Not by a committee, and not by a senior engineer who read the source. By a statistical process whose main input is how much has already been written about each option.

The best evidence I've found for how that process behaves comes from outside the frontend. In 2025, Twist and colleagues watched eight language models pick tools for projects where Python was a poor fit: low-latency systems, heavy concurrency, low-level work. Python was still the most-used language in 58 percent of cases. More telling, the models contradicted their own recommendations 83 percent of the time. Ask which language suits the job and you get a sensible answer. Ask the model to build the thing and it builds it in whatever it has seen most. Polars, a faster dataframe library that was growing quickly, was never used at all. Not once. Why? Nobody had written about it enough. The model didn't reject it. It just never thought of it.

Those models are a generation old now, and the newer ones take direction better. But the gap between what a model recommends and what it does is the whole story, because the person who says "just build me a website" never asks for a recommendation. They get the default.

For most of software's history, popularity was a lagging indicator. A tool got popular because enough people tried it, found it better, and told others. The signal was noisy, and there was plenty of corporate marketing mixed in, but popularity sat roughly downstream of quality. Now it's an input. The most-written-about framework gets generated most, so it gets shipped most, so it gets written about most, so the next model generates it more. Who, anywhere in that loop, stops to ask whether the thing is any good?

Popularity used to be the result of the choice. Now it is the choice.

How did the last new thing get in?

React itself arrived as a heresy. When Facebook open-sourced it in 2013, the reaction ran from skepticism to outright ridicule. JSX looked like a mistake: HTML in your JavaScript, the separation of concerns everyone had been taught, thrown out. Why would a team do that to themselves on purpose? Pete Hunt went on stage at JSConf EU that year with a talk called "Rethinking Best Practices," which is a title you only choose when you know everyone disagrees with you.

What did it take? A few thousand curious people spent a weekend with a strange idea, felt the difference, and wrote about it. The cost of trying the weird thing was your own learning curve, and a good enough idea paid that back.

That cost has changed shape. A new framework today is unfamiliar to the developer and to the developer's collaborator, the one doing most of the typing. Svelte learned this from its own users. After Svelte 5 introduced runes in late 2024, models kept writing Svelte 4, mixing old syntax into new code because they had seen so much more of the old. The Svelte team ended up publishing documentation formatted specifically for LLMs. In 2015, that sentence would have made no sense. A framework now has two audiences to win. Which one is harder? The one that learns in batches, on a delay, in proportion to how many people already use you.

Eric Normand put the arithmetic better than I can: "Before, if a new language was 10x more productive than JavaScript (or the most popular language), it had a shot. But if you're already 10x faster with the AI using JavaScript, your language will have to be 10x that combination, using an AI not trained on it." Swap "framework" for "language" and nothing about the math changes.

Even the winners can't eat

If you want to see what this does to the people who build the tools, look at Tailwind.

Tailwind is in the default stack of every AI builder. Adam Wathan says usage is growing faster than it ever has. And in January 2026, Tailwind Labs laid off three-quarters of its engineering team. Traffic to the docs had fallen 40 percent in two years, and revenue was down almost 80 percent. There's no villain here. The business depended on developers visiting the docs and finding the paid products. Developers don't visit the docs anymore. Who does? Their assistant.

Wathan made the announcement while declining a pull request that would have added an llms.txt file to make the docs easier for models to read. "Making it easier for LLMs to read our docs," he wrote, "just means less traffic to our docs."

The docs trained the assistant that stopped visiting the docs. You couldn't draw a tighter circle.

Open source has always been funded, one way or another, by attention: docs traffic, conference talks, the reputation that turns into a job or a consulting practice. AI keeps the usage and strips out the attention. If the most successful CSS framework of the decade can't pay its engineers on those terms, who pays for the challenger that would have replaced it in 2030?

The same thing is happening one layer down, in the public places where new tools used to get taught. A study in PNAS Nexus found Stack Overflow activity fell about 25 percent within six months of ChatGPT's release, with Python and JavaScript falling faster than average. The questions didn't stop. They went private. Every developer who asks a model how to do something in a new framework, instead of asking in public, produces an answer the next model will never see. A new framework needs a public record of people struggling with it before a model can learn it. Where does that record live, now that we've all stopped writing it?

Does the trap close on React too?

The lock-in doesn't only protect the incumbent. It freezes it.

Becker makes the point with a single sentence about training data: a frontier model "has seen ten years of useEffect + fetch and maybe two years of TanStack Query. It has seen a decade of manual useMemo and one year of the React Compiler." React can keep improving. But can the React that everyone generates? It moves at the speed of the corpus, and its own authors now design for a reader that learned their API from its past.

Abdelkader Boudih calls this the ossification of APIs, and he describes the new participant well: "the AI intermediary that needs to 'get it'" before your users can have a good experience. He saw it in his own Ruby library. He gave a class a render method with its own meaning, and Copilot kept trying to fill it in with Rails controller options while RuboCop warned about the arguments. Both tools had seen Rails' render so many times that any other meaning looked like a mistake.

So the pressure works against new ideas inside existing frameworks as much as against new frameworks. Every design choice now gets a quiet review from a reader whose taste is the average of everything already written.

Am I wrong?

There's a serious argument that none of this matters, and I want to give it its due.

Start with standardization. We spent a decade complaining about JavaScript fatigue. A new framework every eighteen months was a tax, not a gift. If the field settles on one reasonable stack the way railroads settled on one gauge, maybe the energy goes somewhere better than rewriting the same todo app.

The lag is also shrinking. Models read documentation at inference time now: llms.txt files, MCP servers, tools like Context7 that put current docs straight into the context window. A framework released today can be usable through an agent in weeks rather than a training cycle. The Svelte problem of 2024 may look quaint by 2027.

And new tools do still break through. uv went from launch to default in a large share of Python shops in about a year, in the middle of all this, with no help from training data.

Then there's the most interesting objection: maybe the frontier moved. José Valim, who created Elixir, wrote recently that agents simply aren't bothered by boilerplate, so the syntactic comfort that drove a generation of frameworks matters much less than it did. The innovations that count now may be the ones that help machines, like stronger guarantees and runtimes that expose their own state. If he's right, the next great framework won't look like a framework to us at all, and asking for "the next React" is asking for a faster horse.

I think all of that is partly true. But look at why uv won. Slow installs are pain the model can't absorb for you. You sit there and watch the spinner. That's the real dividing line.

Friction was the signal

What did every framework that mattered start as? Somebody's irritation. Backbone, because jQuery spaghetti didn't scale. React, because Facebook's interface kept falling out of sync with its own data. Svelte, because shipping a runtime to the browser to draw a mostly static page felt absurd. The ideas came from people close enough to the pain to notice it and stubborn enough to believe it wasn't necessary.

AI is extraordinarily good at absorbing pain. That's the point of it. The model swallows the boilerplate and the baffling error and the three hundred lines of state management that once would have made you swear and open a new tab to look for something better. The person who asked for a website never feels any of it, so they never form an opinion about it, so they never go looking for what's next.

That's the stagnation I'm worried about. React winning is fine, and new frameworks have always been hard to launch. What changed? Fewer and fewer people feel the problems, and the people who feel a problem are the only ones who ever solve it. A framework's job used to be relieving developer pain. Now the model relieves it, sitting on top of the framework, and in doing so it hides the signal that told us where the framework was failing.

We haven't eliminated the friction. We've stopped feeling it, and only one of those leads anywhere new.

A single railroad gauge works because trains aren't trying to evolve. Software is. A monoculture is efficient right up until conditions change, and conditions always change.

What does choosing look like now?

Where does that leave the choice? I don't think the answer is nostalgia, or refusing the tools. It's putting the choice back somewhere a person can see it.

If you build things, when was the last time a decision was made for you and you didn't notice? You probably can't say, and that's the point. Write your stack into your AGENTS.md on purpose, even when it's the default stack, because a deliberate default is a different thing from an accidental one. Every so often, spend a Saturday on something strange, especially something your assistant is bad at. The friction is telling you something.

If you build frameworks, the machine is now a first-class audience: ship the llms.txt, the MCP server, and an eval suite that proves models can write your framework correctly. It's unfair that this is the price of entry, and it's the price of entry anyway. If you build models, treat diversity of output as a quality metric. A model that recommends Polars and then writes pandas has a bug.

And if you're old enough to remember the whiteboard, write down what you know. We're the last cohort who learned why these choices matter by getting them wrong ourselves, and that knowledge won't reach the training data unless someone puts it there.

Your friend who wanted a website is going to get React, and they're going to be fine. Fine is fine. But who is willing to not be fine? In 2013 somebody was: they tried the thing everyone was mocking and stuck with it long enough to find out it was better. If we build a world where that person never feels enough friction to start, React won't just be the framework we chose. It will be the last one anybody did.