なぜ皆がReactを使うのに、私たちは使わなくてもいいのか？- フロントエンドの戦争の歴史とHotwireの誕生理由
最近のウェブ開発の話を聞くと
いつも同じ言葉が出る。
「フロントはReactでやらないと。」
「最近は全部Reactを使う。」
「Reactを学ばないと開発者になれない。」
しかし、本当でしょうか？
いいえ、正確に言うと半分だけ正しい言葉です。
Reactがいいライブラリであるのは事実です。
しかし問題は…
Reactが「必要な状況」は本当に全ウェブサービスの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は状態(state)の関数だ。」
しかし現在のReactはどうなっているでしょうか？
React
ReactDOM
JSX
Babel
Webpack
Vite
Next.js
Zustand
Redux
Suspense
Server Components
hydration
client/server boundary
streaming
routing
bundler
compilerベースのレンダリング…
これらすべてが
Reactエコシステム内で「必須の議論」になってしまいました。
Reactはもはや単純なライブラリではありません。
Reactは独自の複雑な世界になり、年々難しくなっています。
こうなるとどんな問題が生じるでしょうか？
新人開発者の参入障壁が急増する
チーム全体がReactの専門家でないとメンテナンスが難しくなる
プロジェクトの初期速度が極端に遅くなる
サーバーは単純なのにフロントが核心的複雑さの原因になる
そしてこの質問が続きます。
「私のサービスは本当にReactが必要か？」
#3. ほとんどのSaaS、ウェブサービスにはReactは必要ありません
Reactが必要な状況は主に2つあります:
リアルタイムでUIが継続的に変化する複雑なSPA
(例: Figma, Slack(Web), Notion, Trelloなど)大規模フロントエンド組織 + マルチチーム協力が必要な超大規模プロジェクト
しかしRails開発者が作るサービスはどうでしょうか？
CRUDサービス
ダッシュボード
ブログ
コミュニティ
データ検索中心サービス
フォーム中心サービス
顧客管理
内部ツール
SaaS
ECバックオフィス
このようなサービスは
Reactの半分の機能さえ必要ありません。
そしてReactを使うと
開発スピードはむしろ遅くなり
複雑さが急激に増します。
#4. この背景から生まれた技術がHotwireです
HotwireはRailsチームが提案した技術スタックであり
この哲学を中心にしています。
「フロントエンドの80％はReactのように複雑である必要はない。」
Hotwireの構成はシンプルです:
Turbo (HTMLストリーミング + 部分更新)
Stimulus (小さなJavaScriptエンジン)
Cable + Streams (リアルタイム)
しかし核心はこれです。
HTMLそのものを更新する方法がほとんどのウェブサービスで最も速く、最も簡単で、最もメンテナンス可能である。
Reactのように
状態 → 差分 → レンダリング → hydration…
このような複雑なプロセスはありません。
HotwireはRailsの哲学をそのまま受け継いでいます:
単純さ
生産性
繰り返し速度
メンテナンス性
コードの少なさ
開発者の幸福
そして驚くべき現実:
実際に作ってみるとReactよりも3倍速く、
コード量は1/5程度であり、
バグは劇的に減少します。
#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など)が登場
「ビルドなし + サーバー中心ウェブ」の流れが再浮上
現在むしろ開発者たちは言います:
「最近のウェブはあまりにも複雑になった。再び単純さが必要だ。」
この流れは歴史的に常に正しかったです。
メインフレーム → PC(単純性回帰)
SOAP → REST(単純性回帰)
jQuery時代の難局 → React(単純性回帰)
複雑化したSPA → Hotwire/HTMX(単純性回帰)
Reactは最終的に消える。ただ「いつか」の問題だけです。
#結論 — 私たちは技術を選ぶのではなく、方向を選ぶのです
Reactを学ばないと言うのではありません。
Reactが必要な時は必ず使えばいいです。
しかしほとんどのサービスにはReactは必要ありません。複雑な技術を使う瞬間に速度が遅くなり、メンテナンスが難しくなります。
Rails + Hotwireはこう言います:
「ウェブは本来単純でなければならない。
サーバーがHTMLを提供し、ブラウザが表示すればいい。
すべての複雑さは必要な時だけ少しずつ重ねればいい。」
この哲学は
AI時代の開発方法とも完璧に一致します。
初心者なら特にHotwireを使う理由が強力です。
速いです
簡単です
明確です
バグが少ない
サーバー状態 = UI状態
ビルドシステムがありません
メンテナンスが簡単です
1人開発者に最適
そして最も重要な言葉:
HotwireはReactよりもはるかに長く続く技術です。Railsの哲学は20年を乗り越え、これからも変わらないでしょう。