鉴川智库网

Web开发社区长期存在一种“凭感觉”决策的现象：框架常被标榜为“极快”，工具被宣称能“极大提升”效率，但这些主张往往缺乏证据支撑。随着AI代理（Agentic Era）逐渐接管代码编写，开发者对开发者体验（DX）的依赖降低，但“某框架更适合代理”等新说法依然缺乏数据验证。

为此，一项基于事实的基准测试应运而生。该测试旨在通过量化数据，评估不同JavaScript框架在AI代理构建应用时的实际表现。

实验设计与局限性

测试构建了一个基于PokéAPI的小型应用，具备搜索、过滤等功能。实验指示AI代理使用特定框架（如Next.js、SvelteKit、Angular等）的最新版本构建应用，并通过合规性测试套件防止作弊。评估维度包括开发时间、Token消耗、代码行数以及Lighthouse性能和可访问性评分。

为确保公平，每个框架均使用其官方MCP（模型上下文协议）或技能工具。代理在沙盒中运行，不知晓后续的Lighthouse测试细节。测试承认LLM输出的随机性及Lighthouse指标的波动性，因此采用多次迭代取中位数的方式以减少误差。

需要注意的是，该应用属于内容型网站，交互性较低，更接近维基百科而非复杂单页应用（SPA）。此外，测试未强制CSS方法论，仅要求避免使用Tailwind等组件库，以聚焦于JS框架、CSR与SSR、SPA与MPA的差异。

成本分析：Token与时间

成本数据基于Claude Code API价格计算。结果显示，SvelteKit、Gracile+Lit和Angular的构建成本显著高于其他框架。SvelteKit的高成本可能源于代理频繁阅读其v3迁移指南；Gracile则因代理不熟悉框架而克隆仓库或阅读源码；Angular的高成本则与其生成的代码量较大有关。

Hono+htmx表现出较高的成本效益。尽管React Router的中位数成本略高，但其最低成本版本仍低于Hono+htmx的最高成本版本，显示出较大的方差。

在工具使用方面，代理对各框架MCP/技能的调用频率差异巨大。例如，React Router在5次运行中均使用了技能工具和文件，而Nuxt的MCP从未被调用，Next.js仅在少数运行中读取了技能文件。这种随机性反映了当前LLM行为的不确定性。

值得注意的是，“Vanilla”（原生JS+Vite）的表现不如多个框架，表明在AI辅助下，拥有某种框架结构可能比完全裸写更具优势。

质量评估：性能与可访问性

Lighthouse测试显示，大多数框架在累积布局偏移（CLS）、性能和可访问性得分上均接近饱和（CLS多为0.000，可访问性多为100分）。因此，传输的JavaScript字节数、总阻塞时间（TBT）和最大内容绘制（LCP）成为更具区分度的指标。

• JavaScript字节数：直接反映客户端框架的大小，多页面应用（MPA）框架通常具有更小的包体积。
• 总阻塞时间（TBT）：数值普遍较小，但MPA框架因主线程占用少而占优。
• 最大内容绘制（LCP）：MPA框架因能快速渲染HTML而普遍优于SPA。Qwik是例外，作为客户端路由的SPA，其LCP表现与MPA相当。

Next.js和Astro在LCP上表现出较大方差，主要受图像懒加载策略及优先级设置影响。Angular在部分运行中因SSR配置问题导致失败，未被计入有效数据。

可维护性：代码行数

代码行数是衡量可维护性的直观指标。数据显示，Hono+htmx仅需约Angular 70%的代码量即可实现相同功能，且构建速度更快。这印证了在AI代理时代，代码简洁性直接关联Token消耗及长期维护成本。

结论与启示

本测试并非旨在判定“最佳框架”，而是证明在AI编码时代，技术选型应基于证据而非直觉。结果表明，MPA框架在性能指标上通常优于SPA，而轻量级组合（如Hono+htmx）在成本和代码效率上表现突出。

框架作者可通过优化MCP和技能工具来提升AI协作效率。对于开发者而言，在将代码生成交给AI时，重新审视技术栈选择的依据显得尤为重要。是继续沿用习惯，还是根据性能、成本和可维护性的实证数据进行选择？这一转变或许将推动Web开发向更高效、更 accessible 的方向演进。

附录：测试框架版本