校对 ｜ 原子武器果汁、Tina
技术和软件设计领域存在一类有意思的现象，是同样的商业模式接踵而至盛衰、循环往复。
htmx 的爆红
过去Web非常单纯。URL 对准伺服器，伺服器将统计数据混合成 html，接着在应用领域程序上呈现出该积极响应。紧紧围绕这种单纯本体论，问世了各种Javascript架构，以前可能须要数年天数完成的两个插件基本要素，那时借助于那些架构建立相对繁杂的工程项目却只须要数半小时，他们节约了很多天数，从而能将更多精力花在业务方法论和插件设计上。
但随着 Web 急速地发展，Javascript 失去平衡了。无人知晓所踪，他们决定向采用者放出大量 App，并在采用时收到急速增加的互联网允诺；无人知晓所踪，为了聚合 html，他们要采用 JSON，收到十多个互联网允诺，弃置他们在那些允诺中获得的大部分统计数据，用两个愈来愈不透明化的 JavaScript 架构记录器将 JSON 切换为 html，接着将捷伊 html 修整到 DOM 中……
何况大家快忘掉了他们能在伺服器上图形 html 吗？更快、更完全一致、更吻合插件的实际状况，并且不会向采用者电子设备推送任何人无谓的统计数据？但是如果没有 Javascript，他们要在每天操作方式时重新读取网页。
那时，有两个捷伊库出现了，摈弃了订制化的方法，这是 htmx。作为 Web 合作开发未来经营理念的一类实现，它的基本原理很单纯：
从任何人采用者该事件收到 AJAX 允诺。
让伺服器聚合代表该允诺的新插件状况的 html。
在积极响应中推送该 html。
将该原素拉到它应该去的 DOM 中。
个工程项目 intercooler.js。2020 年，他改写了不倚赖 jQuery 的 intercooler.js，并将其重新命名为 htmx。接着他吃惊的发现 Django 街道社区迅速并戏剧化地接受了它！
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 的理由！
这项工作共耗费了约 2 个月天数（采用 21K 行标识符库，主要是 JavaScript）
不会降低插件的采用者体验（UX）
将标识符库体积减小了 67%（由 21500 行削减至 7200 行）
将 Python 标识符量增加了 140%（由 500 行增加至 1200 行）;这对更喜欢 Python 的合作开发者们应该是好事
将 JS 总体倚赖项减少了 96%（由 255 个减少至 9 个）
6. 将 Web 构建天数缩短了 88%（由 40 秒缩短至 5 秒）
7. 首次读取交互天数缩短了 50% 至 60%（由 2 到 6 秒，缩短至 1 到 2 秒）
8. 采用 htmx 时能配合更大的统计数据集，超越 React 的处理极限
9. 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://www.reddit.com/r/django/comments/rxjlc6/htmx_gaining_popularity_rapidly/
https://mekhami.github.io/2021/03/26/htmx-the-future-of-web/
More on HTMX – Back to the Future
声明：本文为InfoQ校对，未经许可禁止转载。
