HTML 优先

原文 ↗ Hacker News 讨论 ↗

一篇倡导“HTML 优先”Web 开发的宣言——偏好语义化 HTML、最少 JavaScript，并避免沉重的构建工具——重新激起了围绕简洁性与现代前端框架（如 React）之间长期存在的张力。支持者认为，依赖浏览器原生特性、属性和服务端渲染的 HTML，能让网站更易访问、更易维护，也更适合新手；批评者则警告说，内联事件处理器、像 hyperscript 这样的 DSL，以及缺乏清晰的状态和复用模式，无法扩展到复杂应用，也难以满足当代的安全与可访问性要求。许多人认为这些原则对小型到中型、内容密集型网站很有价值，但怀疑它们能否替代大型、高交互 Web 应用中的组件化框架和构建流水线。

对“HTML 优先”的总体反应

  • 许多人赞同转向更简单、以 HTML 为中心的开发方式，尤其适用于小型/中型站点和服务端渲染应用。
  • 也有人认为这是在美化 2000 年代初的做法，并忽视了框架、构建工具以及关注点分离之所以变得普遍的原因。

HTML 与框架（React、Vue 等）

  • 支持 HTML 优先：
    • 大多数 Web UI 都是表单和基础交互；服务端渲染加上少量 JS “点缀”（htmx、Alpine 等）通常已经足够。
    • 框架带来了沉重的复杂度（状态管理、路由、构建链），而对于不需要 SPA 行为的项目，可能会增加约 50% 的工作量。
    • 对学习很友好，“查看源代码”也可作为教学和调试工具。
  • 持怀疑态度：
    • 对于更大型、带状态的应用（仪表盘、预订系统、富交互工具），框架有助于管理复杂度、复用和团队协作流程。
    • 没有框架时，团队往往会重新造出临时的迷你框架，同时仍要应对浏览器怪癖。
    • 许多开发者更看重在各处使用一套强大的技术栈，而不是拆分心智模型。

内联属性、局部性与关注点分离

  • 支持内联 onclick / 工具类的人认为：
    • “行为的局部性”（HTML、行为和样式放在一起）让组件更容易在同一处理解。
  • 批评者认为：
    • 这会重新引入 CSS/JS 分离本来解决的那种面条式代码；在规模上很难重构和调试。
    • 内联 JS 会破坏或削弱 CSP，增加 XSS 暴露面，并让安全审查更复杂。
    • 可访问性会受损（例如用可点击的 <div> 代替 <button>）。

CSS、Tailwind 与 class 设计

  • Tailwind 受到赞扬的点：
    • 通过组合小的工具类，避免不可维护的语义化 CSS 文件。
    • 在组件范围内表现良好，并鼓励一致的设计令牌。
  • 批评：
    • 它实际上把 class 变成了第二个 style 属性；HTML 会变得杂乱。
    • 需要构建步骤（清理/生成 CSS），与“无构建”理念相冲突。
    • 一些测量结果表明，Tailwind 的打包体积可能比设计良好的语义化 CSS 更大。

HTMX、hyperscript 与“基于 HTML”的库

  • HTMX 和 Alpine 被认为是加入交互性、同时避免完整 SPA 的不错“HTML 优先”方案。
  • 担忧包括：
    • 从 API 返回 HTML 可能会让前端和后端关注点缠在一起。
    • hyperscript 明确是一种自定义 DSL，这与文章自身反对自定义语法的警告相矛盾。
    • 有些人认为 HTMX 很适合内部工具和中等规模应用，但不适合非常大的前端。

可访问性、UX 与原生元素

  • 许多人强调原生语义（<button>、<details>、<summary>、<datalist>、正确的 ARIA）对于可访问性以及键盘/屏幕阅读器支持至关重要。
  • 也有人指出，原生控件（日期选择器、多选框）表现不一致、难以样式化，而且常常功能太有限，迫使团队回到自定义 JS 组件。

历史 / 元主题

  • 一些评论把这看作一个反复循环中的又一次转向：内联 → CSS/JS 分离 → JS 框架 → 现在又回到“HTML 优先”。
  • 对这究竟是实质性进步、有用的纠偏，还是最新的潮流，存在强烈分歧。