AI 年度盘点与2025发展趋势展望,50+案例解析亮相AICon 了解详情
写点什么

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

  • 2022-10-17
    北京
  • 本文字数:3014 字

    阅读完需:约 10 分钟

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

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

 

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?v=3GObi93tjZI)。

 

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

 

九大数据提升

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

 

  1. 这项工作共耗费了约 2 个月时间(使用 21K 行代码库,主要是 JavaScript)

  2. 不会降低应用程序的用户体验(UX)

  3. 将代码库体积减小了 67%(由 21500 行削减至 7200 行)

  4. 将 Python 代码量增加了 140%(由 500 行增加至 1200 行);这对更喜欢 Python 的开发者们应该是好事

  5. 将 JS 总体依赖项减少了 96%(由 255 个减少至 9 个)

 


  1. 将 Web 构建时间缩短了 88%(由 40 秒缩短至 5 秒)

  2. 首次加载交互时间缩短了 50%至 60%(由 2 到 6 秒,缩短至 1 到 2 秒)

  3. 使用 htmx 时可以配合更大的数据集,超越 React 的处理极限

  4. 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/

 

2022-10-17 18:2422640

评论 7 条评论

发布
用户头像
这有点像pjax
2022-10-25 08:35 · 广东
回复
用户头像
看看 Rails
2022-10-24 15:51 · 上海
回复
用户头像
yyds
2022-10-21 08:52 · 浙江
回复
用户头像
化繁为简,适合小型项目
2022-10-20 15:53 · 上海
回复
用户头像
在react vue之前,曾经出现过一个不知名的叫pjax的方案,和这个很类似,用node写小服务的时候尝试过,现在替换成这个感觉也可以
2022-10-19 11:57 · 浙江
回复
用户头像
由简入繁,然后由繁入简
2022-10-18 08:34 · 辽宁
回复
用户头像
看着让人心动
2022-10-18 06:30 · 安徽
回复
没有更多了
发现更多内容

网信办严厉查处诱导未成年人参与直播打赏行为:直播打赏行业乱象必须整治

石头IT视角

有return的情况下try catch finally的执行顺序

技术小生

7月月更

[ kitex 源码解读 ] Kitex 扩展性设计思路

baiyutang

Go golang 云原生 微服务框架 kitex

向量化引擎对HTAP的价值与技术思考

OceanBase 数据库

oceanbase

Elephant Swap的LaaS方案优势分析,致eToken表现强势

BlockChain先知

在 SAP 云平台上部署和运行 Docker 应用

汪子熙

Docker Kubernetes 云原生 SAP 7月月更

在线XML转CSV工具

入门小站

工具

一个15年ABAP老兵的建议:了解这些基础知识,对ABAP开发有百利而无一害

汪子熙

后台开发 SAP abap Netweaver 7月月更

附答案 | 最强Python面试题之Python基础题(1)

KEY.L

7月月更

什么是云渲染?渲染速度有多快?一文告诉你

Finovy Cloud

计算机 云渲染 集群渲染

Python动态属性有什么用

和牛

测试

振奋人心!元宇宙!下一代互联网的财富风口

CECBC

如何在OneFlow中新增算子

OneFlow

深度学习 算子

快速搭建个人博客网站——Hexo

空城机

Hexo 个人博客 7月月更

用 React 结合 SAP UI5 Web Components 来开发 SAP Fiori 应用

汪子熙

JavaScript 前端开发 SAP SAP UI5 7月月更

G1GC算法读书笔记(更新中)

老猎人

优必选科技眼中的AI机器人时代

优必选科技

AI 机器人

【Docker 那些事儿】初始 Kubernetes 容器管理平台(下)

Albert Edison

Docker Kubernetes 容器 云原生 7月月更

音频的价值、AI Codec 的意义与算法能力的边界丨一期一会 • 音频工程师专场

声网

音频技术 一期一会

Ansible项目最佳实践

穿过生命散发芬芳

ansible 7月月更

机器学习-集成学习

AIWeker

机器学习 7月月更

超干货!彻底搞懂单工、半双工、全双工的区别与联系

wljslmz

网络技术 7月月更 通信模式 双工

元宇宙浪潮震撼来袭,抓住时机,齐心协力

CECBC

Vue Cli Study

程序员海军

vuecli 7月月更

中国经济网:“元宇宙”炙手可热

CECBC

Envoy分布式链路追踪

阿泽🧸

envoy 7月月更

SeekTiger的Okaleido有大动作,生态通证STI会借此爆发?

股市老人

等额本金递增还款/等额本金递减按揭房贷还款计算器

入门小站

工具

【刷题记录】17. 电话号码的字母组合

WangNing

7月月更

数据中台建设误区

奔向架构师

数据中台 7月月更

Htmx意外走红,我们从React“退回去”后:代码行数减少 67%,JS 依赖项从 255 下降到 9_移动_Tina_InfoQ精选文章