htmx

high power tools for HTML——把超文本补完

更新于 2026-08-30 · 数据来源：GitHub API（采集于 2026-08-30）

一句话定位

不写 JavaScript，让 HTML 自己长出交互

直接在 HTML 属性里（hx-get / hx-post / hx-swap…）访问 AJAX、CSS Transitions、WebSocket、SSE——服务端返回 HTML 片段而非 JSON，零构建、零 hydration、零客户端状态管理。适合想逃离 SPA 复杂度、以服务端为中心的 Web 团队；也是理解 REST 本源（HATEOAS）的最佳工程教材。

核心数据

1.6k forks · 前身 intercooler.js（2013）· 当前 v2.0.10 · 0BSD 许可（比 MIT 更自由）· 作者 Carson Gross 同期维护 hyperscript、著《Hypermedia Systems》· 官网附 essays 专栏沉淀超媒体方法论

README 里的灵魂四问

README 结尾的一首 haiku，是整个项目的气质注脚：javascript fatigue: longing for a hypertext already in hand（JS 疲劳：渴望一种早已在手的超文本）。

SPA vs 超媒体：两种世界观

一次 hx-get 的完整生命周期

两行代码的哲学

<script src="https://cdn.jsdelivr.net/npm/htmx.org@2/dist/htmx.min.js"></script>

<!-- 这就是 htmx 的全部入门成本 -->
<button hx-post="/clicked" hx-swap="outerHTML">
  Click Me
</button>

• 声明即行为：「用户点这个按钮时，向 /clicked 发请求，用响应替换整个按钮」——一句话写在标记里，无需任何 JS
• 渐进增强气质：属性不生效时仍是合法 HTML；服务端渲染的页面天然可降级
• 动词齐备：hx-put / hx-delete / hx-patch——HTML 只差 PUT/DELETE，htmx 补上
• npm 包名是 htmx.org：老 htmx 包是坏的——README 特意警告

hx-swap 六式

配合 hx-target（CSS 选择器 / closest 语法 / this）决定「换哪里」，hx-swap 决定「怎么换」——组合出所有局部更新需求，整页刷新从此退休。

hx-trigger：事件系统军火库

<!-- 任意元素、任意事件，全部声明式 -->
<div hx-get="/mouse_entered" hx-trigger="mouseenter">悬停加载</div>

<input hx-get="/search" hx-trigger="keyup changed delay:500ms"/>
<!-- 值变了才触发 + 500ms 防抖：搜索框的工业标准写法，一行 -->

<button hx-post="/vote" hx-trigger="click throttle:1s">投票</button>
<!-- 1 秒节流：防连击，还是一行 -->

<div hx-get="/dash" hx-trigger="every 5s">仪表盘</div>
<!-- 轮询：every 5s，仍然一行 -->

<form hx-post="/save" hx-trigger="submit from:body">…</form>
<!-- from: 换监听源；once / delay / changed 自由组合 -->

防抖、节流、轮询、事件委托、一次性触发——这些 SPA 里要引库或手写的时序控制，在 htmx 里是 trigger 规范的一部分。Playground 里可以亲手调这些参数。

扩展 + hyperscript：克制后的纵深

<button _="on click toggle .red on me">
  变红
</button>

六年三幕：intercooler → htmx 1.x → 2.x

• 血统：2013 年 jQuery 时代的 intercooler.js 就提出 ic-* 属性驱动；2020 年以原生 JS 重写为 htmx——理念早于爆发六年，等到了 SPA 疲劳的时势
• 2.x（当前 v2.0.10）：清理十年废弃 API、默认值现代化（如 hx-boost 历史）、扩展拆分独立包——核心保持 ~14KB 不膨胀
• 测试文化：mocha + chai + sinon 模拟 XHR，/test 目录按 attributes/core/ext/regressions 分层，回归测试单独成册——对一个「只是增强 HTML」的库，测试纪律罕见地严格
• 知识输出：htmx.org/essays + 《Hypermedia Systems》免费电子书 + Carson 的会议演讲——不只给工具，还给世界观和方法论，这是 49k stars 里社区凝聚力的来源
• 0BSD 许可：比 MIT 更宽松——「拿去用，别问」

适合谁用

• 服务端为主的全栈团队：Django / Rails / Laravel / Go 模板党——不离开舒适区就获得现代交互，模型层直接服务 UI
• 厌恶构建链的小团队与独立开发者：零 npm、零 bundler、零 hydration，一个 script 标签回到 2010 年的部署简单度 + 2026 年的交互体验
• 内部系统 / 后台 / 内容站：CRUD 密集、SEO 重要、交互中等——SPA 在这里是过度工程的重灾区
• 渐进增强信徒：表单不写 JS 也能提交、链接没有 JS 也能跳——可访问性与降级路径天然成立

需要警惕（作者自己也承认）

• 不适合高交互前端：Figma 类画布、复杂拖拽、离线优先应用——超媒体模型的硬边界，作者在 essays 里反复划线
• 每次交互一次往返：延迟敏感场景（游戏感操作、毫秒级反馈）体验不如本地状态——网络就是你的状态总线
• HTML 片段体积：比精瘦 JSON 大——高流量站点要靠缓存与局部模板控制
• 生态位夹缝：React/Vue 主流惯性 + LiveView/Hotwire 等同类竞争（服务端驱动各有玩法）——团队招聘与既有代码迁移成本是现实阻力
• 681 open issues：长尾 issue 响应依赖核心小团队节奏

未来空间

htmx 改变的不只是写法，是行业对话的坐标系——「要不要 SPA」从此有了体面的否定答案。Web 平台演进（View Transitions、hotwire 系竞争）会持续挤压它的独特性，但「HTML 补完主义」的哲学坐标与教学价值长存：它证明了复杂度是可以被拒绝的，而拒绝本身可以成为 49k stars。