The Hidden Cost of JavaScript Frameworks for AI
The web development community has a chronic problem: it makes decisions based on vibes instead of evidence. For years, developers adopted frameworks because they seemed to offer a good developer experience (DX), justifying the choice retrospectively with claims like "the virtual DOM is fast!" — without ever measuring whether they actually delivered more value. Alex Russell has called this "frontend's lost decade"; Baldur Bjarnason labeled programming as a "pop culture" of fleeting trends.
But the era of AI agents has changed the game — or at least it should have. When a developer is no longer typing code line by line, but instead giving instructions to an AI agent (like Claude Code), the notion of "developer experience" becomes somewhat irrelevant. What matters now is how cheaply and efficiently a framework is when an AI agent needs to build with it. And that is exactly what engineer Nolan Lawson measured in October 2026 in an ambitious benchmark: the same Pokémon app, built five times with each of twelve different JavaScript frameworks, using AI agents.
The experiment
The setup is straightforward but deliberately chosen. Lawson built a Pokédex app — a catalog of Pokémon data with search, filters, and creature details — using the PokéAPI as the data source. For each of the twelve frameworks (Next.js, Nuxt, SvelteKit, Angular, Astro, Hono+htmx, Qwik, SolidStart, React Router, TanStack Start, Gracile+Lit, and vanilla JavaScript with Vite), he instructed a Claude Code agent (Opus 5.5 model) to build the same app and ran it five times per framework. The results were evaluated across four dimensions: API cost in dollars, real wall-clock execution time, tokens processed, and Lighthouse performance and accessibility scores.
The results revealed a clear and, for many developers, uncomfortable pattern. The cheapest framework for AI-built applications was Hono+htmx, with a median of $2.67 per build. Astro came second ($2.76) and Nuxt third ($2.82). At the expensive end, Angular was the costliest at $4.97 — nearly double the cheapest option. SvelteKit ($4.28) and Gracile+Lit ($4.65) were also notably more expensive. Plain vanilla JavaScript with Vite ranked fourth ($2.98), surprisingly competitive, challenging the notion that frameworks are always worth it.
What makes these numbers particularly relevant is that they don't just measure initial build cost. The amount of generated code directly impacts future maintenance costs. Hono+htmx produced about 1,370 lines of code; Angular produced 2,009 — roughly 70% more code. As Lawson notes, "in the agentic era, this hits even harder," because every future edit also consumes tokens, affecting "the literal cost to maintain a codebase over time."
Why some frameworks are more expensive
The reasons revealed by the benchmark are revealing. SvelteKit, one of the more expensive frameworks, had its agents reading the migration guide for version 3 every single run — likely because that version was too new to be in the Opus 5.5 training data. Gracile (a web components framework) was even more problematic: the agents didn't know the framework and had to either clone the repository or read compiled source from node_modules. Angular, on the other hand, simply generated more and more code with each iteration.
Adoption of AI tooling also varied dramatically between frameworks. React Router had the skill tool installed and used in 100% of runs; Nuxt had its MCP installed, but the agents never used it; Next.js had its skill file read only once in five runs. This variability demonstrates the stochastic nature of LLMs — the same agent can make radically different decisions for the same problem, purely by dice-roll.
Quality: what Lighthouse doesn't show
Interestingly, Lighthouse performance, accessibility, and CLS (Cumulative Layout Shift) scores were practically saturated across all frameworks — there was little variation. What really mattered was the amount of JavaScript sent to the client. Astro sent effectively 0 KiB of JavaScript (it was a statically generated site); Hono+htmx sent only 18 KiB; while Next.js sent 142 KiB, React Router 115 KiB, and TanStack Start 118 KiB. For users on mobile connections, the difference between 0 and 142 KiB of JavaScript is the difference between instant loading and waiting.
The LCP (Largest Contentful Paint) metric was even more revealing, although highly variable — which Lawson acknowledges as a limitation. In general, LCP punished Single Page Applications (SPAs) and rewarded Multi-Page Applications (MPAs), which is unsurprising: MPAs render HTML directly from the server, while SPAs need to first execute client-side JavaScript and make API calls to fetch data.
What this means for the future of frontend
Lawson's benchmark raises a question that few want to ask: in 2026, when AI agents are writing most of the code, should JavaScript frameworks be designed thinking primarily about machine readability, not human DX? The answer is probably somewhere in the middle — but the data shows that lighter frameworks with fewer abstraction layers (Hono, Astro, Nuxt) deliver better cost-benefit for AI-assisted development. And frameworks with extra layers of abstraction (Angular, SvelteKit) may be delivering less value than their marketing claims.
Lawson himself acknowledges the experiment's limitations: the Pokédex is a content app, closer to Wikipedia than to Figma or Gmail, and doesn't represent the complexity of highly interactive apps. But for a significant slice of the modern web — dashboards, catalogs, data-driven applications — the Pokédex is exactly the type of app that agents are building every day. And the numbers don't lie.
The question is whether framework authors will take these data seriously or whether the community will continue deciding by vibes — especially since, ironically, most framework teams are already using AI agents internally. If your own agent knows Astro is cheaper than Angular for building, why insist on the "feeling" choice?
Sources: Nolan Lawson, Web Standards Daily, GitHub — agent-framework-benchmark
✓ Independent sources cross-checked and verified before publishing