审视JavaScript框架带来的AI成本

Web 开发社区最让我反感的一点是，我们做出的大多数决策都基于“感觉（Vibes）”。框架总是“快如闪电（blazing fast）”，工具会让你的开发过程“如虎添翼（supercharge）”，正确的抽象既能造福开发者又能造福用户（开发体验 DX 与用户体验 UX 二合一！

）。所有这些气喘吁吁的吹嘘通常都拿不出任何证据。Alex Russell 称之为“前端失去的十年（frontend’s lost decade）”，Baldur Bjarnason 认为编程不过是一种流行文化，而我则一直在博客中试图用事实和基准测试来对抗这种趋势（至少在状态好的时候是这样）。

很长一段时间里，我们社区对证据的排斥似乎是由对更好 DX 的追求驱动的。换句话说，开发者就是喜欢在 React 中手敲 JSX 的感觉，而推广 React 或相关工具的论点（“虚拟 DOM 很快！”）在很大程度上只是为了证明最初直觉正确的事后合理化解释。（Jonathan Haidt 可能会同意这一评估。）

但在代理时代（agentic era），当开发者不再需要亲手编写代码、从而较少受 DX 约束时，我依然看到感觉主导着一切（不仅仅是在“氛围编程（vibe-coding）”的意义上）。

前端被重写，仅仅是因为某个框架“对代理更好”。（有人想过去问问代理吗？）由此产生的代码“更快”，代理犯的“错误更少”，等等。同样的，这些说法往往也是在没有证据的情况下提出的。每当我读到这样的陈述时，我心里就会想：“基准测试在哪里？”

所以我产生了好奇，于是我写了一个基准测试。这个基准测试的结构非常直接：

· 使用 PokéAPI 设计一个小型但并非不重要的宝可梦应用（Pokémon app）（关注过我的工作的读者对此应该不会感到意外）

· 指导代理使用特定的 JavaScript 框架/元框架（例如 Next.js、Nuxt、SvelteKit 等）来构建该应用

· 针对规范符合性测试套件测试输出结果（以防代理作弊）

· 从开发时间、消耗的 Token、代码行数、以及 Lighthouse 中的性能和可访问性评分来评估结果

这个应用相当简单：你有一个宝可梦列表，包含它们的属性、招式以及来自各个游戏的数据。你可以进行搜索、筛选等操作：

我首先需要说明一些注意事项：这不是一个完美的实验。这个应用只代表了一种整体模式（holotype）——它是一个相对基于内容、互动性很强的网站，更接近 Wikipedia 而不是 Figma 或 GMail 等。话虽如此，我总得选个应用来构建，而这个应用至少在宏观层面上很容易理解，并且在制定规范和测试时相对简单直接。

为了尽量公平起见，我让每个框架/元框架（meta-framework）都使用该工具官方的 MCP 或技能（skills）。我希望避免诸如“这个框架在训练数据中代表性不足，所以我们构建了自己的 MCP，我们期望人们使用它”之类的指责。

我也没有过度指定要使用的具体架构（例如 SSR 与 CSR），也没有要求应用程序必须尽可能地具备高性能。我只是将规范交给了高投入的 Opus 5.5，并告诉它使用给定框架的最新版本。

每个代理（agent）都在沙盒中运行，并且在运行过程中并不知道它将在 Lighthouse 的性能和无障碍访问（accessibility）方面接受测试，不过它获得了合规性测试套件（conformance test suite）。

请注意，除了避免使用 Tailwind、Bootstrap 或任何其他组件框架，以及要求基于一组规范标记（spec tokens）进行设计以强制实现一定的视觉一致性之外，我也没有强制规定任何 CSS 方法论。

我不想让这次测试完全变成关于 CSS 的测试，而是关于 JS 框架、CSR 与 SSR、SPA 与 MPA 等方面的测试。最终生成的应用程序将针对基于无障碍树（accessibility tree）而非原始 DOM 的合规性套件进行测试，以避免强制规定任何特定的 HTML 结构——其中一个框架使用了依赖于 Shadow DOM 的 Web Components，因此这是必需的。

我从这次实验中学到的一点是，我所测量的一切都具有高度的随机性。大语言模型（LLMs）是随机词生成器，所以有时你会遇到较差的骰子点数，代理会走上某些奇怪的切入路线，浪费大量的 Token，这并不是框架或其工具本身的错。

Lighthouse 本身也可能会给出不一致的结果：最大内容绘制（Largest Contentful Paint, LCP）可能会判定某张图片是“最大”的元素，然后在下一次运行中又选择另一张。要做到完全公平的实验很困难，但运行多次迭代确实有所帮助，我也尽量如实呈现了方差。

抛开这些冗长的开场白不谈，让我们来看一下结果。

