Hotwire vs. React：‘单人框架’指南

看起来您只提供了来源链接，而没有贴出需要翻译的正文内容。请把要翻译的文本（包括任何 Markdown 格式）粘贴在这里，我会帮您翻译成简体中文，并保留代码块、链接和原有的格式。谢谢！

默认选择

在过去的五年里，“标准 Web 堆栈”已经不可争议：
后端 API（Rails/Node） + SPA 前端（React/Vue）。
这是在训练营中教授的架构，招聘者要求的技能，并且长期以来是获得“现代”感受的唯一方式——无页面刷新、流畅切换、实时更新。

但它是有代价的。我把它称为 React 税。
随着 Rails 7（以及现在的 Rails 8）和 Hotwire 的成熟，这个税已经不再是强制性的。以下是我认为 Hotwire 是 95 % Rails 项目更优选择的原因。

React 的隐藏成本

当你选择 React 时，你并不是在构建一个单一的应用，而是构建 两个：

• 后端 – 序列化、JWT、CORS、版本控制。
• 前端 – 路由管理、全局状态（Redux/Context）、effect hooks、package.json 地狱。

一个简单的功能比如 “重命名项目” 会扩展为许多步骤：

• 前端：乐观更新 UI 状态。
• 前端：发起 API 调用。
• 后端：处理认证。
• 后端：更新数据库。
• 后端：序列化 JSON 响应。
• 前端：处理成功/错误。
• 前端：重新同步本地状态。

Hotwire 的简化流程

使用 Hotwire 时，流程压缩为：

• 控制器 – 更新数据库。
• 视图 – 渲染 HTML。

计算机科学中最难的问题是给事物命名。第二难的是缓存失效。把数据库状态复制到 Redux store 或 React Query 缓存中会招致 bug：列表陈旧、计数不匹配、UI 显示 “Premium” 而 API 返回 403。Hotwire 拒绝了这种前提。

Turbo 让服务器成为唯一的真相来源。当数据变化时，你用服务器返回的全新 HTML 替换屏幕上的 HTML 片段，消除了一整类 “状态不同步” 的 bug，因为根本不存在客户端状态。

单人框架

Rails 8 推出了 “单人框架” 的概念：单个开发者应该能够构建以前需要五人团队的创业项目。如果你是独立开发者或小团队使用 React，你大约会把 50 % 的时间花在管理后端与前端之间的粘合上。

使用 Hotwire（Turbo Drive + Turbo Frames + Stimulus）时，你可以在 Ruby/ERB 领域完成约 90 % 的工作：

• 编写标准的 Rails 视图。
• 通过 Turbo Drive 免费获得 SPA 速度的导航。
• 通过 Frames 实现动态局部更新。

上下文切换成本

这在 2016 年是真实的；今天已经不再成立。

Turbo Drive 与 Turbo Streams

Turbo Drive 拦截链接点击和表单提交，使标准的 Rails 应用感觉瞬时。它合并 并在不进行完整页面刷新的情况下替换。

需要实时功能？Turbo Streams 搭配 ActionCable 只需几行 Ruby 就能向数百万用户广播更新：

# app/models/message.rb
after_create_commit { broadcast_append_to "chat_room" }

这行代码会创建一个 WebSocket 连接，将新消息追加到每个活跃用户的 DOM 中。在 React 中实现同样的功能需要搭建 socket context、监听器、状态 reducer 以及安全检查。

React 仍然有意义的情况

我并不是 React 的反对者；它是一项了不起的工程技术。如果满足以下条件，你仍然可以使用 React（或 Vue/Svelte）：

• 你在构建高保真工具（例如 Figma、浏览器内视频编辑器、复杂的拖拽式 Trello 克隆）。
• 你需要 “离线优先”（必须在没有网络的情况下 100 % 工作的 PWA）。
• 你的 API 为多个客户端（移动端、网页、桌面端）提供完全相同的接口——尽管原生应用也在向服务器驱动 UI 方向发展。

大多数情况

对于绝大多数 SaaS 产品——仪表盘、市场、社交网络、项目管理工具——“React 税”是资源的浪费。Hotwire 能以约 10 % 的复杂度提供 80 % 的 React 交互性。

如果你想快速交付功能，请使用 Hotwire.*
如果你想配置 Webpack，请使用 React.

你是坚持使用 React 生态系统，还是已经尝试过 Hotwire 的生活方式？在下方讨论吧。