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

编译｜核子可乐、Tina
技术和软件开发领域存在一种有趣的现象，就是同样的模式迭起兴衰、周而复始。
htmx 的走红
过去Web非常简单。URL 指向服务器，服务器将数据混合成 html，然后在浏览器上呈现该响应。围绕这种简单范式，诞生了各种JAVA框架，以前可能需要数月时间完成的一个应用程序基本功能，现在借助这些框架创建相对复杂的项目却只需要数小时，我们节省了很多时间，从而可以将更多精力花在业务逻辑和应用程序设计上。
但随着 Web 不断地发展，Java 失控了。不知何故，我们决定向用户抛出大量 App，并在使用时发出不断增加的网络请求；不知何故，为了生成 html，我们必须使用 JSON，发出数十个网络请求，丢弃我们在这些请求中获得的大部分数据，用一个越来越不透明的 Java 框架黑匣子将 JSON 转换为 html，然后将新的 html 修补到 DOM 中......
难道大家快忘记了我们可以在服务器上渲染 html 吗？更快、更一致、更接近应用程序的实际状态，并且不会向用户设备发送任何不必要的数据？但是如果没有 Java，我们必须在每次操作时重新加载页面。
?

文章插图
现在，有一个新的库出现了，摒弃了定制化的方法，这就是 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 设法抓住了开发者对现有 Java 框架不满的浪潮，“这些框架非常复杂，并且经常将 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“非常非常缓慢” 。在敏捷开发的要求下，团队里唯一的 Java 专家对项目的复杂性表现得一无所措，因此他们决定试试 htmx 。
九大数据提升

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

这项工作共耗费了约 2 个月时间（使用 21K 行代码库，主要是 Java）
不会降低应用程序的用户体验（UX）
将代码库体积减小了 67%（由 21500 行削减至 7200 行）
将 Python/ target=_blank class=infotextkey>Python 代码量增加了 140%（由 500 行增加至 1200 行）;这对更喜欢 Python 的开发者们应该是好事
将 JS 总体依赖项减少了 96%（由 255 个减少至 9 个）