数据采集、数据融合、平台能力构建、AI算法支持等方面最新技术实践分享>> 了解详情
写点什么

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

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

PingCAP 入选 2022 Gartner 云数据库“客户之声”,获评“卓越表现者”最高分

PingCAP

TiDB

百度交易中台之钱包系统架构浅析

百度Geek说

系统架构 百度app

2022年中国手机银行年度专题分析

易观分析

手机银行

既不是研发顶尖高手,也不是销售大牛,为何偏偏获得 2 万 RMB 的首个涛思文化奖?

TDengine

数据库 tdengine 时序数据库

CVPR2022 | 上科大x小红书首次提出动作序列验证任务,可应用于体育赛事打分等多场景

小红书技术REDtech

Transformer CVPR2022 视频动作理解 动作序列验证

linux 密钥登录

CRMEB

容器云是什么意思?与堡垒机有什么区别?

行云管家

云计算 运维 容器云 堡垒机 IT运维

不容错过的2大直播!Linux应用运行抖动的背后&身临其境体验Anolis OS|第25-26期

OpenAnolis小助手

Linux 开源 操作系统 直播 龙蜥大讲堂

5000字解析:实战化场景下的容器安全攻防之道

青藤云安全

网络安全 容器安全 攻防演练

Linux下玩转nginx系列(六)---nginx实现cache(缓存)服务

anyRTC开发者

nginx Linux 缓存 音视频 服务器

云堡垒机分布式集群部署优缺点简单说明-行云管家

行云管家

云计算 网络安全 堡垒机 云堡垒机

北京Java培训 | java设计模式之原型模式

@零度

JAVA开发 原型设计模式

百问百答第43期:应用性能探针监测原理-PHP探针

博睿数据

智能运维 博睿数据 性能监测 百问百答

《网络是怎么样连接的》读书笔记 - ADSL

懒时小窝

网络编程

手写多层轮播图_篇二【前端造轮子/大作业】【gowork.fit】

上进小菜猪

6月月更

3M互助智能合约系统开发搭建技术

薇電13242772558

智能合约

啃论文俱乐部 | 压缩算法团队:我们是如何开展对压缩算法的学习研究

OpenHarmony开发者社区

OpenHarmony

西安Java培训 | java设计模式之工厂设计模式

@零度

设计模式 JAVA开发

居家办公初体验之新得分享| 社区征文

阿Q说代码

居家办公 初夏征文 心得分享

浅谈德州扑克AI核心算法:CFR

行者AI

人工智能 AI 强化学习

见证荣耀|长三角区块链应用创新大赛复赛于旺链科技成功举办

旺链科技

区块链 产业区块链 区块链应用创新

Flink CDC MongoDB Connector 的实现原理和使用实践

Apache Flink

mongodb 大数据 flink 流计算 实时计算

这不会又是一个Go的BUG吧?

捉虫大师

Java Go 死锁

高效远程办公手册| 社区征文

程序员-小江

初夏征文

【深入理解TcaplusDB技术】TcaplusDB业务数据备份

tcaplus

数据库 nosql TcaplusDB 腾讯游戏

小程序直播互动功能运行在App里?

Speedoooo

小程序 直播带货 移动开发 直播技术 小程序容器

Apache ShardingSphere 5.1.2 发布|全新驱动 API + 云原生部署,打造高性能数据网关

SphereEx

云原生 ShardingSphere 版本更新

融云 x DiDO:中东热土上的语音社交「萌狮」

融云 RongCloud

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