从代码库中移除 React.js 并为 UI 交互性改造 Htmx（2023）
用 HTMX 和服务器渲染的 HTML 替代 React 风格的 SPA，被描述为一种很有吸引力的选择，尤其适合论坛和 CRUD 密集型站点，在这些场景中，大多数交互都很简单，负载大小和可交互时间比丰富的客户端状态更重要。支持者强调堆栈更简单、缓存更好以及首次加载更快，而批评者则认为 HTMX 在复杂、高交互的 UI 场景下扩展性较差，会导致“属性意大利面”，并重演 AngularJS 时代方法中的老问题。许多人最终得出结论：当客户端状态很少、页面更偏文档化时，HTMX 表现良好；但对于更复杂、像应用一样的界面，React/Vue 风格的框架仍然更合适。
HTMX 与 React/SPA 框架的适用范围
- 许多人认为 HTMX 非常适合服务器渲染、内容密集或 CRUD 风格的应用（论坛、管理后台、表单、筛选、分页）。
- 也有人认为，React/Vue/Solid 风格的框架更适合复杂、高交互、具有状态的 UI（聊天、通知、编辑器、媒体播放器、DAW）。
- 关于现代前端是否已围绕 JSX “稳定下来”存在争论；一些人认为是这样（React/Solid 占主导），另一些人则指出有许多主流框架默认并不使用 JSX。
性能、流量与缓存
- 支持 HTMX 的评论认为：发送的 JS 更少、首次渲染更快、HTML 片段缓存更简单，并且对低端设备和高流量落地页更友好。
- 批评者声称，带有 SSR/hydration 和 CDN 的 React 也可以很高效；在大规模场景下（>10k req/s），为 HTMX 生成大量 HTML 片段可能成本很高。
- 一位实践者发现，当为复杂筛选返回大量 HTML 响应时，HTMX 很慢；改用 Alpine + 局部片段后，负载更小，体感也更快。
状态管理与“意大利面”担忧
- 反对者认为，HTMX/基于属性的方法类似 Angular 1.0：代码片段分散、状态管理困难，最终会“意大利面化”。
- HTMX 支持者反驳说，客户端状态应尽量最小；真实状态在服务器上，HTML 更新只是反映服务器端的真实状态。
- 也有人表示，团队在 HTMX 之后又回到了 React，因为 HTMX 变得难以管理；但也有人说基于 HTMX 的系统依然更易维护。
交互能力的限制与变通方案
- 被指出的薄弱点包括：页面内复杂交互（在滚动过程中更新的滚动列表、文本选择保持、复杂的 facet 表单）。
- 建议的缓解方式包括：DOM morphing 扩展、out-of-band swaps、将 HTMX 与小型 JS 组件混用（Alpine、Web Components、Leaflet 等）。
- 有人认为 HTMX 对“像应用一样”的体验并不完整；也有人建议采用混合架构（大多数页面用 HTMX，重型组件用 React/Vue “islands”）。
使用场景、工具与替代方案
- 有热情的反馈称 HTMX 可驱动完整 Web 应用，甚至包括 PWA；离线支持需要 service workers 和大量缓存，有些人认为这很繁琐。
- 对 HTMX 的组件组合能力较弱、缺乏类似 Storybook 的工具链提出了抱怨；建议包括类似 LiveView 的系统、Places.js、Pyview，或以 JS 为先的 SSR 框架。
- 多人强调并不存在放之四海而皆准的最佳工具；正确选择取决于交互程度、状态复杂度、规模以及团队技能。