一个真实的 React 到 htmx 移植案例

理论上谈论 REST 和 HATEOAS 或描述 超媒体驱动的应用 架构固然很好，但归根结底，软件中最重要的是实际效果：它有效吗？它能改进事情吗？

我们可以肯定地说，htmx 有效，因为我们自己在软件中使用它。但要说它比其他方法_更好_，则很难，因为我们还没有进行过苹果对苹果的比较，来评估 htmx 与 例如 React 的差异。

直到现在。

Contexte 的 David Guillot 在 DjangoCon 2022 上进行了我们称之为 “所有 htmx 演示之母” 的演示：

在真实世界的 SaaS 产品中从 React 转向 htmx：我们做到了，而且棒极了！

我们一头扎进去，用简单的 Django 模板和 htmx 在几个月内替换了我们 SaaS 产品的两年 React UI。我们想与大家分享我们的经验，包括各种方面的具体指标，并说服你们的 CTO！

视频

您可以（应该！）在这里观看整个演示：

执行摘要

• 该工作耗时大约 2 个月（针对一个 21K 行代码的代码库，主要为 JavaScript）
• 应用的用户体验 (UX) 没有减少
• 他们将代码库大小减少了 67%（从 21,500 行减少到 7200 行）
• 他们将 Python 代码 增加了 140%（从 500 行增加到 1200 行），如果您更喜欢 Python 而非 JS，这是一件好事
• 他们将总JS 依赖减少了 96%（从 255 个减少到 9 个）
• 他们将Web 构建时间减少了 88%（从 40 秒减少到 5 秒）
• 首次加载交互时间减少了 50-60%（从 2 到 6 秒减少到 1 到 2 秒）
• 使用 htmx 时可以处理更大的数据集，因为 React 无法处理这些数据
• Web 应用内存使用量减少了 46%（从 75MB 减少到 45MB）

分析

这些数字令人震惊，它们反映了 Contexte 应用极易适应超媒体的事实：这是一个以内容为重点的应用，显示大量文本和图像。我们不会期望每个 Web 应用都能看到这些数字。

然而，我们 确实 期望 许多 应用通过采用超媒体/htmx 方法，至少在其系统的一部分中，看到显著改进。

开发团队构成

移植的一个容易被忽略的方面是它对团队结构的影响。当 Contexte 使用 React 时，后端和前端之间存在严格的分工，有两个开发者完全负责后端，一个开发者完全负责前端，还有一个开发者是“全栈”。

（这里的“全栈”意味着他们能舒适地在前端和后端工作，从而能够完全独立地开发整个“栈”中的功能。）

移植到 htmx 后，整个团队 都成了“全栈”开发者。这意味着每个团队成员都更有效率，能够贡献更多价值。它还让开发更有趣，因为开发者可以拥有整个功能。最后，它可以导致更优化的软件，因为开发者可以在栈的任何地方进行优化，而无需与其他开发者协调。

幻灯片

演示的幻灯片可以在此处找到（务必查看优秀的演讲者笔记！）

https://docs.google.com/presentation/d/1jW7vTiHFzA71m2EoCywjNXch-RPQJuAkTiLpleYFQjI/edit?usp=sharing