SPA的黄昏与HTML的归来：一篇论文揭示的Web开发"去框架化"革命

当"Hacker News"开始讨论HTML

2026年6月11日，Hacker News首页上出现了一个耐人寻味的讨论：一家公司通过构建HTML优先、JavaScript仅作渐进增强的网站，表单完成率一夜之间大幅提升。与此同时，Aalto大学计算机科学系的一篇学术论文《The Case for HTML First Web Development》（arXiv:2602.17193）在技术社区持续发酵，系统性地论证了Web开发的"HTML First"范式。

这并非一次偶发的话题反弹。它指向的是一个更深的趋势：在经历了近十年的SPA（单页应用）框架统治后，Web开发界正在经历一场静默但深刻的去框架化革命。而这场革命的旗帜上，只写了四个字母——HTML。

背景：我们是怎么走到"JS一切"这一步的？

从Web 2.0到SPA狂热

要理解HTML First为什么在2026年成为一个值得严肃讨论的话题，得先回顾Web开发这二十年的狂奔。

2000年代初，Web 2.0浪潮催生了AJAX、动态页面和以Google Maps为代表的第一批真正意义上的"Web应用"。但当时的浏览器能力有限，HTML标准僵化（W3C还在推倒逼开发者放弃现有投资的XHTML2），开发者不得不用JavaScript来弥补平台缺陷。

2010年代，jQuery一统江湖；2013年React开源后，SPA框架进入爆发期。到2020年代初，"前后端分离"已经成为Web开发的"政治正确"——前端用React/Vue/Angular管理整个UI层，后端只提供JSON API。一个典型的SPA项目，node_modules动辄数百MB，构建工具链从Webpack到Vite到Turbopack不断迭代，JavaScript"框架的框架"层出不穷。

然而，代价也随之显现：

• "div soup"泛滥：框架鼓励的组件化开发，往往以牺牲语义化的HTML结构为代价
• 构建步骤不可逆：如果没有webpack/vite，你甚至无法在浏览器中直接"查看源代码"来理解页面
• 性能反直觉：为了一个表单交互加载整份React bundle，首屏加载时间膨胀到数秒
• 开发者疲劳：框架半年一个版本，API频繁废弃，"JavaScript Fatigue"成为社区热词

正如论文作者Juho Vepsäläinen所总结的："框架让复杂应用的开发变得前所未有的容易，但也让HTML被放到了次要位置。"（arXiv论文, Section 1.1）

核心原理：HTML First的六项原则

2023年，开发者Tony Ennis发表了HTML First Manifesto（html-first.com），提出了六项原则，这些原则构成了HTML First运动的理论内核：

原则一：应用"最小力量原则"

优先从最简单的技术开始：先HTML标记，需要时再CSS，最后才用JavaScript。

这实际上是渐进增强（Progressive Enhancement）思想的现代表达。Gustafson早在2003年就提出了渐进增强的概念，但SPA时代让这个理念几乎被遗忘。HTML First将其重新推到前台。

原则二：优先"原生"方案而非外部框架

许多看似需要框架的交互——折叠面板、对话框、表单验证——其实现代HTML已经原生支持。

原则三：尽可能避免构建步骤

这意味着你的源码可以直接在浏览器中运行，不需要webpack/vite的转换。这一原则直接挑战了过去十年"无构建不爽"的主流实践。

原则四：最小化不必要的客户端状态

与SPA中一切状态放在客户端的做法相反，HTML First鼓励尽可能将状态和验证逻辑放在服务端，让客户端保持"薄"的状态。

原则五：保留"查看源代码"的能力

这是HTML First最有情怀也最硬核的原则。SPA经过编译、打包、混淆之后，浏览器中的"查看源代码"几乎毫无意义。HTML First强调开发者应该工作在接近Web标准的层面，让源代码直接可读、可调试。

原则六：如果必须用库，优先选择复用现有概念的库

例如，像htmx这样的库——它不创造自己的新语法，而是通过HTML属性扩展已有的超媒体能力——比React/Vue/Angular这类创造全新编程模型的框架更符合HTML First的精神。

技术深度：HTML比你想象的更强大

