htmx 只是又一个 JavaScript 框架吗？

原文 ↗ Hacker News 讨论 ↗

htmx 应被视为轻量级 JavaScript 库、完整框架，还是“未来的 HTML polyfill”，引发了关于现代 Web 界面构建方式的更广泛讨论。评论者将 htmx 以超媒体为中心、无构建、服务端渲染的模型，与 React 风格的 SPA 和沉重的 bundler 工具链进行对比，争论复杂性、依赖管理、性能和团队结构方面的权衡。许多人认为 htmx 是一种务实方式，可将大部分逻辑保留在后端并减少 JavaScript，但也指出它最适合某些类型的应用，而且在短期内不太可能取代大型组织中的主流 SPA 框架。

htmx 是什么：库还是框架

  • 关于定义的争论仍在继续：有人把 htmx 看作库（HTML 也是这么称呼它的），也有人把它看作框架（它管理事件循环并调用你的代码）。
  • 几位评论者认为传统的“你调用库；框架调用你”过于模糊，指出 React、Spring、Rails 等也有类似的混淆。
  • 一个更务实的定义浮现出来：库更容易替换；框架会渗透整个代码库且难以替换。按这个标准，有人认为 htmx 表现得更像框架。

以超媒体为中心的模型

  • htmx 将 HTML 现有的“超媒体控制”（链接和表单）泛化到任何元素，从而支持声明式 HTTP 请求和局部 DOM 交换。
  • 许多用户重视把大部分逻辑保留在后端，返回 HTML 而不是 JSON，并避免客户端与服务器之间重复保存状态。
  • 有人将 htmx 视为更丰富的超媒体客户端和“无构建”工作流的概念验证。

与 SPA 和 JS 工具链的比较

  • 对现代 JS/NPM 生态系统的强烈批评：依赖爆炸、升级脆弱、频繁破坏性变更、复杂的构建流水线。
  • htmx 的吸引力在于它可以：
    • 避免或尽量减少 bundler/transpiler。
    • 让内部工具和 CRUD 应用的 UI 更简单。
    • 用服务端渲染的 HTML 获得“类似 SPA”的交互性。
  • 也有人认为，只要正确锁定版本并使用合适工具，TypeScript/React 可以很稳定，而复杂性往往来自误用，而不是技术栈本身。

局限性、DSL 担忧与逃生出口

  • 批评者指出，基于属性的配置表达能力上限较低，并且会出现迷你 DSL（例如复杂的 hx-trigger 语法）和配套语言。
  • 担心随着需求增长，团队会不断叠加更多 JS，最终变成乱成一团的代码，并最终迁移到完整的 SPA 框架。
  • 支持者回应说：
    • htmx 有意运行在有限的能力层级上；当需求超出时，你应该有意识地加入脚本或切换工具。
    • 它可以与 AlpineJS 或类似工具较好地组合，用于客户端状态管理。

采用情况、组织结构与用例

  • 据报道最合适的场景包括：内部工具、管理后台、内联网应用、交互适度的网站；尤其适合由后端开发者同时负责数据和 UI 的情况。
  • 有人指出它在大型、以利润为导向的公司中使用有限，并将此归因于：
    • 既有的 React/SPA 投入。
    • 前端与后端团队分工明确。
  • 关于 htmx（或其理念）是否会影响 HTML 标准，仍有争论；几位评论者对短期内实现标准化持悲观态度。