htmx v4 进入 Beta 了，前端工程师该认真看看这套无框架思路了

htmx v4 进入 Beta 了，前端工程师该认真看看这套无框架思路了

导语

2026 年了，前端框架已经卷到了”编译时优化”和”元框架 meta-framework”这种词。但你有没有想过，最朴素的 HTML + hypermedia 思路反而可能更适合你的下一个内部工具或内容站？htmx v4 进入 Beta 了，这套”用属性驱动交互”的极简方案，值得前端工程师认真看一遍。

正文

问题：框架太重，交互太轻

很多前端项目的真实情况是：页面 80% 是内容展示 + 表单提交，但为了 20% 的交互，我们引入 React/Vue + 路由 + 状态管理，打包体积几百 KB，首屏时间拉长，招聘门槛也变高了。

这不是说框架没用，而是很多场景下”过度工程”。如果你的需求本质上是：点按钮加载一段 HTML、提交表单刷新局部区域、点击标签切换内容——那 htmx 的 10KB 可能就是更务实的答案。

方案：htmx v4 的 Hypermedia-Driven Applications 思路

htmx 的核心思路很老派：HTML 本身就是 hypermedia，你不需要把交互逻辑搬到 JavaScript 里，用属性告诉浏览器”这个元素要做什么”就够了。

htmx v4 Beta 在之前版本基础上，把这条思路进一步系统化了：

• hx-on 语法：可以在标签内直接写事件处理，不用单独写 JS 文件
• 改进的扩展系统：官方提供了一组扩展，比如 hx-headers、hx-disabled-elt 等
• WebSocket 支持增强：hx-ws 更稳定，适合聊天、实时通知场景
• 加载状态改进：htmx-indicator 机制更灵活
• 更好的错误处理：请求失败时更容易展示 fallback 内容

本质上，htmx v4 想做的不是”又一个 AJAX 库”，而是让服务端渲染也能拥有 SPA 的交互体验。

代码示例：用 htmx 做一个带搜索的列表

<input type="text" name="q" placeholder="搜索项目..."
       hx-get="/api/search"
       hx-trigger="keyup changed delay:300ms"
       hx-target="#results"
       hx-indicator=".spinner">

<div id="results" hx-get="/api/projects" hx-trigger="load">
  <div class="spinner">加载中...</div>
</div>

<button hx-delete="/api/projects/123"
        hx-confirm="确定删除吗？"
        hx-target="#project-123"
        hx-swap="outerHTML">
  删除
</button>

对比方案：

• 用 React 写：你需要组件、状态、事件处理、fetch/axios、可能还需要 React Query
• 用 htmx：HTML 属性写完，后端返回 HTML 片段即可

什么时候该选 htmx？

不是所有项目都适合，htmx v4 最适合的场景：

1. 内部工具/后台：CRUD 为主，交互简单，团队里 Python/Go/Java 后端更熟悉 HTML 模板
2. 内容站/博客：文章列表、分页、搜索，不需要复杂状态管理
3. 多语言团队：前端、后端都能理解 HTML 模板，减少沟通成本
4. 性能敏感项目：10KB 库体积，无虚拟 DOM，首屏几乎零开销

不适合的场景：富交互应用、大量动态表单验证、需要复杂状态管理的客户端应用。

收尾

htmx v4 Beta 不是要取代 React/Vue，而是给前端工程师多一个选项。当你发现项目”用 React 写了个博客后台”或者”Vue 路由只是为了切 3 个页面”时，不妨想想：是不是 htmx 就够了？下一篇文章，我会拿一个真实的后台项目，把 React 换成 htmx v4，看看代码量、性能和开发体验的差异。