HTML First并非一句空洞的口号。现代HTML（特别是HTML Living Standard）已经内置了相当多的交互能力，足以替代大量JavaScript代码。

案例1：可折叠容器——零JS实现

<details>
  <summary>什么是HTML First？</summary>
  <p>一种优先使用HTML原生能力、减少抽象层级的Web开发范式。</p>
</details>

这不需要任何JavaScript，浏览器原生支持展开/收起动画。

案例2：模态对话框——原生API

<dialog id="myDialog">
  <p>这是一个原生对话框</p>
  <button onclick="this.closest('dialog').close()">关闭</button>
</dialog>
<button onclick="document.getElementById('myDialog').showModal()">
  打开对话框
</button>

过去这需要复杂的DOM操作、遮罩层管理、焦点锁定、键盘事件处理——现在一个<dialog>元素全搞定。

案例3：表单验证——声明式校验

<form>
  <input type="email" required autocomplete="email" 
         pattern="[a-z0-9._%+\-]+@[a-z0-9.\-]+\.[a-z]{2,}$">
  <input type="submit" value="提交">
</form>

HTML5内置的表单验证API已经覆盖了绝大多数场景，包括输入类型检查、必填校验、正则匹配、自动填充建议等功能，无需引入任何表单验证库。

案例4：通过htmx实现动态交互

当HTML原生能力不足时，htmx这类库可以"渐进增强"：

<button hx-get="/api/load-more" hx-target="#content" hx-swap="beforeend">
  加载更多
</button>
<div id="content">
  <!-- 这里会自动追加新内容 -->
</div>

不需要写一行JavaScript，不需要管理状态，不需要打包。htmm通过HTML属性实现AJAX请求和DOM更新的绑定，将交互逻辑从JS搬回了声明式的HTML中。

论文引用的数据显示，采用htmx的项目代码库体积平均减少了67%（htmx官方数据）。

现实案例：从React到HTMX的真实迁移

HTML First并非纸上谈兵。2025-2026年间，多个团队公开分享了从React迁移到HTMX/HTML First的实战经验：

案例一：200个站点的生产级迁移

一位开发者在2026年5月发表的案例研究（Dev.to案例报告）中详细记录了团队从React迁移到HTMX的过程：在6个月时间内，将管理面板逐路由迁移至HTMX。结果是代码量急剧下降、依赖大幅减少、开发体验显著改善。团队发现，大部分"需要React"的交互场景，其实可以用更简单的方式实现。

案例二：从Next.js到HTMX的URL缩短器

Pouria Ezzati的案例研究（Next.js to htmx — A Real World Example）显示，将一个URL缩短器应用从Next.js迁移到HTMX后，代码库规模大幅缩减，依赖项从数十个降至个位数，构建步骤完全消失。开发者体验的提升尤为显著——"在Next.js项目中修改一个按钮样式需要理解整个组件树的props传递，在HTMX中只需找到对应的HTML文件直接修改。"

案例三：10位Django开发者的集体转向

2025年底的一篇研究报告（From React to HTMX: Real Migration Stories）采访了10位从React迁移到HTMX的Django开发者，所有人都表示不会再回到纯SPA模式。他们承认在某些场景下（如实时协作工具、复杂的客户端状态管理）仍需React，但对于80%以上的"内容型+一定动态交互"的Web应用，HTML First提供了更好的性价比。

正反视角分析

支持方：为什么HTML First是对的？

1. 性能的回归：SPA的"性能惩罚是结构性的，而非偶然的"（SPAs Are a Performance Dead End, 2026）。HTML First通过减少客户端JavaScript、利用服务端渲染+渐进增强，在首次加载时间（FCP/LCP）和交互响应性上都有本质优势。

2. 可维护性提升：HTML First的代码天然是声明式的。一个按钮的行为可以直接在HTML属性中看到（如hx-get、hx-target），而不需要在组件树中追踪props和state的流转。论文作者称之为"更高的概念简洁性"（greater conceptual simplicity）。

3. Web的初心：Tim Berners-Lee设想的Web是一个"全球信息交换系统"，其核心是超文本（hypertext），而非应用平台。HTML First在某种程度上是让Web回归其设计初衷。

