2026 年了，前端还在卷框架？htmx v4 进入 Beta，HDA 这条路快通了

2026 年了，前端还在卷框架？htmx v4 进入 Beta，HDA 这条路快通了

导语

2026 年的前端圈还在卷什么？React Server Components、Vite 8、Bun 2.x……但与此同时，另一条路线正在 quietly 成熟：不需要打包、不需要虚拟 DOM、甚至不需要你写太多 JavaScript——htmx v4 已经进入 Beta，目标今年夏天发布正式版。这篇文章带你从架构师视角理解 HDA（Hypermedia-Driven Application）到底是什么、和 SPA 到底有什么本质区别，以及为什么值得你现在就关注。

问题：SPA 是不是走过头了？

过去 10 年，前端工程化的一条主线是”把更多逻辑搬到客户端”：从 jQuery 到 Backbone，到 Angular/React/Vue，再到如今的全栈框架 RSC。这个方向带来了更好的交互体验，但也付出代价：

• 首屏 JS 体积动辄几百 KB，甚至几 MB
• 客户端状态管理复杂度指数上升
• SEO、无障碍、渐进增强往往变成”事后补丁”
• 团队需要同时维护服务端 API 和前端状态模型

我在实际项目里见过太多团队因为过度客户端化而后悔：明明是一个内容为主的站点，硬是搭了一套 Redux + React Query + SSR 的复杂架构，结果维护成本远超收益。

方案：HDA——把 HTML 重新当成应用状态载体

HDA（Hypermedia-Driven Application）的核心思想其实很朴素：HTML 本身就是最好的应用状态载体，你不需要把状态抽出来放到 JavaScript 对象里，再费劲同步回 DOM。

htmx 是这个思路最成熟的实现。截至 2026 年 7 月，htmx v2 已经在生产环境稳定运行，v4 Beta 也已发布（four.htmx.org），目标是 Summer ’26 正式版。

HDA 的三大约束（源自 htmx 官方论文 Hypermedia-Driven Applications）：

• 声明式语法：用 HTML 属性描述交互，不用 JavaScript 命令式编程

• 超媒体通信：与服务器交互用 HTML，不用 JSON API

• 按需脚本：JavaScript 作为增强手段，不主导架构

用代码对比就明白了。下面是同一个”搜索输入，防抖后请求后端”的模式：

function SearchBox() {
  const [query, setQuery] = useState('');
  useEffect(() => {
    const timer = setTimeout(async () => {
      const res = await fetch(`/api/search?q=${query}`);
      const data = await res.json();
      setResults(data);
    }, 500);
    return () => clearTimeout(timer);
  }, [query]);
  return  setQuery(e.target.value)} />;
}

搜索中...

注意第二段代码没有任何 ——交互逻辑全在 HTML 属性里。后端只需要返回一段 HTML 片段，htmx 负责插入 DOM。

代码/截图：v4 Beta 值得关注的三个方向

结合官方站点和 web.dev 的 Baseline 生态进展，v4 值得关注的方向：

1. 更细粒度的事件触发控制

v4 对 hx-trigger 做了扩展，支持更复杂的事件组合。上面搜索防抖的例子在 v2 已经可用，v4 进一步优化了触发时机和取消逻辑，减少不必要的请求。

2. 与 Web Standard 的深度融合

htmx 一直坚持不依赖框架，v4 进一步拥抱 Web Platform：

• 利用 Web Components 做可复用交互部件
• 与 View Transitions API 配合实现页面过渡
• 支持 CSS :has() 选择器做条件样式

  加载个人资料

3. 性能基线

htmx 全量压缩后约 16KB，gzip 后不到 5KB。对比一个典型 React 应用的生产包（含 React + ReactDOM + 常用 hooks），体积通常在 100-300KB。这不是”框架 A 比框架 B 快”的问题，而是架构范式的差异：HDA 把复杂度放在服务端，客户端只需要一个轻量运行时。

结论：什么时候该选 HDA？

不是所有项目都适合 HDA，但以下场景 HDA 明显更优：

• 内容驱动型站点：博客、文档、CMS——交互逻辑不复杂，首屏性能敏感
• 传统后端团队：Ruby on Rails / Laravel / Django 团队，不想再招前端专家
• 渐进增强需求：需要 SEO、无障碍、低带宽环境支持
• 快速原型/MVP：几天内上线一个可用的交互页面，不需要复杂构建链

反过来，如果你的应用是：

• 重度交互的 SaaS 仪表盘
• 实时协作白板
• 3D / WebGL 应用

……那 SPA/框架仍然是更合理的选择。

收尾

框架选择从来不是”谁更好”，而是”谁更适合你的约束”。htmx v4 的成熟意味着 HDA 路线在 2026 年已经不是一个”实验性选项”，而是一个值得严肃考虑的架构选项。

下一步行动：拿你当前一个简单的 CRUD 页面，用 htmx 重写核心交互，感受一下”没有虚拟 DOM”的开发体验。如果 30 分钟内能跑通，说明这条路适合你。

参考：

• htmx.org：官方文档与 Hypermedia-Driven Applications 论文
• web.dev/baseline：Baseline Alerts 已上线 Web Platform Status Dashboard（2026-06-25）
• web.dev/articles/use-baseline-with-browserslist：Browserslist 已内置 Baseline 查询
• four.htmx.org：htmx v4 Beta 专属页面