Misago 从 React.js 迁移到 HTMX 以提升性能和可维护性

Misago 正在用 HTMX 替换 React.js 以消除冗余代码并提升性能

Misago 正在将其前端架构从基于 React.js 的单页应用（SPA）方式迁移回由 HTMX 驱动的服务器端渲染。此举旨在解决“双重实现”问题：页面被构建了两次——一次作为 Django 模板用于初始加载/SEO，另一次作为 React 组件用于交互——导致维护开销增加和响应时间变慢。

The problems with the React.js and Django hybrid approach

之前的架构需要后端和前端之间进行复杂的同步，这导致了几个技术瓶颈：

• 重复实现： 大多数页面同时存在为 Django 模板和 React 组件，这意味着任何 UI 更改都需要在两个不同的位置进行更新。
• 开发摩擦： 编辑 Django 模板的自定义者经常看到他们的更改短暂闪现后被 React 的客户端渲染覆盖。
• 延迟增加： 为了“预烘焙” React 应用而将数据序列化为 JSON 的需求减慢了服务器响应生成。
• 包体积膨胀： 翻译消息在 django.po 和 djangojs.po 文件中被复制，增加了用户的初始下载大小。
• 性能下降： 大型 JavaScript 包对性能产生负面影响，尤其是在较旧的移动设备上。
• 插件复杂性： 插件开发者被迫同时实现 Django 模板和 React 组件，这需要在站点构建过程中加入 JavaScript 构建步骤。

Why HTMX was chosen for forum interactivity

论坛软件通常需要在隔离的“岛屿”中实现交互——例如管理操作、投票或更新通知——而不是提供完全流畅的 SPA 体验。HTMX 通过在交互时用新的服务器渲染 HTML 替换 HTML 的部分来使这些特定区域变得动态，而无需完全重新加载页面。

通过使用 HTMX，Misago 消除了这些交互对 JSON 序列化和专用 JavaScript 组件的需求。后端只需返回所请求“岛屿”所需的 HTML 片段，浏览器随后将其替换到现有页面中。

Measurable impact on JavaScript bundle sizes

早期的迁移步骤已经显示出总 JavaScript 足迹的减少。例如，将“论坛选项”页面替换为“账户设置”并使用 Django 视图和 HTMX 重写“线程列表”，导致 misago.js 出现以下减少：

• 账户设置迁移： misago.js 减少了 37kb（17kb 已 gzip）。
• 线程列表迁移： misago.js 减少了 48kb（8kb 已 gzip）。

在这些更改之前，Misago 0.39 的基线 JS 大小包括一个 vendor.js 大小为 679kb 和一个 misago.js 大小为 615kb（未压缩）。

Community perspectives on the HTMX transition

围绕此次迁移的技术讨论凸显出一种分歧：一方支持服务器端渲染的简洁性，另一方则主张客户端状态管理的必要性。

Arguments for HTMX in forums

许多开发者认为论坛是 HTMX 的理想使用场景，因为它们主要提供基于文本的内容。一位贡献者指出：

我认为 HTMX 非常适合论坛软件。论坛网站主要提供非交互内容……使用 HTMX，您可以通过服务器发送事件进行部分渲染和实时更新。

Limitations and trade-offs

其他开发者指出，HTMX 在处理“丰富”交互或高频 DOM 更新时可能会遇到困难。一位用户分享了他在产品列表页上的负面体验：

我遇到的问题是，当所有内容一起作为一个“响应”工作时，整个体验变得非常缓慢。返回整个表单的所有 HTML……当结果超过半打时会变得明显卡顿。

另一项批评指出，与 React 相比，HTMX 缺乏细粒度的 DOM 协调。

React 正是围绕这种事情设计的。他们在内部做了一些有趣的魔法来支持无缝的 DOM 协调……如果有人发布类似 SSR 的东西如 htmx 会感觉缺少某些东西。

Future migration strategy

Misago 将逐步过渡到 HTMX，一次一个发布周期地移动单个组件（如 Navbar、线程列表和用户资料）。在此过渡期间，某些页面可能暂时作为标准多页应用（MPA）运行，伴随完整页面重载，除非使用 AJAX 或 HTMX 以防止无法忍受的用户体验摩擦，例如在点赞帖子或投票时。