4. 真正的"跨平台"：HTML First应用在任何支持浏览器的设备上都能工作，不依赖特定框架的运行时。即使在JavaScript被禁用或未加载完成的情况下，基础内容依然可访问。

反对方：HTML First不应该被神化

1. 场景局限性：对于复杂的单页应用——如Google Docs、Figma、在线IDE——HTML First的范式完全不适用。这些应用需要细粒度的状态管理和实时协作，SPA架构是更合理的选择。

2. 开发者生态的惯性：React/Vue/Angular经过近十年的发展，拥有庞大的组件生态、工具链和人才储备。一个采用HTML First的团队，在招聘和第三方库复用方面会面临实际困难。

3. "退步"的风险：有人批评HTML First是"技术原教旨主义"——用一种浪漫化的Web初心来否定合理的工程进步。毕竟，jQuery和React的出现本身就是对当时Web平台不足的回应，如果HTML First成为一种教条，可能导致开发者放弃更高效的现代工具。

4. AI时代的变量：论文作者也坦诚地指出一个开放性问题——"HTML First与AI驱动的Web开发趋势如何对齐？" 如果未来的Web应用大量由AI直接生成代码，那么"人类是否理解HTML结构"可能不再是一个核心考量。

批判性思考：这不仅是技术选择，更是一种价值观

在我看来，HTML First的意义不在于它是否"取代"React/Vue——它不会，也不应该。

它的真正价值在于提供了一面镜子，让2026年的Web开发者重新审视一个被忽略太久的问题：我们引入的每一层抽象，到底在解决什么问题？又在制造什么问题？

过去十年，SPA框架的普及遵循的是一个"技术乐透"逻辑：大家都在用React，所以新项目也用React；面试要求React，所以学React；社区讨论React，所以默认React就是"正规"的Web开发方式。很少有人停下来问：这个简单的表单页面，真的需要一个完整的客户端路由和状态管理框架吗？

HTML First所倡导的，本质上是对工程中复杂度预算的重新思考：

• 一个静态博客网站 → 纯HTML+CSS已经足够
• 一个内容型网站+一定动态交互 → HTML + htmx，搭配服务端渲染
• 一个管理后台仪表盘 → 可能是SPA，但也可以先用HTML First试试
• 一个协同编辑工具 → 确实需要SPA架构

关键在于，框架不应该是默认选项，而应该是经过考量的最终选择。

这就像建筑学中的"少即是多"（Less is More）原则。密斯·凡·德·罗在20世纪中叶提出这一理念时，并不是说所有建筑都应该极简，而是提醒建筑师：每增加一处装饰，都应该有充分的理由。HTML First对Web开发的贡献，本质上是一个类似的问题：每引入一个npm包、每搭建一个构建流水线、每封装一个组件，你真的需要它吗？

结语：HTML不死，它只是被重新发现

2026年，Web已经诞生了34年。HTML作为Web最基础的构造语言，经历了从被轻视到被重新发现的有趣轮回。

还记得互联网早期的那种纯粹吗？右键"查看源代码"，HTML结构一目了然，从标题到段落到链接，每行代码都对应着屏幕上的一块内容。SPA摧毁了这种透明性，而HTML First试图重新找回它——不是通过拒绝技术进步，而是通过更审慎地选择技术。

正如论文结论所写："HTML First开发对Web开发者具有明显优势，尽管其优势的程度以及与AI驱动的Web开发趋势的兼容性，仍然是开放性问题。"（arXiv论文, Conclusion）

HTML First不是怀旧，而是一种理性的回归。在这个意义上，它不是Web开发的"倒退"，而是一次经过深思熟虑的"进化回调"——一种对复杂度失控的主动纠偏。

毕竟，最好的架构不是功能最强的那个，而是刚好够用的那个。

参考链接：

• arXiv论文：The Case for HTML First Web Development (Juho Vepsäläinen, Aalto University, 2026)
• HTML First Manifesto (Tony Ennis, 2023)
• Next.js to htmx — A Real World Example
• Why We Switched from React to HTMX in Production: A 200-Site Case Study
• From React to HTMX: Real Migration Stories from 10 Django Devs (2026)
• SPAs Are a Performance Dead End (Yegor Bugayenko, 2026)
• HTML Living Standard (WHATWG, 2026)