共计 3535 个字符，预计需要花费 9 分钟才能阅读完成。
本文来自 InfoQ, 作者:Tina，核子可乐
技术和软件开发畛域存在一种乏味的景象，就是同样的模式迭起兴衰、周而复始。
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…）。
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 个）
- 将 Web 构建工夫缩短了 88%（由 40 秒缩短至 5 秒）
- 首次加载交互工夫缩短了 50% 至 60%（由 2 到 6 秒，缩短至 1 到 2 秒）
- 应用 htmx 时能够配合更大的数据集，超过 React 的解决极限
- 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/
