Htmx 意外走红，我们从 React“退回去”后：代码行数减少 67%，JS 依赖项从 255 下降到 9

技术和软件开发领域存在一种有趣的现象，就是同样的模式迭起兴衰、周而复始。

htmx 的走红

过去 Web 非常简单。URL 指向服务器，服务器将数据混合成 html，然后在浏览器上呈现该响应。围绕这种简单范式，诞生了各种 Javascript 框架，以前可能需要数月时间完成的一个应用程序基本功能，现在借助这些框架创建相对复杂的项目却只需要数小时，我们节省了很多时间，从而可以将更多精力花在业务逻辑和应用程序设计上。

但随着 Web 不断地发展，Javascript 失控了。不知何故，我们决定向用户抛出大量 App，并在使用时发出不断增加的网络请求；不知何故，为了生成 html，我们必须使用 JSON，发出数十个网络请求，丢弃我们在这些请求中获得的大部分数据，用一个越来越不透明的 JavaScript 框架黑匣子将 JSON 转换为 html，然后将新的 html 修补到 DOM 中......

难道大家快忘记了我们可以在服务器上渲染 html 吗？更快、更一致、更接近应用程序的实际状态，并且不会向用户设备发送任何不必要的数据？但是如果没有 Javascript，我们必须在每次操作时重新加载页面。

现在，有一个新的库出现了，摒弃了定制化的方法，这就是 htmx。作为 Web 开发未来理念的一种实现，它的原理很简单：

• 从任何用户事件发出 AJAX 请求。

• 让服务器生成代表该请求的新应用程序状态的 html。

• 在响应中发送该 html。

• 将该元素推到它应该去的 DOM 中。

htmx 出现在 2020 年，创建者Carson Gross 说 htmx 来源自他于 2013 年研究的一个项目intercooler.js。2020 年，他重写了不依赖 jQuery 的 intercooler.js，并将其重命名为 htmx。然后他惊讶的发现 Django 社区迅速并戏剧性地接受了它！

图片来源：https://lp.jetbrains.com/django-developer-survey-2021-486/

Carson Gross认为 htmx 设法抓住了开发者对现有 Javascript 框架不满的浪潮，“这些框架非常复杂，并且经常将 Django 变成一个愚蠢的 JSON 生产者”，而 htmx 与开箱即用的 Django 配合得更好，因为它通过 html 与服务器交互，而 Django 非常擅长生成 html。

对于 htmx 的迅速走红，Carson Gross 发出了一声感叹：这真是“十年窗下无人问，一举成名天下知（this is another example of a decade-long overnight success）”。

htmx 的实际效果

可以肯定的一点是 htmx 绝对能用，单从理论上讲，这个方法确实值得称道。但软件问题终究要归结于实践效果：效果好吗，能不能给前端开发带来改善？

在 DjangoCon 2022 上，Contexte 的 David Guillot 演示了他们在真实 SaaS 产品上实现了从 React 到 htmx 的迁移，而且效果非常好，堪称“一切 htmx 演示之母”（视频地址：https://www.youtube.com/watch?v=3GObi93tjZI）。

Contexte 的项目开始于 2017 年，其后端相当复杂，前端 UI 也非常丰富，但团队非常小。所以他们在一开始的时候跟随潮流选择了 React 来“构建API绑定 SPA、实现客户端状态管理、前后端状态分离”等。但实际应用中，因为 API 设计不当，DOM 树太深，又需要加载很多信息，导致 UI“非常非常缓慢”。在敏捷开发的要求下，团队里唯一的 Javascript 专家对项目的复杂性表现得一无所措，因此他们决定试试 htmx。

九大数据提升

于是我们决定大胆尝试，花几个月时间用简单的 Django 模板和 htmx 替换掉了 SaaS 产品中已经使用两年的 React UI。这里我们分享了一些相关经验，公布各项具体指标，希望能帮同样关注 htmx 的朋友们找到说服 CTO 的理由！

1. 这项工作共耗费了约 2 个月时间（使用 21K 行代码库，主要是 JavaScript）

2. 不会降低应用程序的用户体验（UX）

3. 将代码库体积减小了 67%（由 21500 行削减至 7200 行）

4. 将 Python 代码量增加了 140%（由 500 行增加至 1200 行）；这对更喜欢 Python 的开发者们应该是好事

5. 将 JS 总体依赖项减少了 96%（由 255 个减少至 9 个）

