真实世界 React -> htmx 移植

在理论上谈论 REST & HATEOAS 或者描述 超媒体驱动应用程序 架构，都很好，但归根结底，软件重要的是实用性：它是否有效？它是否有所改进？

我们可以肯定地说 htmx 有效，因为我们在自己的软件中使用了它。但很难说它比其他方法有改进，因为我们没有进行过 htmx 与例如 react 的苹果对苹果比较。

直到现在。

David Guillot 在 Contexte 进行了我们称之为 “史上最伟大的 htmx 演示” 的演示，在 DjangoCon 2022

从 React 到 htmx，应用于真实的 SaaS 产品：我们做到了，而且效果很棒！

我们大胆尝试，用简单的 Django 模板和 htmx 在几个月内替换了我们 SaaS 产品的 2 年开发的 React UI。我们想与大家分享我们的经验，并提供各种方面的具体指标，说服你的 CTO！

#视频

你可以（应该！）在这里观看完整的演示

#执行摘要

• 整个过程大约花费了 2 个月（代码库有 21K LOC，主要是 JavaScript）
• 应用程序的用户体验（UX）没有减少
• 他们将代码库大小减少了67%（从 21,500 LOC 到 7200 LOC）
• 他们增加了python 代码140%（从 500 LOC 到 1200 LOC），如果你更喜欢 python 而不是 JS，这是好事
• 他们将JS 依赖项总数减少了96%（从 255 到 9）
• 他们将网页构建时间减少了88%（从 40 秒到 5 秒）
• 第一次加载到交互的时间减少了50-60%（从 2 到 6 秒到 1 到 2 秒）
• 使用 htmx 时，更大的数据集成为可能，因为 react 无法处理这些数据
• 网页应用程序的内存使用量减少了46%（从 75MB 到 45MB）

#分析

这些数据令人瞠目结舌，反映了 Contexte 应用程序非常适合超媒体：它是一个以内容为中心的应用程序，显示大量文本和图像。我们预计并非所有 Web 应用程序都能看到这些数据。

然而，我们预计许多应用程序可以通过采用超媒体/htmx 方法（至少在他们系统的一部分）看到显著的改进。

#开发团队组成

移植的一个容易被忽视的方面是它对团队结构的影响。当 Contexte 使用 react 时，后端和前端之间存在明显的界限，两名开发者完全是后端，一名开发者完全是前端，一名开发者是“全栈”。

（这里“全栈”意味着他们能够在前端和后端都进行工作，因此能够独立地开发整个“栈”的功能。）

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

#幻灯片

演示的幻灯片可以在这里找到（一定要查看优秀的演讲者笔记！）

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