为什么使用原生 JavaScript
“原生” JavaScript 的支持者认为，现代浏览器、Web Components 和轻量自定义辅助库足以满足许多应用需求，而 React 或 Angular 这类大型框架往往会引入不必要的复杂性、构建工具链和性能开销——尤其是对小团队或简单 UI 而言。反对者则指出，对于中等复杂度或生命周期较长的项目，框架通过强制共享结构、可预测模式和更容易的上手，往往物有所值，即便它们会增加抽象层和技术栈波动。多位贡献者还提到，TypeScript、JSDoc 和 LLM 正在再次改变这些权衡，让人们更容易直接使用平台，同时仍能获得类型安全和代码生成支持。
原生 JS 与框架的适用范围
- 许多人认为原生 JS 对于小型或个人项目是可行且令人愉快的：依赖更少、无需构建步骤、完全掌控浏览器，把浏览器本身当作“框架”。
- 一些人认为，现代 JS（ES5+ 特性）和 Web API 如今已经足够好，因而对于基本的 CRUD 和“零散交互”而言，沉重的框架往往并非必要。
- 也有人反驳说，对于任何“中等复杂度的 UI”，原生方案往往会逐渐累积成一个定制的、文档不足的框架，带有临时拼凑的设计决策。
团队协作、结构与规模化
- 一个强烈的主题是：框架提供共享约定、可预测性和防护栏，尤其是在代码库和团队人数增长时。
- 使用流行框架能简化招聘和上手；新开发者和 LLM 已经熟悉这些模式。
- 批评者指出，框架本身也会碎片化（React 变体、状态管理器、样式系统），因此选择一个框架并不能完全消除分歧或复杂性。
Web Components 与“轻量”抽象
- 一些人主张 Web Components 和模块化原生 JS 作为可扩展的折中方案：组件化 UI、动态导入，以及共享组件池，而无需沉重工具链。
- 另一些人则认为文章中的自定义抽象（包括 EHTML）实际上是微型框架，又增加了一个需要学习的定制层。
类型系统与工具链
- 多条评论推荐使用 TypeScript 或 JSDoc/@ts-check 做静态检查，但对于是否接受构建步骤存在分歧。
- 对于复杂应用，“零构建”方案也受到质疑，因为它缺少压缩/代码拆分，而且自定义工具链在长期上更脆弱。
性能、UX 与架构选择
- 关于 SPA 与多页应用的争论：一些人坚持在正确缓存下 MPA 也能很快；另一些人则认为 SPA 会更灵敏、更动态。
- 多人批评 React 给只需少量 DOM 更新的 UI 引入了延迟和复杂性；也有人把 React 视为面向更大型 SPA 的强大“电动螺丝刀”。
LLM 与框架的未来
- 一些人预计，LLM 会通过让直接使用平台 API 或小型辅助库变得更容易，从而降低对大型框架的需求。
- 另一些人指出，框架能为非确定性的 LLM 生成代码提供防护栏，而且 LLM 已经能很好地与 React/TypeScript 等主流技术栈协作。