1. 将 Web 构建时间缩短了 88%（由 40 秒缩短至 5 秒）

2. 首次加载交互时间缩短了 50%至 60%（由 2 到 6 秒，缩短至 1 到 2 秒）

3. 使用 htmx 时可以配合更大的数据集，超越 React 的处理极限

4. Web 应用程序的内存使用量减少了 46%（由 75 MB 降低至 40 MB）

这些数字令人颇为意外，也反映出 Contexte 应用程序高度契合超媒体的这一客观结果：这是一款以内容为中心的应用程序，用于显示大量文本和图像。很明显，其他 Web 应用程序在迁移之后恐怕很难有同样夸张的提升幅度。

但一些开发者仍然相信，大部分应用程序在采用超媒体/htmx 方法之后，肯定也迎来显著的改善，至少在部分系统中大受裨益。

开发团队组成

可能很多朋友没有注意，移植本身对团队结构也有直接影响。在 Contexte 使用 React 的时候，后端与前端之间存在硬性割裂，其中两位开发者全职管理后端，一位开发者单纯管理前端，另有一名开发者负责“全栈”。（这里的「全栈」，代表这位开发者能够轻松接手前端和后端工作，因此能够在整个「栈」上独立开发功能。）

而在移植至 htmx 之后，整个团队全都成了“全栈”开发人员。于是每位团队成员都更高效，能够贡献出更多价值。这也让开发变得更有乐趣，因为开发人员自己就能掌握完整功能。最后，转向 htmx 也让软件优化度上了一个台阶，现在开发人员可以在栈内的任意位置进行优化，无需与其他开发者提前协调。

htmx 是传统思路的回归

如今，单页应用（SPA）可谓风靡一时：配合 React、Redux 或 Angular 等库的 JS 或 TS 密集型前端，已经成为创建 Web 应用程序的主流方式。以一个需要转译成 JS 的 SPA 应用为例：

但 htmx 风潮已经袭来，人们开始强调一种“傻瓜客户端”方法，即由服务器生成 html 本体并发送至客户端，意味着 UI 事件会被发送至服务器进行处理。

用这个例子进行前后对比，我们就会看到前者涉及的活动部件更多。从客户端角度出发，后者其实回避了定制化客户端技术，采取更简单的方法将原本只作为数据引擎的服务器变成了视图引擎。

后一种方法被称为 AJAX（异步 JavaScript 与 XML）。这种简单思路能够让 Web 应用程序获得更高的响应性体验，同时消除了糟糕的“回发”（postback，即网页完全刷新），由此回避了极其低效的“viewstate”等.NET 技术。

htmx 在很多方面都体现出对 AJAX 思路的回归，最大的区别就是它仅仅作为新的声明性 html 属性出现，负责指示触发条件是什么、要发布到哪个端点等。

另一个得到简化的元素是物理应用程序的结构与构建管道。因为不再涉及手工编写 JS，而且整个应用程序都基于服务器，因此不再对 JS 压缩器、捆绑器和转译器做（即时）要求。就连客户端项目也能解放出来，一切都由 Web 服务器项目负责完成，所有应用程序代码都在.NET 之上运行。从这个角度来看，这与高度依赖服务器的Blazor Server编程模型倒是颇有异曲同工之妙。

技术和软件开发领域存在一种有趣的现象，就是同样的模式迭起兴衰、周而复始。随着 SPA 的兴起，人们一度以为 AJAX 已经过气了，但其基本思路如今正卷土重来。这其中当然会有不同的权衡，例如更高的服务器负载和网络流量（毕竟现在我们发送的是数据视图，而不只是数据），但能让开发者多个选择肯定不是坏事。

虽然不敢确定这种趋势是否适用于包含丰富用户体验的高复杂度应用程序，但毫无疑问，相当一部分 Web 应用程序并不需要完整的 SPA 结构。对于这类用例，简单的 htmx 应用程序可能就是最好的解决方案。

参考链接：

https://news.ycombinator.com/item?id=33218439

https://htmx.org/essays/a-real-world-react-to-htmx-port/

https://www.reddit.com/r/django/comments/rxjlc6/htmx_gaining_popularity_rapidly/

https://mekhami.github.io/2021/03/26/htmx-the-future-of-web/

https://www.compositional-it.com/news-blog/more-on-htmx-back-to-the-future/