Reading Room

Most decisions about which JavaScript framework (the toolkit that structures a website's code) to use get made on feelings and gut calls, not real measurements. A developer named Nolan Lawson, who writes the blog Read the Tea Leaves, decided to test this directly now that AI coding agents, AI models that can take several steps on their own, do most of the actual typing. Lawson points to two other writers who have made the same complaint before him: Alex Russell has called this pattern frontend's lost decade, and Baldur Bjarnason has said programming works more like a pop culture than a field built on evidence. Lawson thinks this matches a pattern the psychologist Jonathan Haidt has described: people feel a gut reaction first, then invent the reasoning to justify it afterward. With an AI agent doing the typing now instead of a human developer, he wanted to know whether the old vibes based claims, that one framework is faster for agents or makes fewer mistakes, actually hold up. His results give a sharper, fact based way to question framework and tooling choices instead of going with whatever feels fast, useful for anyone running engineering teams.

Lawson built the same small app, a searchable list of Pokemon using the public PokeAPI, 12 separate times, once for each of 12 frameworks or meta-frameworks (a framework built on top of another framework, the way Next.js is built on top of React): Hono+htmx, Astro, Nuxt, plain Vanilla JavaScript, Next.js, Qwik, TanStack Start, SolidStart, React Router, SvelteKit, Gracile+Lit, and Angular. He had Claude Opus 5.5 build each version at high effort, using that framework's official MCP (a standard way to plug tools into an AI model) or skills, then checked the result against a conformance test suite so the agent could not cheat its way to a passing score. He deliberately avoided steering the agents beyond that: he did not tell any of them whether to render the page on the server before sending it or build it in the visitor's browser, and he did not tell them to aim for speed. Each agent worked without knowing its result would later be timed in Lighthouse, Google's automated site-speed and accessibility checker, though it did know about the conformance tests. He ran each framework 5 times and took the median result for cost, build time, tokens used (chunks of text, roughly three quarters of a word each), lines of code, and Lighthouse scores for speed and accessibility.

Lawson flagged real limits on his own test. The app is mostly a content page you search and filter, closer to a reference page like Wikipedia than to an interactive tool like Figma or Gmail. He picked that shape because it was easy to describe clearly and easy to test, not because it is the hardest case for a framework to handle. He also banned popular style toolkits like Tailwind and Bootstrap and instead gave every agent the same set of design tokens (a shared list of colors, sizes, and spacing values) to keep the look consistent. The point was to keep the test about the JavaScript frameworks themselves, and about choices like rendering on the server versus the browser and single-page apps (where clicking around never reloads the page) versus multi-page apps (where each click loads a new page), not about which CSS toolkit an agent happened to prefer.

To grade the apps fairly, Lawson tested against the accessibility tree, the simplified structure that screen readers use, rather than checking the raw page code line by line. He needed that approach because one of the 12 setups, Gracile+Lit, builds with web components that rely on shadow DOM (a structure that hides a component's internal code from the rest of the page). A test that demanded one exact HTML structure would have unfairly failed that framework for a difference that has nothing to do with quality.

Lawson was upfront that every measurement in this test is noisy. AI models do not produce the exact same output every time, since they generate words with an element of randomness built in, so the same framework could draw a lucky or unlucky run and send an agent down an expensive side path for reasons that had nothing to do with the framework itself. Even the grading tool wobbled on its own: Lighthouse's speed score depends partly on which single element it decides is the page's biggest visible item, a measurement called Largest Contentful Paint, and Lighthouse could pick a different image as that element from one run to the next on the exact same page. Running each framework five times and taking the middle result was Lawson's way of smoothing out that noise, which is also why he grouped his findings into three separate buckets: cost to build, the quality of the app produced, and how easy the resulting code would be to maintain afterward. The numbers below cover the first bucket, cost.

The cost to build ranged from $2.67 for Hono+htmx up to $4.97 for Angular, measured in the API price Claude Code would have charged. He noted this is not money he actually spent, since he pays a flat $100 a month on a Claude Max plan. In order: Hono+htmx $2.67, Astro $2.76, Nuxt $2.82, Vanilla JavaScript $2.98, Next.js $3.14, Qwik $3.27, TanStack Start $3.54, SolidStart $3.79, React Router $3.81, SvelteKit $4.28, Gracile+Lit $4.65, and Angular $4.97.

The numbers are noisy: React Router's typical cost ran about a dollar higher than Hono+htmx's, yet Hono+htmx's single most expensive run, $3.19, still cost more than React Router's cheapest run, $2.82. Even with that noise, a clear pattern held. SvelteKit, Gracile+Lit, and Angular were reliably the most expensive to build in. Lawson suspects SvelteKit's extra cost comes from the agent reading SvelteKit's version 3 migration guide on every single run, likely because that version is too new to be in Claude Opus 5.5's training data (the material it learned from before release).