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

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

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

编译｜核子可乐、Tina

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

htmx的走红

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

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

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

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

从任何用户**发出AJAX请求。

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

在响应中发送该html。

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

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

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

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

对于htmx的迅速走红，CarsonGross发出了一声感叹：这真是“十年窗下无人问，一举成名天下知（thisisanotherexampleofadecade-longovernightsuccess）”。

htmx的实际效果

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

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

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

九大数据提升

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

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

不会降低应用程序的用户体验（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%（由75MB降低至40MB）

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

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

开发团队组成

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

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

htmx是传统思路的回归

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

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

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

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

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

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

技术和软件开发领域存在一种有趣的现象，就是同样的模式迭起兴衰、周而复始。随着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/

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

声明：本文为InfoQ编译，未经许可禁止转载。