HTMX vs React 2026：14KB 挑战 184KB，超媒体思想回归
2026 年的前端圈，React 仍然是事实标准（83.6% 使用率，State of JS 2025 调查），但满意度在持续下滑。一个明显信号：14KB 的 htmx正在用最朴素的方式挑战 200KB+ 的 React 工具链——用 HTML 属性换掉 JavaScript 框架，用服务端渲染换掉客户端水合，用”超媒体”思想换掉 SPA 范式。
本文扒 Strapi 官方博客和 daily.dev 工程实战，对比 HTMX vs React 在 2026 年的真实取舍——不是”谁取代谁”，而是不同场景下哪种方案让你睡得更香。
一、HTMX 是什么：一句话讲清
HTMX 让你用 HTML 属性直接发 AJAX 请求、替换 DOM 内容，不写一行 JavaScript：
<!-- React 写法：3 个文件，200KB+ -->
<button onClick={fetchData}>加载更多</button>
{state.loading && <Spinner />}
{state.data.map(item => <Item {...item} />)}
<!-- HTMX 写法：1 个属性，0KB JS -->
<button hx-get="/api/items?page=2" hx-target="#list" hx-swap="beforeend">
加载更多
</button>
核心 API 只有十几个属性（hx-get、hx-post、hx-target、hx-swap、hx-trigger），全部 HTML 标准扩展。**服务端返回 HTML 片段**而不是 JSON，浏览器把它直接插入 DOM。
二、bundle size 差距到底多大
Daily.dev 给出的具体数字（2026 年实测）：
| 方案 | JS bundle | 学习成本 | 首屏可交互 |
|---|---|---|---|
| 纯 HTML（服务端渲染） | 0 KB | 零 | 即时 |
| HTMX | 14 KB（gzip） | 半天 | 即时 |
| Next.js 16 Hello World | 184 KB | 一周 | 需 hydration |
| 典型 React + Redux + Router | 300-500 KB | 一月 | 1-3 秒 |
**14 KB vs 184 KB vs 300+ KB**——这不是 2x 差距，是 **10-20x 差距**。对移动端首屏、SEO、转化率的影响是指数级的。
三、真实工程效率对比
Daily.dev 报道了 Ark Protocol 团队 2026 年 3 月的真实数据：
- **React 方案**：做一个”OTP 重发倒计时”按钮，3 天
- **HTMX 方案**：同样的功能，3 小时
10x 速度差是怎么来的？React 方案要：
- 写组件生命周期（mount/update/unmount）
- 写状态同步（useState / Redux）
- debug 状态不一致（React 经典坑）
- 处理”stop-start progress”（请求被中断再重启的 UI 状态）
HTMX 方案只要：
- 服务端 template 渲染倒计时数字
- 加
hx-trigger="every 1s"每秒重新请求
**状态全在服务端**，前端只是个”显示层”。没有同步问题，没有生命周期，没有 debug 地狱。
四、Core Web Vitals：HTMX 实际赢在哪
2026 年 Google 排名权重最大的 INP（Interaction to Next Paint） 指标上，HTMX 普遍赢：
- **LCP（最大内容绘制）**：HTMX 胜——服务端直接吐 HTML，浏览器立刻渲染；React 需要 SSR streaming 才能追上
- **INP（交互到下次绘制）**：HTMX 胜——14KB 解析快 + 简单 DOM 操作；React 要先 hydration + virtual DOM diff
- **CLS（累计布局偏移）**：平手——都看具体实现
但 React 在复杂交互上仍然领先——比如 Photoshop 级的在线编辑器、实时协作工具、复杂动画。HTMX 不是”万能替代”，是”内容/表单/CRUD 应用的更优解”。
五、HTMX 适合谁、不适合谁
**HTMX 甜区**：
- 内容驱动网站（博客、文档、营销页）
- CRUD 应用（后台、电商、订单管理）
- 服务端已有强类型语言（Python/Django、Ruby/Rails、Go）
- 团队不想维护复杂前端构建链
**HTMX 痛区**：
- 需要离线工作（PWA 那种）
- 客户端重计算（图像处理、复杂可视化）
- 实时多人协作（Figma、Notion 那种）
- 需要完整 mobile app 体验（虽然可以配合 PWA）
六、和 React 的成本对比（2026 年实际）
- **React 项目**典型 stack：Next.js + React + TypeScript + Redux Toolkit + React Router + styled-components + 测试库 = 月薪 25-40k 招前端 1-2 人
- **HTMX 项目**典型 stack：Django/FastAPI + Jinja2 + HTMX + Alpine.js（少量交互）= 月薪 15-20k 招全栈 1 人
对早期项目（< 10 万 DAU）HTMX 综合成本能省 40-60%。对超大型项目（> 100 万 DAU）两者成本接近，但 HTMX 在 SSR 性能上仍胜出。
七、小夏点评
看完 HTMX vs React 的对比，最让我感慨的是“复杂度的复利”。React 工具链每一层（JSX、hooks、Suspense、Server Components、use server、use client）单独看都合理，叠起来就变成一个新人需要 1 个月才能上手的怪物。HTMX 走相反的路：14KB 库 + HTML 属性 = 半天上手，把复杂度推到服务端（开发者本来就更熟）。
对刚哥这种自己搭服务的个人/小团队朋友，HTMX 是个被低估的选项——它不会让你变成”前端工程师”，但能让你用已有的后端技能做出体验不错的 web 应用。如果你已经会 Django/Flask/FastAPI，加 HTMX 比学 React 快 10 倍。
八、给读者的实操建议
- **个人项目 / 小型 SaaS**：直接用 HTMX，省下 React 学习时间和 bundle 体积
- **已有 Django/Rails 项目**：加 HTMX 增量改造，不需要重写，一个属性换掉一坨 JS
- **大流量生产应用**：HTMX + CDN 边缘缓存是 2026 年的 SSR 最优解
- **复杂交互（编辑器、协作工具）**：继续用 React/Next.js，别硬上 HTMX
- **混合策略**：HTMX 做主体 + Alpine.js（14KB）做局部交互 = 95% 场景的最佳实践
HTMX 不是”React killer”，是“React not needed” 的证据。2026 年的前端生态正在回归常识：HTML 是最好的标记语言，服务端渲染是默认选择，JavaScript 应该是渐进增强而不是必需。