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

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 事件会被发送至服务器进行处理。
?

文章插图
【Htmx意外走红，我们从React“退回去”后：代码行数减少 67%，JS 依赖项从 255 下降到 9】用这个例子进行前后对比，我们就会看到前者涉及的活动部件更多。从客户端角度出发，后者其实回避了定制化客户端技术，采取更简单的方法将原本只作为数据引擎的服务器变成了视图引擎。
后一种方法被称为 AJAX（异步 Java 与 XML）。这种简单思路能够让 Web 应用程序获得更高的响应性体验，同时消除了糟糕的“回发”（postback，即网页完全刷新），由此回避了极其低效的“viewstate”等.NET 技术。
htmx 在很多方面都体现出对 AJAX 思路的回归，最大的区别就是它仅仅作为新的声明性 html 属性出现，负责指示触发条件是什么、要发布到哪个端点等。
另一个得到简化的元素是物理应用程序的结构与构建管道。因为不再涉及手工编写 JS，而且整个应用程序都基于服务器，因此不再对 JS 压缩器、捆绑器和转译器做（即时）要求。就连客户端项目也能解放出来，一切都由 Web 服务器项目负责完成，所有应用程序代码都在.NET 之上运行。从这个角度来看，这与高度依赖服务器的 Blazor Server 编程模型倒是颇有异曲同工之妙。
技术和软件开发领域存在一种有趣的现象，就是同样的模式迭起兴衰、周而复始。随着 SPA 的兴起，人们一度以为 AJAX 已经过气了，但其基本思路如今正卷土重来。这其中当然会有不同的权衡，例如更高的服务器负载和网络流量（毕竟现在我们发送的是数据视图，而不只是数据），但能让开发者多个选择肯定不是坏事。
虽然不敢确定这种趋势是否适用于包含丰富用户体验的高复杂度应用程序，但毫无疑问，相当一部分 Web 应用程序并不需要完整的 SPA 结构。对于这类用例，简单的 htmx 应用程序可能就是最好的解决方案。
参考链接：
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/
硅谷“网红”技术大牛 Steve Yegge：退休后面试工程主管，他们居然让我写点代码
智联招聘：Q3 全国平均招聘月薪 10168 元；曝特斯拉拒招小鹏前员工；英特尔或裁员数千人，国内公司涉多起劳动纠纷｜Q 资讯
专访“MySQL 之父”：我曾创造 MySQL，也将颠覆 MySQL
另一种“推翻” VS Code 的尝试：JetBrains Fleet 现开放公测