为什么所有人都在使用React，我们却不需要使用它？—前端战争的历史和Hotwire的诞生原因
最近听到有关Web开发的讨论时，总是会听到同样的话语。
“前端应该用React。”
“现在所有人都在用React。”
“不学React就不是开发人员。”
但这是真的吗？
不，准确来说，只有一半是正确的。
React是一个很好的库。
但问题是...
React在“必要的情况”中实际上只占整个Web服务的10~20%。
令人惊讶的是，
Rails开发者创建的大多数服务
并不属于这10~20%之内。
1. 在React确立之前，许多库英勇地牺牲了
初学者们不知道一个事实。
React从一开始并不是‘绝对的强者’。
现在已经消失的许多框架和库
现在几乎都已经消失了。
AngularJS (已死)
Ember.js (临死)
Backbone.js (几乎消失)
Knockout.js
ExtJS
Meteor前端层
jQuery + SPA框架们
Mithril, Riot, Preact...
前端生态系统
在10年内涌现了100多种技术，98%都消失了。
React之所以幸存下来，原因很大：
结构相对好
相对易于维护
得到了企业的采纳
但是这也意味着React终将消失。
因为前端技术的本质始终如一。
2. React变得越来越庞大和复杂（现实）
最初的React非常简单。
“UI是状态的函数。”
但现在的React呢？
React
ReactDOM
JSX
Babel
Webpack
Vite
Next.js
Zustand
Redux
Suspense
Server Components
hydration
client/server boundary
streaming
routing
bundler
基于编译器的渲染...
所有这些
在React生态系统中已成为“必要讨论”。
React不再是一个简单的库。
React已经成为一个复杂的世界，每年变得更加复杂。
这样一来会出现什么问题？
新开发者的准入门槛上升
如果整个团队不是React专家，则维护难度急剧上升
项目初始速度大幅减慢
服务器简单，但前端却成为核心复杂性的根源
然后就会出现这个问题。
“我的服务真的需要React吗？”
3. 大多数SaaS、Web服务不需要React
需要React的情况主要有两种：
实时UI不断变化的复杂SPA
(例如：Figma, Slack(Web), Notion, Trello等)需要大规模前端组织+多团队协作的超大型项目
但Rails开发者创建的服务呢？
CRUD服务
仪表板
博客
社区
数据搜索为中心的服务
表单为中心的服务
客户管理
内部工具
SaaS
电子商务后台
这些服务
根本不需要React的一半功能。
而且使用React反而会导致
开发速度变慢
复杂性急剧增加。
4. 在这种背景下诞生的技术就是Hotwire
Hotwire是Rails团队提出的技术栈，
以这种理念为核心。
“前端的80%无需像React那样复杂。”
Hotwire的构成非常简单：
Turbo (HTML流式传输 + 部分更新)
Stimulus (小型JavaScript引擎)
Cable + Streams (实时)
但关键在于这一点。
直接更新HTML本身是大多数Web服务中最快、最简单、最易于维护的方法。
不像React那样
状态 → 差异 → 渲染 → hydration...
没有这样复杂的过程。
Hotwire完全遵循Rails的理念：
简单性
生产力
迭代速度
可维护性
代码量少
开发者快乐
而且令人惊讶的事实：
实际上，与React相比，速度快3倍，
代码量只有1/5，
bug大幅减少。
5. 不需要使用React的原因 — Hotwire已经解决了
在React试图解决的10个问题中，
Hotwire通过服务器中心方法解决了7~8个问题。
例如：
| 问题 | React方式 | Hotwire方式 |
|---|---|---|
| UI更新 | 差异计算 → 渲染 | 服务器直接发送HTML片段 |
| 状态管理 | Redux/Zustand | 服务器状态 = UI状态 |
| 路由 | 前端路由器 | Turbo优化页面导航 |
| 实时 | WebSocket + 客户端渲染 | Turbo Stream直接更新HTML |
| SEO | 单独设置 | 100%服务器渲染 |
| 构建 | Babel/Webpack/Vite | 无（无需构建！） |
| 复杂性 | 复杂 | 低 |
Hotwire极大地提高了Rails开发者的生产力。
6. 那么React会怎样？它终将消失。几乎可以确定。
因为前端的历史一再重演。
- 最初是简单的UI库
→ 逐渐变得庞大
→ 变得复杂
→ 组织无法维持
→ 其他技术出现
→ 一代交替
React也在走这条路。
实际上，迹象已经显现。
React Server Components过于复杂，开发者反感
性能问题
Next.js主导React规则（React本体不再独立）
竞争对手（Solid, Qwik, Svelte, HTMX等）出现
“无需构建 + 服务器中心Web”趋势再次兴起
现在开发者们反而说：
“现在的Web太复杂了。我们需要简单性。”
这种趋势在历史上一直是正确的。
主机 → PC（简单性回归）
SOAP → REST（简单性回归）
jQuery时代的混乱 → React（简单性回归）
复杂的SPA → Hotwire/HTMX（简单性回归）
React最终会消失。只是一个“何时”的问题。
结论 — 我们选择的不是技术，而是方向
这并不是说不要学习React。
当需要React时，一定要使用。
但大多数服务不需要React。使用复杂技术会导致速度变慢，维护困难。
Rails + Hotwire这样说：
“Web本来就应该简单。
服务器提供HTML，浏览器展示即可。
只有在必要时才添加少量复杂性。”
这种理念
完全符合AI时代的开发方式。
对于初学者来说，使用Hotwire的理由尤为强大。
快速
简单
清晰
bug少
服务器状态 = UI状态
无需构建系统
易于维护
最适合个人开发者
最重要的是：
与React相比，Hotwire将是一种更持久的技术。Rails的理念已经坚持了20年，未来也不会改变。