过去十几年，JavaScript 框架之间的竞争，主要围绕开发体验、运行性能和工程效率展开。React、Angular、Vue 等框架各自形成了庞大的开发者生态，框架选择往往与团队技术积累、开发习惯甚至技术偏好密切相关。
但当 AI Agent 开始承担越来越多的代码编写工作，这套评价标准可能正在发生变化：越来越多开发者开始关注哪种框架更适合 AI Agent 编程，能让模型更快完成任务、少消耗 Token，同时生成更容易维护的代码？
近日，前 Microsoft Edge 浏览器性能项目经理、资深 Web 开发者 Nolan Lawson 让 AI Agent 分别使用 12 种 JavaScript 框架构建同一个 Pokémon 应用，并从开发成本、Token 消耗、开发时间、最终产品性能和代码维护规模等维度进行了比较。
结果显示，同样的应用开发任务，最便宜的 Hono+htmx 中位成本为 2.67 美元，而 Angular 达到 4.97 美元，接近前者的两倍。Token 消耗方面，Angular 达到 976 万，Hono+htmx 为 426 万，相差约 2.3 倍。与此同时，不同框架生成的应用在 JavaScript 体积、浏览器主线程阻塞时间和代码规模方面也呈现出明显差异。
Lawson 借此提出一个值得整个行业重新思考的问题：当开发者不再亲手编写每一行代码，过去那些围绕开发体验形成的技术选型，是否还应该原样保留？
同一应用，Angular 成本近翻倍，Token 消耗超两倍
参与这次测试的有 12 个框架：Angular、Astro、Gracile+Lit、Hono+htmx、Next.js、Nuxt、Qwik、React Router、SolidStart、SvelteKit、TanStack Start，以及不使用 UI 框架、仅采用 Vanilla JavaScript/TypeScript 和 Vite 的方案。
实验统一使用 Claude Opus 5.5，并设置 High 推理强度，要求 Agent 使用对应框架的最新版本。每个框架原则上运行 5 次，每次都在独立沙箱中完成开发。作者没有提前告诉 Agent 应用将接受 Lighthouse 性能和可访问性测试，也没有指定必须使用 SSR 还是 CSR，更没有要求 Agent 必须采用特定的性能优化方案。
为了尽可能公平，Lawson 为各框架安装了官方提供的 MCP、Skills 或 Claude Code 插件（如果有），但没有强制 Agent 必须调用这些工具。CSS 方面，他没有限定具体方法，只要求不要使用 Tailwind、Bootstrap 或其他组件框架，并通过统一的设计规范保持视觉一致性。
为了尽可能控制变量，Lawson 没有让 Agent 随意开发不同类型的项目，而是要求所有框架完成同一个基于 PokéAPI 的宝可梦图鉴应用。应用包含宝可梦列表、属性、技能和游戏版本数据，并支持搜索、筛选等功能。
需要说明的是，Angular 有两次测试出现了特殊情况：Agent 虽然生成了 SSR 应用，但应用拒绝来自 localhost 以外的访问，不符合测试要求。Lawson 将其视为未按规范完成任务，没有重新运行。因此，代码规模和性能指标仅采用 3 次有效测试结果，而成本统计仍保留全部 5 次结果。
首先是最直观的开发成本。结果显示，Hono+htmx、Astro 和 Nuxt 在 AI 构建成本方面表现突出：Hono+htmx 以 2.67 美元排名第一，Astro 为 2.76 美元，Nuxt 为 2.82 美元；而 Angular、Gracile+Lit 和 SvelteKit 的成本相对较高。其中，Angular 单次构建的估算成本达到 4.97 美元，接近 Hono+htmx 的 1.86 倍。
这些价格是 Claude Code 按照 API 价格计算的 Token 成本估算，并非 Lawson 实际支付的独立账单。Lawson 使用的是每月 100 美元的 Claude Max 套餐，因此测试本身属于订阅额度内的使用。
成本差异背后，Token 消耗和开发时间也呈现出相似趋势。
开发时间方面，Astro 表现最好，单次构建中位数为 8.2 分钟，Hono+htmx 为 8.6 分钟，Nuxt 为 9 分钟。Angular 则需要 17.2 分钟，是 Astro 的两倍还多。
Token 消耗也呈现出类似趋势。Nuxt 单次构建消耗约 385 万 Token，Astro 约 413 万，Hono+htmx 约 426 万；Angular 则达到 976 万 Token，是 Nuxt 的约 2.5 倍。TanStack Start、SolidStart 和 React Router 的 Token 消耗也相对较高，分别达到 707 万、713 万和 758 万。
这意味着，即使使用同一个模型、相同的任务要求，选择不同的框架，Agent 完成工作的成本和时间也可能出现明显差异。
不过，Lawson 也提醒，成本和 Token 数据存在较大波动。例如 React Router 的中位成本比 Hono+htmx 高约 1 美元，但前者最便宜的一次测试只花费 2.82 美元，仍低于后者最贵的一次 3.19 美元。因此，不能把单次测试的差异直接理解为框架之间必然存在固定的成本差距。
整体来看，SvelteKit、Gracile+Lit 和 Angular 的开发成本相对较高。其中，SvelteKit 的一个可能原因是版本较新，Agent 在每次测试中都会阅读 SvelteKit v3 迁移指南，可能是因为 Opus 5.5 的训练数据中缺乏足够的新版本信息。
Gracile 的情况更加明显，由于 Agent 对该框架不熟悉，有时会直接克隆整个代码仓库，甚至阅读 node_modules 中的编译后源码。Angular 的高成本则更多与最终生成的代码规模有关。
这也暴露出一个此前容易被忽略的问题：框架是否容易被模型理解，正在成为技术选型的新变量。
MCP、Skills 没想象中好用，Agent 甚至经常不看
为了避免某些框架因为缺乏 AI 工具支持而在测试中吃亏，Lawson 尽可能为各框架安装了官方 MCP、Skills 或 Claude Code 插件。但实验结果显示，Agent 对这些工具的实际使用情况并不稳定。
Lawson 认为，这种情况恰恰符合真实的 AI Coding 使用场景。普通开发者并不会每次都用大写命令反复要求 Agent 调用 MCP 或读取 Skills，很多人甚至根本不会主动配置这些工具。
此外，Lawson 还解释了部分测试方案的选择原因。Hono+htmx 是为了让 htmx 进入对比，同时将 Hono 作为一种 JavaScript 版的 Rails/Django 式方案；Gracile+Lit 则是为了代表 Web Components 生态。
对于 Vanilla，Lawson 要求 Agent 使用不带 UI 框架的原生 JavaScript 或 TypeScript，并通过 Vite 构建。结果却显示，原生方案的表现并没有优于所有框架，甚至在成本和 Token 消耗方面不如部分框架。
生成的应用也有性能差异
前面回答了“AI 写代码需要花多少钱”的成本问题，最终生成的应用性能则回答了：花了这些 Token，最后交付的产品质量究竟如何？
Lawson 使用 Lighthouse 对生成的应用进行了性能和可访问性测试。他认为，软件开发不能只追求低成本，还需要关注最终产品是否足够高效、易用。
首先，从 Lighthouse 的整体评分来看，12 种框架的差距并不大。除了 Vanilla 的 CLS（累计布局偏移）为 0.111、性能得分为 97 分，Angular 性能得分为 98 分、TanStack Start 为 99 分外，其余方案基本都达到了 100 分的性能和可访问性评分，CLS 也普遍为 0。
由于整体评分已经非常接近满分，Lawson 进一步比较了 JavaScript 传输体积、总阻塞时间（TBT）和最大内容绘制时间（LCP）等具体指标。
在 JavaScript 传输体积方面，Astro 最轻，仅为 0KiB（测试范围 0—1KiB）；Vanilla 为 7KiB，Gracile+Lit 为 8KiB，Hono+htmx 为 18KiB。相比之下，Next.js 达到 142KiB，TanStack Start 为 118KiB，React Router 为 115KiB。
更值得注意的是 TBT。总阻塞时间衡量浏览器主线程被长任务阻塞的时间，数值越高，意味着页面在加载过程中主线程被占用的时间越长，可能影响用户的交互响应。
实验中，Astro、Gracile+Lit、Hono+htmx、SvelteKit 和 Vanilla 的 TBT 中位数均为 0ms；TanStack Start 为 1ms，Qwik 为 3ms，SolidStart 为 11ms，React Router 为 17ms，Nuxt 为 40ms。Next.js 达到 71ms，Angular 则达到 103ms。
Lawson 特别指出，TBT 并不完全取决于 JavaScript 传输体积。例如，Angular 的 JavaScript 传输体积为 93KiB，低于 Next.js 的 142KiB，但它的 TBT 反而更高。这说明，浏览器主线程的实际执行负担不仅与代码下载量有关，还受到代码解析、执行以及框架运行机制等因素影响。
在 LCP（最大内容绘制）方面，Astro 以 810ms 位居第一，Gracile+Lit 为 956ms，Hono+htmx 为 978ms，Qwik 为 979ms。Next.js 达到 2090ms，TanStack Start 为 2028ms，Angular 为 1954ms。
LCP 的波动明显高于其他指标。Lawson 发现，Next.js 的一次测试没有使用图片懒加载，而另外四次使用了懒加载，这直接造成了结果差异。Astro 和 Vanilla 也出现了类似波动，可能与资源优先级和 LCP 对最大元素的识别变化有关。
总体而言，LCP 测试更倾向于奖励能够快速返回 HTML 的 MPA（多页面应用），而不是需要等待客户端 JavaScript 执行、甚至还需要多次网络请求获取数据的 SPA（单页面应用）。从这次实验来看，LCP 在很大程度上与 JavaScript Bundle 体积相关。不过，Qwik 是一个例外：它采用客户端路由，技术上属于 SPA，但最终得分接近 MPA 方案。
不过，Lawson 指出，Lighthouse 和 Core Web Vitals 本身就存在对 SPA 不够友好的倾向，因此不能直接将这组结果理解为 SPA 在所有应用场景下都不如 MPA。
代码越少，AI 维护也可能越便宜
除了开发成本和最终产品性能，Lawson 还比较了各框架生成代码的规模，并将其作为衡量可维护性的一个简单指标。
他没有采用复杂的圈复杂度等指标，而是直接统计非空源代码行数。结果显示，Hono+htmx 只生成 1370 行代码，是所有方案中最少的；Nuxt 为 1415 行，Astro 为 1461 行，Next.js 为 1539 行。Angular 则达到 2009 行，是所有方案中最多的。
这组结果让 Lawson 特别关注。他引用了 Svelte 创始人 Rich Harris 的一句话：“框架不是组织代码的工具，而是组织思想的工具。”
在 Lawson 看来，框架的意义本来就是减少需要维护的代码。但在 Agent 时代，这个问题变得更加重要，因为代码规模最终会影响 Token 消耗，不仅是最初生成代码时的成本，也包括未来每次修改、调试和重构时的成本。
在这次实验中，Hono+htmx 使用约 1370 行代码，就完成了与 Angular 约 2009 行代码相同的应用功能，代码量约为后者的 68%，同时开发成本更低、速度也更快。
Lawson 也强调，简洁并不是框架唯一值得追求的价值，但在 AI Agent 成为主要代码生产者的背景下，框架能否减少代码规模，显然值得重新纳入技术选型标准。
以后怎么选框架？开发者吵起来了
Lawson 在文章中提出，Web 开发社区长期存在一个问题：技术选型经常依赖主观感受，而不是可靠的测试数据。某个框架被宣传为速度更快、开发效率更高，另一个工具则被认为更适合 AI Agent，但这些结论往往缺乏足够的实验证据。
他认为，随着 AI Agent 逐渐取代开发者完成大量具体编码工作，过去围绕开发者体验建立的技术选型逻辑也需要重新审视。如果开发者不再亲自逐行编写代码，那么选择框架时，就应该更加关注 Agent 能否稳定理解文档、完成任务，以及最终生成的应用是否足够高效、易于维护。
Lawson 的实验发布后，立刻引发了社区的争论。有人要回归原生，有人认为框架反而更重要了。
一部分开发者认为，AI 正在削弱传统框架存在的必要性。过去，框架最大的价值之一是帮助人类开发者组织代码、管理复杂状态和提高协作效率，但这些工作如今可以交给 AI 完成。对于内容展示、信息检索等交互相对简单的网站，直接使用 HTML、CSS 和原生 JavaScript，可能比引入 React 等大型框架更加经济。有人甚至直言，既然 AI 已经能够写代码，就没有必要继续沿用过去为了方便人类开发者而建立的复杂技术体系。
另一派开发者则认为，框架在 AI 时代不仅没有过时，反而可能更加重要。有开发者分享，自己尝试让大模型使用原生 JavaScript 开发后，代码缺陷逐渐增加，最终重新选择 React。React 稳定的 API 和相对成熟的编程模式，更容易被模型理解，也有利于减少实现过程中的混乱。还有人认为，框架为长期项目提供了必要的工程约束，能够减少 Agent 在复杂代码中反复踩坑的概率。
讨论还延伸到了企业的软件工程管理。一名开发者认为，他分享了所在团队在不到 5 年内，从 Backbone、Angular、React、Ember、Next.js、Vue、Svelte，最终又回到 Angular 和 React 的经历。频繁重构让管理者获得了新的项目成果，却可能留下仓促交付的代码和不断增加的技术债。过去十多年 JavaScript 框架频繁更迭，部分原因并不是业务真的需要，而是企业招聘、技术选型和管理层追逐流行技术共同推动的结果。
也有开发者反驳称，框架并不只是技术潮流的产物。对于商业软件和大型应用，框架背后还有持续维护的开源社区、成熟的组件生态和经过验证的工程实践。如果企业完全抛弃现有框架，转而自行构建状态管理、响应式更新和组件体系，最终可能只是重新发明一套维护成本更高的框架。AI 虽然能够加速代码维护，却并不意味着软件维护本身已经消失。
不过，这项实验并不是一份可以直接用于所有项目的框架排行榜。测试只覆盖一个以内容展示为主、交互相对简单的宝可梦应用，并不能代表复杂仪表盘、邮件系统、设计工具或大型企业应用。Lawson 希望通过这次实验说明，在 AI 编程时代，技术选型依然可以通过数据和 Benchmark 来验证，而不是继续依靠社区口碑和主观判断。
对于已经高度依赖 AI Agent 的软件团队而言，这项实验提出了一个值得重新考虑的问题：过去开发者选择框架，是为了让自己写代码更舒服；未来选择框架，可能还需要考虑让 AI 写代码更省 Token、开发更快、生成的代码更少，并且让后续维护成本更低。
有开发者分享，自己使用 AI 开发 HTMX 项目时，简单页面效果不错，但遇到复杂表单和状态管理后，Agent 经常出现页面加载缓慢、状态丢失等问题。他认为，如果改用 React，Agent 可能一次就能完成。不过，他最终通过增加测试约束，让 Agent 逐步解决了这些问题，保留了 HTMX 方案，而且最终性能甚至超过了他认为 React 能够达到的水平。
相反，也有人认为，React 的流行程度和大量现成代码示例，让模型更容易掌握其开发模式。技术栈是否适合 AI，不仅取决于框架本身，还取决于模型训练数据、文档质量、工具支持和实际任务复杂度。
这场讨论没有统一答案，但一个变化已经比较明确：AI 正在迫使开发者重新审视过去的技术选型标准。框架不再只是帮助人类更方便地编写代码，也需要证明自己能够帮助 Agent 更准确地理解项目、更少地生成错误，并降低后续维护成本。
参考链接：
https://nolanlawson.com/2026/10/28/the-ai-cost-of-javascript-frameworks/
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
Over the past decade or so, competition between the JavaScript framework has focused on development experience, operational performance and engineering efficiency. Frameworks such as React, Angular, and Vue each form a vast developer's ecology, and framework choices are often closely linked to team technology accumulation, development habits and even technological preferences.
But as AI Agent begins to take on more and more code writing, this set of evaluation criteria may be changing: more and more developers are beginning to focus on which framework is more suitable for AI Agent programming, allowing models to perform their tasks faster, less consuming Token, and generating codes that are easier to maintain?
In recent days, former Microsoft Edge Browser Performance Project Manager, Senior Web Developer Nolan Lawson, allowed AI Agent to construct the same Pokémon application using 12 JavaScript frames, comparing the dimensions of development costs, Token consumption, development time, end product performance and code maintenance.
The results show that the cheapest medium cost of the Hono+htmx was $2.67 for the same application development mission, while Angular reached $4.97, nearly twice the former. For Token consumption, Angular amounted to 9.76 million and Hono+htmx to 4.26 million, a difference of approximately 2.3 times. At the same time, applications generated by different frameworks show significant differences in JavaScript volume, browser main route block time and code size.
Lawson asks a question worth rethinking the whole industry: Should the technology models built around the development experience be retained when the developers no longer prepare each line of code themselves?
The same application, Angular cost nearly doubled, Token consumes more than twice.
There are 12 frameworks involved in this test: Angular, Astro, Gracile+Lit, Hono+htmx, Next.js, Nuxt, Qwik, React Router, SolidStart, SvelteKit, TanStack Start, and programmes that do not use the UI framework and only use Vanilla JavaScript/ TypeScript and Vite.
The experiment uses Claude Opus 5.5 in a uniform manner, and sets the High reasoning strength, requiring Agent to use the latest version of the corresponding frame. Each framework operates in principle five times and is developed in a separate sandbox each time. The author did not inform Agent that the application would be subject to the Lighthouse performance and accessibility test, nor did he specify whether SSR or CSR must be used, nor did he require Agent to have a specific performance optimization scheme.
In order to be as fair as possible, Lawson has installed officially available MCP, Skills or Claude Code plugins (if any) for the frameworks, but has not made it mandatory for Agent to call on these tools. On the CSS side, he did not define a specific method, but simply asked not to use Tailwind, Bootstream or other component frameworks and to maintain visual consistency through uniform design specifications.
To control the variables as much as possible, Lawson does not allow Agent to develop different types of projects at will, but requires all frameworks to complete the same PokéaPI-based dream-based application. Apply data containing dreamable lists, attributes, skills and game versions, and support search, filter, etc.
It is important to note that two tests in Angular have had exceptional circumstances: while Agent generated an SSR application, the application refused access from outside the localhost and did not meet the test requirements. Lawson considers it as a failure to fulfil its mandate as required and has not re-run. Therefore, code size and performance indicators use only three valid test results, while cost statistics retain all five results.
The first is the most intuitive development cost. The results showed that Hono+htmx, Astro and Nuxt performed well in AI construction costs: Hono+htmx ranked first at $2.67, Astro at $2.76 and Nuxt at $2.82; and Angular, Gracile+Lit and SvelteKit costs were relatively high. Of these, the estimated cost of the single construction of Angular amounted to $4.97, close to 1.86 times the Hono+htmx.
These prices are Token cost estimates based on Claude Code ' s API prices and are not separate bills actually paid by Lawson. Lawson uses a $100-a-month Claude Max package, so the test itself is used in subscription to quota.
Behind the cost differences, Token consumption and development time show similar trends.
In development time, Astro performed best with 8.2 minutes median for single construction, 8.6 minutes for Hono+htmx and 9 minutes for Nuxt. Angular takes 17.2 minutes, more than twice as many as Astro.
Token consumption shows a similar trend. Nuxt One-time construction consumes about 3.85 million Token, Astro about 4.13 million, Hono+htmx about 4.26 million, and Angular up to 9.76 million Token, about 2.5 times Nuxt. Token consumption in TanStackStart, SolidStart and React Router was also relatively high at 7.07 million, 7.13 million and 7.58 million respectively.
This means that even using the same model, the same mission requirements, and choosing different frameworks, Agent ' s cost and time of completing the work may vary significantly.
Lawson, however, also cautions that costs and Token data are highly volatile. For example, the median cost of React Router is about US$ 1 more than the Hono+htmx, but the former cost only US$ 2.82 for the cheapest test and still less than the latter ' s most expensive one, US$ 3.19. Therefore, the difference in the single test cannot be directly understood as the inherent fixed cost gap between frameworks.
Overall, SvelteKit, Gracile+Lit and Angular have relatively high development costs. One of the possible reasons for SvelteKit is that the version is relatively new and Agent will read the SvelteKit v3 migration guide for each test, possibly because of the lack of sufficient new version information in Opus 5.5 training data.
Gracile is even more obvious, as Agent is not familiar with the framework and sometimes clones the entire code warehouse directly, even reading the compiled source code in the code modules. The high cost of Angular is more related to the size of the code eventually generated.
This also exposes a problem that was previously easily overlooked: Whether the framework is easily understood by the model is becoming a new variable of technical choice.
MCP, Skills, it's not as good as it looks, Agent.
To avoid the risk of some frameworks being tested for lack of AI support, Lawson has installed, to the extent possible, official MCP, Skills or Claude Code plugins for the frameworks. However, experimental results indicate that the actual use of these tools by Agent is not stable.
Lawson believes that this is exactly what the real AI Coding uses. Ordinary developers do not always ask Agent to call MCP or read Skills with capital commands, and many do not even have the initiative to configure these tools.
In addition, Lawson explained why some of the testing options were selected. Hono+htmx is intended to allow htmx to enter the comparison, while Hono is used as a Raws/Django version of JavaScript; Gracile+Lit represents Web Components ecology.
For Vanilla, Lawson requests Agent to use the original JavaScript or TypeScript without the UI framework, and build through Vite. The results show that primary programmes do not perform better than all frameworks, even less than some in terms of costs and token consumption.
There's also a difference of performance in the applications generated.
The question of the cost of “how much is it going to cost for AI to write” has been answered earlier, and the application performance that was eventually generated: what is the quality of the product that was finally delivered?
Lawson used Lighthouse to test the performance and accessibility of the resulting applications. In his view, software development could not only be low-cost, but also focus on whether the end product was efficient and easy to use.
First of all, from the overall rating of Lighthouse, the 12 frameworks are not very different. With the exception of Vanilla ' s CLS (cumulative layout deviation) with 0.111, performance score of 97, Angular performance score of 98, and TanStack Star, 99, the remaining schemes have basically reached 100, performance and accessibility rating of 0, and CLS is common.
As the overall rating is very close to full, Lawson further compares the specific indicators of JavaScript transfer volume, total blockage time (TBT) and maximum content time (LCP).
In JavaScript transport volume, Astro is the lightest, only 0KiB (test range 0-1KiB); Vanilla is 7KiB, Gracile+Lit is 8KiB, Hono+htmx is 18KiB. By contrast, Next.js reaches 142 KiB, TanStack Star is 118 KiB, React Router is 115 KiB.
More notably, TBT. The higher the value of the total block time measure the time when the browser main route is blocked by a long task, the longer the main route is occupied during the loading of the page, which may affect the interactive response of the user.
In the experiment, the median TBT values for Astro, Gracile+Lit, Hono+htmx, SvelteKit and Vanilla were 0ms; TanStackStart was 1 ms, Qwik was 3 ms, SolidStart was 11 ms, React Router was 17 ms and Nuxt was 40 ms. Next.js reaches 71ms and Angular 103ms.
Lawson notes in particular that TBT does not depend entirely on JavaScript transport volume. For example, the JavaScript transport volume in Angular is 93KiB, less than the 142KiB in Next.js, but its TBT is higher. This indicates that the actual implementation burden of the browser main route is not only related to the volume of code downloads but is also influenced by factors such as code interpretation, implementation and framework operating mechanisms.
In LCP (maximum content mapping), Astro ranked first with 810 ms, Gracile+Lit with 956 ms, Hono+htmx with 978 ms and Qwik with 979 ms. Next.js reaches 2090m, TanStackStart 2028m and Angular 1954m.
LCP fluctuations are significantly higher than other indicators. Lawson found that Next.js did not use laziness in one test, while four others used laziness, which directly resulted in a difference of results. Similar fluctuations have occurred in Astro and Vanilla, which may be related to resource priorities and changes in the identification of the largest elements by LCP.
In general, LCP tests tend to reward the quick return of the HTML MPA (multipage application) rather than the SPA (single page application) that needs to wait for the client JavaScript to execute, and even multiple web requests for data. From this experiment, LCP is largely associated with JavaScript Bundle. However, Qwik is an exception: it uses a client route and is technically SPA, but ultimately scores close to the MPA scheme.
However, Lawson points out that Lighthouse and Core Web Vitals themselves have a tendency to be less friendly to the SPA, so that the results cannot be directly understood to mean that the SPA is worse than the MPA in all applications.
The fewer codes, the less AI, the cheaper the maintenance.
In addition to development costs and end-product performance, Lawson compares the size of the codes generated by the frameworks and uses them as a simple measure of maintenanceability.
Instead of using such indicators as complex circle complexity, he directly counted non-empty source lines. The results show that Hono+htmx generates only 1370 line codes, which are the smallest of all programs; Nuxt is 1415 line, Astro is 1461 line, Next.js is 1539 line. Angular reaches line 2009, the largest of all programs.
This set of results is of particular interest to Lawson. He quotes Svelte's founder, Rich Harris, who says, "The framework is not an organizational code, but an organizational idea."
In Lawson, it seems that the purpose of the framework is to reduce the number of codes that need to be maintained. But in the Age of Agent, the issue became even more important, because the size of the code ultimately affected token consumption, not only in terms of the cost of first generation of the code, but also in terms of the cost of every modification, debugging and restructuring in the future.
In this experiment, Hono+htmx used approximately 1370 line codes, completing the same application function as the Angular 2009 line code, with a code volume of about 68 per cent of the latter, with lower and faster development costs.
Lawson also stressed that simplicity was not the only value that the framework was worth pursuing, but that, in the context of AI Agent becoming a major code producer, whether the framework could reduce the size of the code was clearly worth reinstating the technical selection criteria.
How do you choose the frame? The developers are arguing.
Lawson argues that the Web development community has a long-standing problem: technology selection often relies on subjective perceptions rather than reliable test data. One framework is promoted as faster and more efficiently developed, while another tool is considered more suitable for AI Agent, but these findings often lack sufficient empirical evidence.
In his view, as AI Agent gradually replaced developers with a large number of specific coding tasks, the technology selection logic built in the past around the development experience also needed to be revisited. If the developer does not write the code in person, then the frame selection should be more focused on Agent ' s ability to understand the document in a stable way, to perform the task, and to generate applications that are efficient and easy to maintain.
Immediately after Lawson ' s experiment publish, the debate in the community started. There are those who want to return to their original origins, and there are those who believe that the framework is more important.
Some developers believe AI is weakening the need for traditional frameworks. In the past, one of the greatest values of the framework was to help human developers organize the code, manage the complexity and improve the efficiency of collaboration, but these can now be done by AI. Direct use of HTML, CSS and original JavaScript may be more economical than introducing large frameworks such as React. Some even put it bluntly, since AI is already able to write codes, there is no need to continue to follow the complex technological system that was built in the past to facilitate human developers.
Another developer argued that the framework was not obsolete in the AI era, but could be even more important. A developer shared it and tried to get LLM to use the original JavaScript to develop it, and the code defects increased and eventually re-chosen React. React stable API and relatively mature programming models are easier to understand by models and help reduce confusion in implementation. The view was also expressed that the framework provided the necessary engineering constraints for long-term projects and could reduce the probability that Agent would re-strike pits in complex codes.
Discussions also extended to software engineering management at the enterprise. According to one developer, he shared the experience of his team in less than five years, from Backbone, Angular, React, Ember, Next.js, Vue, Svelte, and eventually back to Angular and React. Frequent re-engineering has allowed managers to obtain new project results, leaving behind the code of hasty delivery and increasing technical debt. The JavaScript framework has changed frequently over the past decade, partly because business needs are not real, but rather because corporate recruitment, technology selection and management have contributed to the pursuit of popular technologies.
It has also been countered by developers that the framework is not just a product of technological currents. For commercial software and large-scale applications, the framework is backed by open-source communities that are continuously maintained, mature component ecology and proven engineering practices. If an enterprise completely abandons the existing framework and turns to self-structured state management, responsive updating and component systems, it may end up simply re-engineering a framework with higher maintenance costs. AI, while able to speed up code maintenance, does not mean that the software maintenance itself has disappeared.
However, this experiment is not a framework that can be applied directly to all projects. The test covers only a dreamable, interactive and relatively simple application based on presentation of content and does not represent a complex dashboard, mail system, design tool or large enterprise application. Through this experiment, Lawson hopes to show that in the AI programming era, technology selection can still be validated by data and Benchmark rather than by continued reliance on community rhetoric and subjective judgement.
For the software team that has become highly dependent on AI Agent, the experiment raises a question that deserves reconsideration: in the past, developers chose the framework to make their own code more comfortable; in the future, the framework may need to be considered to make the AI writing more affordable, token, develop faster, generate fewer codes, and make follow-up maintenance less costly.
There are developers who share and use AI for their own development of HTML projects. Simple pages work well, but after complex forms and state management, Agent often has problems with slow loading and loss of status. He thinks that if you change to React, Agent might be able to do it at once. However, by adding additional testing constraints, he eventually allowed Agent to gradually resolve these problems, retain the HTML option and ultimately perform beyond what he thought React could be achieved.
Conversely, the view was also expressed that the prevalence of React and the large number of ready-made code examples made it easier for models to master their development model. The suitability of the technology warehouse depends not only on the framework itself but also on model training data, document quality, tool support and the complexity of the actual task.
There is no unified answer to this discussion, but one change is clear: AI is forcing developers to revisit the technical selection criteria of the past. The framework no longer merely helps humans to write codes more easily, but also needs to prove that they can help Agent understand the project more accurately, generate fewer errors and reduce the cost of subsequent maintenance.
References:
https://nolanlawson.com/2026/10/28/the-ai-cost-of-javascript-frameworks/
Auto-fetched and translated by AI Atlas. All rights belong to the original author.