Misago 弃用 React.js，拥抱 HTMX 简化交互
Removing React.js from the codebase and adapting Htmx for UI interactivity
作为 Misago 论坛软件的开发负责人，我决定彻底移除代码库中的 React.js，转而采用 HTMX 来实现 UI 交互。过去，我们不得不为 Django 模板和 React.js 组件重复开发页面，导致维护成本高昂、翻译文件冗余，且巨大的 JavaScript 包严重拖慢了旧设备的性能。经过深思熟虑，我意识到论坛软件并不需要全栈单页应用，传统的服务器端渲染配合局部动态更新已足够满足用户需求。HTMX 让我们能用声明式的方式轻松替换页面局部 HTML，无需复杂的 JSON 序列化或专用 JavaScript。虽然迁移过程需要分阶段进行，甚至短期内会出现部分页面回退到多页应用的状态，但这将显著减少 JS 体积，让开发回归简单高效。
互联网论坛软件拥有足够的交互性，但这种交互性通常只局限于页面的特定区域，而这些功能在 React.js 出现之前的多年里早已实现。
HN 评论区
183- james2doyle
我最近确实尝试在一个网站上使用 HTMX，用的是 4.0 beta 版。该网站需要一个交互式的可过滤产品列表页面体验，用来列出所有供应商。左边是表单过滤器，右边是结果“卡片”列表。
我遇到的问题在于，当把所有东西整合成一个“响应”时，整个体验变得非常缓慢。当结果超过六个时，发送包含大型选择列表的完整表单 HTML 以及结果响应，会出现明显的延迟。
最终我切换到了 Alpine Ajax（https://alpine-ajax.js.org/），将表单从响应中剥离出来，仅使用本地的 x-data 来跟踪状态。这大大减少了需要回传的 HTML 量，只剩下结果列表。虽然我把表单做得稍微复杂了一点，但整体体验感觉流畅多了。两个版本都通过 URL 同步表单状态，并保持初始渲染为服务器生成的完整 HTML。
我发现 Alpine + Alpine Ajax 的体积甚至比 HTMX 4 还要小，尽管在我看来，如果你需要交互性但不想仅仅为了切换一些类名或属性就触发请求，它提供了更多功能，且方式更平易近人、更直观。当然，你也可以两者结合使用（我一开始也是这么走的），但这等于混合了两个世界，同时也增大了包体积。
我依然喜欢 HTMX，以后可能还会再用。只是我发现对于交互式体验来 […]
- snorremd
我觉得 HTMX 非常适合论坛软件。论坛网站主要交付的是非交互式内容，形式为文本，可能还有一些音频、视频或图片内容。所有这些都可以用 HTML 和 CSS 表示。
有了 HTMX，你可以实现局部渲染和通过服务器发送事件（SSE）进行实时更新。这能让你获得大部分“客户端”的感觉，即内容根据用户操作动态加载。
我能想到的论坛中唯一真正动态的 SPA 式功能是 WYSIWYG 编辑器，但你可以把它构建为一个 Web 组件。也许灵活的引用和引用系统（类似 Medium 文章中的评论功能）在纯 HTMX 中会稍微困难一些。所以你可能需要用客户端 JS 构建一些东西。但主要体验完全可以用 HTMX 构建。
- rubylimetea
正如其他人提到的，HTMX 不太适合丰富的交互性。
举个例子：渲染一个可滚动的列表，你需要在滚动中途更改 li 项的内容——由于它在渲染时替换了整个 HTML，滚动位置会重置到顶部。虽然有变通方法，比如 DOM 黑客手段，但它们并不理想。
React 的设计初衷就是为了解决这类问题。它们在底层做了一些神奇的魔法，以支持无缝的 DOM 协调，以及像将整个组件作为另一个组件的 prop 进行透传（prop drilling）等操作。这使它们能够以更细粒度的方式操作 DOM，而无需重新渲染整个页面。
Next.js SSR 之所以有效，是因为它是围绕 React 设计的。所以它们给你提供了所有你想要的 SSR 功能，同时你仍然拥有客户端 React 来实现丰富的交互设计和其他 SPA 的便利之处。
所以，如果有人发布了一个类似 SSR 的东西（比如 htmx），感觉总像是缺了点什么。
也许 htmx 需要一个更有主见的框架，更深入地涉足高性能渲染和状态管理。
或者，也许它们专注于“基础网页”市场。谁知道呢，也许这些会卷土重来。PDF 被独立的 HTML 取代之类的，人们使用 HTMX；或者也许它被用于开发环境中的 HTML 邮件设计，在某个未来邮件可以拥有事件（谁知道呢）。这只是几个想法。
目前感觉它不完整，或者我找不到合适的切入点。不过我很欣赏这个概念，HTML/JS 本该如此。
- prologic
我基本上在所有 Web 应用中都用 HTMX，包括在 iOS/Android 上运行如原生应用般的 PWA。太棒了！我还搭配使用了 DaisyUI + TailwindCSS。你绝对选错不了，用普通的 HTML 加上局部模板，配合 HTMX 为浏览器添加的 SPA 式交互扩展来编写 Web 应用，这种感觉相当愉悦。
- sgt
很高兴他们做了这个决定。Htmx 非常适合服务器端渲染——而在许多或大多数情况下，这本来就是你该做的。你总可以在模板中嵌入一个微型 VueJS 或 ReactJS 应用，以实现非常定制的交互性。
- n4pw01f
两年前就用 HTMX 替换了 React / Vue，至今运行良好。
Hono + WebComponents + HTMX + serverless 现在是我应用的后台架构。
- hazrmard
对我来说，使用 Django 搭配前端框架一直是个挣扎。（我只是个业余爱好者。）我认为将后端拆分为 RESTful API 能让两者更好地结合。我看过 django-rest-framework（https://www.django-rest-framework.org/）和 django-ninja（https://django-ninja.dev/）。当然，这样做就丢弃了 Django 框架自带的许多“开箱即用”的功能。也许只用 Django 模板做管理后台或内部面向的工作，而用 React 做面向客户的网站，是一个健康的折衷方案？
- thrownaway561
这事儿三年前就发生了……好奇今天为什么又成了新闻？