结果

我将从多个维度来剖析这些结果：构建成本、质量和可维护性。对于每个框架/元框架，我取了 5 次运行的中位数：换句话说，我在同一个框架中把同一个应用构建了 5 次。（是的，这就是如今利用编码代理你可以做出的那种疯狂的事情。）

唯一的例外是 Angular，它有两次未能创建出可工作的应用，所以我只取了 3 次迭代。（原因将在下文解释。）

单次运行成本（单位：美元）

Framework Cost ($)

Hono+htmx $2.67 (2.23–3.19)−0.44+0.52

Astro $2.76 (2.16–3.63)−0.60+0.87

Nuxt $2.82 (2.39–4.25)−0.43+1.43

Vanilla $2.98 (2.24–3.37)−0.74+0.39

Next.js $3.14 (2.58–4.13)−0.56+0.99

Qwik $3.27 (2.35–3.80)−0.92+0.53

TanStack Start $3.54 (3.11–3.96)−0.43+0.42

SolidStart $3.79 (2.84–4.81)−0.95+1.02

React Router $3.81 (2.82–3.97)−0.99+0.16

SvelteKit $4.28 (3.59–4.65)−0.69+0.37

Gracile+Lit $4.65 (3.92–5.07)−0.73+0.42

Angular $4.97 (3.19–6.82)−1.78+1.85

02468

3至5次运行的中位数。

Sort Show as table

请注意，这直接引用了来自 Claude Code 的 API 价格，并不代表我实际花费了多少钱。我使用的是 Max 计划（Max plan），所以这只是我总共每月 100 美元费用的一部分。

还要注意其中的差异：React Router 的中位数比 Hono+htmx 大约贵 1 美元，但 React Router 最便宜的版本（$2.82）仍然比 Hono+htmx 最贵的版本（$3.19）便宜。不过，一些可靠的模式确实显现出来了。

最明显的是，SvelteKit、Gracile+Lit 和 Angular 的构建成本比其他框架更高。对于 SvelteKit 而言，这可能是因为 Agent 在每次运行中都会读取 SvelteKit v3 迁移指南，很可能是因为该版本太新，尚未包含在 Opus 5.5 的训练数据中。

对于 Gracile 来说也是类似的情况，Agent 对该框架不太熟悉，要么克隆了 Gracile 仓库，要么从 node_modules 读取了其编译后的源码。对于 Angular 来说，这似乎是总代码大小的一个函数（见下文）。

我还应该提到，并非每个 Agent 都使用了 MCP（Model Context Protocol）/技能（skill）/Claude Code 插件，也并非每个框架都有这些工具：

点击查看 AI 工具使用情况

框架 是否安装 是否被 Agent 使用？

Angular Angular MCP 和 Angular agent skills 3/5 的运行中使用了 MCP，4/5 的运行中使用了 skill 工具，2/5 使用了 skill 文件

Astro Astro MCP server 2/5 的运行中使用了 MCP

Gracile+Lit 不适用（N/A） 不适用（N/A）

Hono+htmx Hono skills 5/5 的运行中使用了 skill tool

Next.js next-devtools-mcp 和 next-dev-loop skill 1/5 的运行中使用了 skill 文件，2/5 的运行中使用了 AGENTS.md

Nuxt Nuxt MCP 不适用（N/A）

Qwik 不适用（N/A） 不适用（N/A）

React Router React Router skill 5/5 的运行中使用了 skill tool，5/5 的运行中使用了 skill 文件

SolidStart 不适用（N/A） 不适用（N/A）

SvelteKit Svelte Claude Code plugin 5/5 的运行中使用了 MCP

TanStack Start 不适用（N/A） 2/5 的运行中使用了 skill 文件

Vanilla 不适用（N/A） 不适用（N/A）

例如，TanStack Start 的 Agent 仅在 2/5 的运行中发现了它的 skill 文件（它们随项目的 node_modules 一起发布）。对于 Nuxt，MCP 从未被 Agent 使用过。

对于 Next.js，Agent 仅在 1/5 的运行中读取了 skill 文件，在 2/5 的运行中读取了 AGENTS.md。这是一个跨度很大的结果，这也指向了 LLM 的随机性本质。

不过，我仍然认为这是一个有效的实验，因为我怀疑没有多少“氛围编程者（vibe-coders）”会用全大写字母冲着他们的 Agent 大喊去使用 MCP（而且很多人可能完全跳过了它）。

另外，如果你想知道我是如何想到 Hono+htmx 这个组合的：本质上，我希望 htmx 能以某种方式得到体现，而 Hono 似乎是一个不错的搭配（即作为 Rails/Django 等框架的 JavaScript 替代品）。至于 Gracile+Lit，我希望 Web 组件（web components）能够得到代