快手、孩子王、华为等专家分享大模型在电商运营、母婴消费、翻译等行业场景的实际应用 了解详情
写点什么

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:2421806

评论 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 · 安徽
回复
没有更多了
发现更多内容

小程序容器是什么技术?能助力物联网企业红海突围?

Speedoooo

小程序 物联网 IoT 小程序容器

架构实战营毕业总结

哈喽

「架构实战营」

整整面试两月,凭借这份15w字Java面试刷题宝典成功入职阿里

Java全栈架构师

Java spring 程序员 面试 算法

leetcode 416. Partition Equal Subset Sum 分割等和子集(中等)

okokabcd

LeetCode 动态规划 数据结构与算法

从一个被应用商店坑了的BUG说起

IT蜗壳-Tango

自动化测试 IT蜗壳教学 6月月更

福昕软件受邀亮相2022先进制造业数智发展论坛

联营汇聚

60天远程办公经验分享 | 社区征文

Albert

初夏征文

什么是IGMP?IGMP与ICMP有啥区别?

wljslmz

网络协议 6月月更 IGMP 组播

如何使用物联网低代码平台进行服务管理?

AIRIOT

低代码 物联网 低代码开发平台 低代码平台

细说GaussDB(DWS)复杂多样的资源负载管理手段

华为云开发者联盟

数据库 并发 CPU管控

架构实战营模块 5 作业

Naoki

架构实战营

MySQL,MVCC详解,快照读在RC、RR下的区别

乌龟哥哥

6月月更

在线文本数字识别列表求和工具

入门小站

工具

国内酒店交易DDD应用与实践——理论篇

Qunar技术沙龙

“造车”,腾讯抄了华为后路

科技新知

华为云AOM 2.0版本发布

华为云开发者联盟

运维 华为云 自动化运维 AOM

第八届“互联网+”大赛 | 云原生赛道邀你来挑战

阿里巴巴云原生

阿里云 云原生 大赛

攻防演练中的防守基石——全方位监控

穿过生命散发芬芳

6月月更 攻防演练

linux之ClamAV杀毒软件安装配置

入门小站

Linux

VoIP Push 在海外音视频业务中的应用

融云 RongCloud

jfinal中如何使用过滤器监控Druid监听SQL执行?

华为云开发者联盟

sql 开发

洞见科技作为「唯一」隐私计算数商,「首批」入驻长三角数据要素流通服务平台

洞见科技

web3 的身份验证之以太坊签名消息

devpoint

区块链 以太坊 Web3.0 6月月更

Freedom自由协议质押挖矿系统开发

开发微hkkf5566

小迈科技 X Hologres:高可用的百亿级广告实时数仓建设

阿里云大数据AI技术

sql 大数据 分布式计算

DevCloud加持下的青软,让教育“智”上云端

华为云开发者联盟

云计算 软件 后端 开发 教育

CorelDRAW2022全新版V24.1.0.360更新

茶色酒

cdr2022

透过华为军团看科技之变(五):智慧园区

脑极体

在线SQL转CSV工具

入门小站

工具

软件快速交付真的需要以安全为代价吗?

华为云开发者联盟

云计算 敏捷 安全 后端 开发

小暑至,盛夏始,7月月更活动伴随着盛夏走来啦!

InfoQ写作社区官方

热门活动 7月月更

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