Strip away the branding and most JavaScript frameworks exist to solve one problem: make it nicer for a person to write and maintain a lot of UI code by hand. React gives you components and a mental model for state. Vue gives you a template syntax that's easier to read than raw DOM manipulation. Next.js gives you routing, data fetching and rendering conventions so a team doesn't have to invent them from scratch.
None of that is about what the browser needs. It's about what the person typing the code needs: less boilerplate, fewer footguns, a convention to follow instead of a decision to make every time. Exactly the same job Rails did for backend Ruby.
Take that need away, and the question gets uncomfortable fast: what's left for a JavaScript framework to do?
Vanilla JS is the fast option, so why isn't it winning?
"Vanilla JS" is a deliberately odd name. It's a joke that stuck: plain JavaScript, with no framework flavor added, the way vanilla is the unflavored base of an ice cream. People started saying it because "JavaScript" alone had stopped meaning that. Ask someone what "the JS" is on a modern site and they'll usually mean React, or Vue, or whatever runtime shipped the bundle, not the language itself. "Vanilla JS" exists to specify the version with nothing added.
And the plain version is fast. No framework runtime to download, parse and execute before the page does anything. No hydration step where the browser has to reattach JavaScript behavior to HTML it already rendered. HTML, CSS and a script tag load faster, work on more devices and need less to go right, because there's less shipped in the first place.
So here is the puzzle the notes for this post started with: if plain HTML, CSS and JS is the fastest way to build a website, why is Next.js still the framework taking share from WordPress on the most-visited sites on the web, not vanilla JS?
WordPress still runs 40.7% of all websites and 58.9% of the CMS market as of September 2026, according to W3Techs, and among the top 10,000 sites by traffic it holds roughly 52% of CMS usage. That's the incumbent Next.js is up against, and it's still gaining there, not vanilla JS or static HTML.
Look at which sites are actually running Next.js at the top of that list, and the pattern answers its own question. Linear, at 340,000 daily users. Nike and Target, running live inventory and per-user recommendations across millions of SKUs. ChatGPT's own web interface, streaming a conversation in real time. Vercel's own site, streaming in personalized auth state around an otherwise static shell. These aren't brochure sites. They're products with logged-in users, live data and more than one person editing the underlying content at once.
That's the assumption from the notes, and it holds up: the sites where Next.js is winning are the ones doing something a static page structurally can't. Personalizing per visitor. Streaming data that changes between one page load and the next. Serving an interface that many people write to at the same time, not just read. A marketing page for a bakery doesn't need any of that. A live inventory feed across three million SKUs does.
So what's actually left for a framework to do?
Once you separate "nicer for a human to write" from "structurally necessary," the list of what's left gets short, and specific:
- Personalized or dynamic server rendering. A page that looks different depending on who's logged in, what's in their cart, or what a database says right now, at the moment of the request.
- Real-time, many-writer surfaces. A chat app, a shared document, a live dashboard: anywhere the content on screen has to update because someone else, or something else, just changed it.
- Complex client-side state. An interface with dozens of interdependent pieces of UI state (open panels, selections, in-progress edits) that all have to stay in sync without a full page reload.
Notice what's not on that list: rendering a page, however good it looks. HTML and CSS already do that, for free, before a single line of JavaScript runs.
Astro's islands are a working answer already
Astro didn't wait for this thought experiment. Its islands architecture, a term coined by Etsy's Katie Sylor-Miller in 2019 and expanded by Preact's creator Jason Miller in 2020, ships a page as static HTML by default and only adds a JavaScript "island" around the one component that actually needs to be interactive: an image carousel, a comment box, a live cart total. The rest of the page never pays for a framework runtime it doesn't use. Astro's own docs are blunt about the alternative: most JavaScript frameworks hydrate the entire page as one application, which is "a heavy-handed choice for most projects on the web today."
Islands aren't Astro's alone anymore either. Most modern frameworks now support some version of partial hydration. It's less a product feature at this point and more an acknowledgment that shipping a full app runtime for a page that's 95% static text was always the wrong default.
Islands are close to the answer this post is looking for: ship plain HTML and CSS everywhere, and reserve JavaScript, framework or not, for the handful of places that are genuinely dynamic. What's still open is whether that dynamic sliver needs a framework at all, or just JavaScript.
What if agents just use web components instead?
Here's the wrinkle the notes raised that's easy to miss: agent-generated interfaces are running into the same framework dependency that human-written ones did, and some developers are already routing around it on purpose.
Every current agent-UI standard defaults to React. MCP Apps: React. AG-UI from CopilotKit: React. Even Google's A2UI, which is meant to be protocol-level and framework-agnostic, ships every reference implementation in React. One developer built an open-source counterpoint: a 14-component toolkit built entirely from web components (the browser's own custom-element standard, no framework required), specifically because, in his words, "you shouldn't need create-next-app" just so an agent can open a modal or switch a tab. Google's own A2UI design already points the same way in principle: the agent says "I need a card," and the client decides how to render it, whether that client is React, Angular or plain web components.
That's the strongest hint yet for where this goes. If an agent doesn't care whether it's emitting a <div> with React props attached or a <z-modal> custom element, the framework isn't doing anything the web platform doesn't already do on its own. Web components give an agent a stable, standard target that works in any framework, or none, without a build step. That's not a hypothetical for later. Someone already shipped it.
Where vanilla JS still struggles
None of this makes frameworks pointless today, and it would be dishonest to pretend otherwise. State handling in plain JavaScript is genuinely harder once an interface has more than a handful of moving, interdependent parts. React's component model and reactive state exist because keeping a dozen pieces of UI in sync by hand, with plain DOM updates, gets error-prone fast: it's easy to update one part of the screen and forget three others that depended on it.
Web components help with structure and reuse, but they don't hand you a state management story on their own; you still have to build or borrow one. And a real-time, many-writer product like a chat app or shared whiteboard is a different kind of problem than a page of prose with a search box, no matter who's writing the code underneath it.
So the honest version of this piece isn't "frameworks are dead." It's: the reasons to reach for one just got narrower, and more specific, than "the code is nicer to write this way."
Where this leaves us
Splitleaf builds sites in HTML, CSS and vanilla JavaScript today. That decision was made on the same logic Rails was built on: a framework earns its place by making the code nicer for the person writing it. When a human was always going to be the one writing and maintaining that code, this cut both ways. It doesn't cut the same way anymore.
We don't have a rewrite to announce. What we have is a real question, out loud, before we act on it: if agents are already comfortable writing Rust for a mail server, and comfortable emitting web components for an agent-built interface, how much longer is a JavaScript framework's real job "be nicer to write" instead of "do something the page genuinely needs"? We think the honest answer, for most websites, is that it already has less to do. We're watching to see how much less.