实测各 JS 框架的 AI 构建成本

The AI cost of JavaScript frameworks

One of my pet peeves with the web development community is that so many of the decisions we make are vibes-based. Frameworks are “blazing fast,” tools will “supercharge” your development, the right abstraction will benefit both you and your users (DX and UX all in one!). All of this breathless boasting is usually offered with zero evidence. Alex Russell has called this “frontend’s lost decade”, Baldur Bjarnason has called programming a pop culture, and I’ve tried to counter this trend in my blog with facts and benchmarks (at my best, anyway).

For a long time it seemed like our community’s allergy to evidence was driven by the desire for greater DX. In other words, devs just liked the way it felt to type JSX in React, and the arguments promoting React or related tools (“the virtual DOM is fast!”) were largely post-hoc rationalizations to justify those initial gut feelings. (Jonathan Haidt would likely agree with this assessment.)

But in the agentic era, when developers are no longer typing code by hand and are thus less constrained by DX, I still see vibes ruling the day (and not just in the sense of “vibe-coding”). Frontends are rewritten because some framework or another is “better for agents.” (Did anyone think to ask the agents?) The resulting code is “faster,” the agents make “fewer mistakes,” etc. Once again, these claims are often made without evidence. Whenever I read one of these accounts, I think to myself, “Where are the benchmarks?”

Well I got curious, so I wrote a benchmark. The structure of this benchmark is pretty straightforward:

- Design a small but non-trivial Pokémon app using the PokéAPI (those who have followed my work will be unsurprised)

- Instruct agents to build the app with a particular JavaScript framework/meta-framework (e.g. Next.js, Nuxt, SvelteKit, etc.)

- Test the output against a spec conformance suite (to avoid agent cheating)

- Evaluate the results in terms of development time, tokens spent, lines of code, and performance and accessibility scores in Lighthouse

The app is fairly simple: you’ve got a list of Pokémon with their types, moves, and data from various games. You can search, filter, etc.:

I should start off with some caveats: this is not a perfect experiment. This app represents only one holotype – it’s a relatively content-based site with little interactivity, closer to a Wikipedia than a Figma, GMail, etc. That said, I had to choose some app to build, and this one is at least easy to understand at a high level, and relatively straightforward to spec out and test.

To try to even the playing field, I had each framework/meta-framework use the official MCP or skills for that tool. I wanted to avoid accusations of “this framework is not well-represented in the training data, that’s why we built our MCP, we expect people to use it,” etc. I also didn’t over-specify the exact architecture to use (e.g. SSR vs CSR), nor did I specify that the app should be as performant as possible. I simply gave the spec to Opus 5.5 with high effort and told it to use the latest version of the given framework. Each agent ran in a sandbox and without any knowledge that it would be tested in Lighthouse on performance and accessibility, although it was given the conformance test suite.

Note I also didn’t mandate any CSS methodology, except to avoid using Tailwind, Bootstrap, or any other component framework, and to design based on a set of spec tokens to enforce some visual consistency. I didn’t want to make this test all about CSS, but instead about JS frameworks, CSR vs SSR, SPAs vs MPAs, etc. The resulting app is tested against a conformance suite based on the accessibility tree rather than the raw DOM to avoid mandating any particular HTML structure – one framework uses web components which rely on shadow DOM, so this was required.

One thing I learned from this experiment is that everything I’m measuring is very stochastic. LLMs are random-word generators, so sometimes you get a low dice-roll and an agent goes off on some weird tangent wasting a bunch of tokens, through no fault of the framework or its tools. Lighthouse itself can give inconsistent results as well: Largest Contentful Paint (LCP) may decide that one image is the “largest” element, then pick another one on the next run. It’s hard to have a perfectly fair experiment, but running multiple iterations did help, and I’ve tried to be honest about the variance.

With all that throat-clearing out of the way, let’s get to the results.

Results

I’m going to break this down by multiple dimensions: cost to build, quality, and maintainability. For each framework/meta-framework, I took the median of 5 runs: in other words, I built the same app 5 times in the same framework. (Yes, this is the kind of zany thing you can do with coding agents these days.)

The exception was Angular, which failed to create a measurable app twice, so I took 3 iterations instead for some metrics. (This is explained below.)

Cost

| Cost per run, in US dollars | |

|---|---|

| Framework | |

|---|---|

| Hono+htmx | $2.67 |

| Astro | $2.76 |

| Nuxt | $2.82 |

| Vanilla | $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 |

| Angular | $4.97 |

| | 02468 |

Note that this quotes the API prices directly from Claude Code and doesn’t actually represent how much money I spent. I’m on a Max plan, so this was just part of my overall $100/month.

Note also the variance: React Router’s median is roughly $1 worse than that of Hono+htmx, but the cheapest version of React Router ($2.82) is still cheaper than the most expensive version of Hono+htmx ($3.19). However some reliable patterns do emerge.

Most clearly, SvelteKit, Gracile+Lit, and Angular are more expensive to build than the other frameworks. For SvelteKit, this may be due to the fact that the agents read the SvelteKit v3 migration guide in every run, likely because it’s too new to be in Opus 5.5’s training data. Similarly for Gracile, the agents didn’t know the framework very well and either cloned the Gracile repo or read its compiled source from node_modules. For Angular it seems to be a function of the total code size (see below).

I should also mention that not every agent made use of an MCP/skill/Claude Code plugin, nor did every framework have one:

Click to see AI tool usage

| Framework | Installed | Used by the agents? |

|---|---|---|

| Angular | Angular MCP and Angular agent skills | MCP in 3/5 runs, skill tool in 4/5 runs, skill files in 2/5 |

| Astro | Astro MCP server | MCP in 2/5 runs |

| Gracile+Lit | N/A | N/A |

| Hono+htmx | Hono skills | Skill tool in 5/5 runs |

| Next.js | next-devtools-mcp and next-dev-loop skill | Skill files in 1/5 runs, AGENTS.md in 2/5 runs |

| Nuxt | Nuxt MCP | N/A |

| Qwik | N/A | N/A |

| React Router | React Router skill | Skill tool in 5/5 runs, skill files in 5/5 runs |

| SolidStart | N/A | N/A |

| SvelteKit | Svelte Claude Code plugin | MCP in 5/5 runs |

| TanStack Start | N/A | Skill files in 2/5 runs |

| Vanilla | N/A | N/A |

For example, TanStack Start’s agent only discovered its skill files in 2/5 runs (they’re shipped in the node_modules of the project). For Nuxt, the MCP was never used by the agents. For Next.js, agents only read the skill file in 1/5 runs and the AGENTS.md in 2/5 runs. This is a wide range of results, which points back to the stochastic nature of LLMs. I still consider this a valid experiment, though, because I doubt many vibe-coders are shouting at their agents in all-caps to use the MCP (and plenty are probably skipping it entirely).

Also, if you’re wondering how I came up with Hono+htmx: essentially, I wanted htmx represented somehow, and Hono seemed like a fine pairing (i.e. as a JavaScript alternative to Rails/Django/etc.). As for Gracile+Lit, I wanted web components represented via their s