JavaScript 框架的 AI 成本

基准范围和局限性

• 许多人认为，宝可梦应用基准测试太小、太静态，无法指导真实世界的选择。
• 批评者指出，它缺少复杂功能（认证、访问控制、社交流程、实时、带校验的表单、多团队开发）。
• 有些人欣赏这种尝试使用客观指标（时间、token、LOC）而不是“感觉”来衡量，但担心别人会过度泛化。
• 也有人希望后续基准测试能覆盖更复杂的应用，甚至包括安全性（例如，用智能体测试基于角色的访问控制）。

框架的赢家、输家与使用场景

• Astro、HTMX 和 Nuxt 收获了很多好评，尤其是在内容驱动型网站和 token 效率方面。
• 有些人强调 Astro/HTMX 在静态或内容密集型场景中表现出色；他们质疑它们在高度交互式应用中的表现。
• Angular 遭到猛烈批评，但支持者认为它适合大型、复杂的企业应用，并受益于其刚性。
• Svelte/Solid 因其优雅和异步处理受到赞赏，不过这里的结果让一些人失望。
• React 被广泛视为事实上的默认选择，尤其适合智能体和工具；jQuery 也被承认仍然无处不在，但大多属于遗留技术。

SPA 与服务端渲染以及 HTMX 风格方法

• 许多人认为，大多数网站都应该是服务端渲染的 HTML，只配少量 JS，HTMX、Turbo/Stimulus、LiveView 风格模式就是例子。
• 也有人反驳说，复杂的 SPA 仍然需要丰富的客户端状态来保证响应性、乐观更新和大型功能集。
• 有几位表示，相比 React/Svelte 的 SPA，AI 在复杂的 HTMX/状态场景中更容易出问题。

为什么需要框架（对人和智能体而言）

• 支持框架的理由：降低认知负担，标准化模式，简化上手/招聘，提供可复用组件，并将状态管理集中化。
• 反对框架的理由：不必要的样板代码和臃肿、由招聘/人事而非实际需求驱动的依赖、刚性，以及长期迁移带来的折腾。
• 有人认为，随着 AI 编写代码，抽象的价值可能没那么高；也有人说 AI 同样需要稳定的抽象，而训练数据中内置的知名框架会让它受益。

AI 智能体、“vibe coding” 与可维护性

• 体验各不相同：有些人表示使用 React/Nuxt/Astro 进行“vibe coding”效果很好；另一些人则发现，如果没有早期结构，智能体会产出一团乱麻。
• 大家担心巨大的单文件原型会超出上下文窗口；有些人主张从一开始就重构为组件，或者使用基于框架的模板。
• 关于框架还是原生 JS 更能减少智能体的总体 token 使用量和错误率，争论仍在继续。

性能、DOM 与语言争论

• 一部分讨论涉及 DOM 性能与基于字符串的 HTML 更新、模板，以及实验性的浏览器特性。
• 还有人担心安全风险（XSS）和基于字符串方案的实际复杂度。
• 其他分支争论包括 async/await 的开销、WASM 包体积，以及现代 JS 是否在美感和认知上都变得令人不快。