Reactはデフォルトとして勝っているが、フロントエンドの革新を遅らせている

• 今日では React の採用は技術的優位ではなくデフォルトとして行われており、これはフロントエンド生態系の革新を鈍らせている
• 多くのチームが制約条件を検討せずに「みんなが知っている React」を選ぶことで、ネットワーク効果が技術的適合性よりもアーキテクチャの意思決定を左右する状況になっている
• Svelte、Solid、Qwik のような革新的なフレームワークは、より優れた性能モデルを提供するが、採用率不足のため主流競争で押し出されている
• React には優れた点が多いが、問題は React をデフォルトとする思考様式が機会費用を増やし、より良い代替案を検討する余地を塞いでいることにある
• 健全な生態系には多様性と競争が必要であり、フレームワークはデフォルトではなく制約と適合性に応じて選ぶべきだというメッセージを伝えている

---

React のデフォルト勝利とその限界

• React はもはや技術的優位で選ばれるのではなく、デフォルトとして採用されることが多い
  • これはチームがプロジェクトの制約を評価せず、自動的に React を使う習慣を強化している
• 代替フレームワーク（Svelte、Solid、Qwik）は、特定のシナリオでは React より性能面で優れているにもかかわらず、十分に評価されていない
• React 自体の問題というより、React をデフォルトとする思考様式が革新を阻害する構造を作っている

革新の天井

• React の Virtual DOM は 2013 年には適切だったが、今日では不要なオーバーヘッドとして作用している
• Hooks はクラスコンポーネントの問題を解決したが、依存配列や stale closure のような新たな複雑さを導入した
• Server Components と React Compiler は性能改善を試みているが、これは React モデルの制約を回避するための便法である
• 一方で Svelte の Runes、Solid の細粒度リアクティビティ、Qwik の Resumability は、まったく異なるモデルでより高い潜在力を示している

技術的負債

• React をデフォルトで選ぶと、不要なランタイムコストと再レンダリング管理の負担が発生する
• 開発者はビジネス価値ではなく、effect の依存関係や hydration 管理に時間を使うことになる
• ベンチマークでは、Solid は React より 2〜3 倍高速な更新性能を示している
• React パターン中心の思考は Web の基礎力を弱め、アーキテクチャの慣性を深める

代替フレームワーク

• Svelte: コンパイラ革命

  • Svelte は作業の大半を コンパイル時に処理し、virtual DOM を取り除く
  • コンポーネントは Web の基本構造に近づき、実行時オーバーヘッドが大幅に減少する
  • しかし「仕事の機会が少ない」という認識のため導入率は低い
  • The Guardian、Wired、Shawn Wang などのさまざまな事例で、Svelte 導入後にバンドルサイズと読み込み時間が大きく減少し、開発生産性が向上したことが証明されている
  • たとえば Shawn Wang は、React では 187KB だったサイトサイズを Svelte で 9KB まで削減した

• Solid: 細粒度リアクティビティの原始的アプローチ

  • Solid は 精密なリアクティビティ（細粒度リアクティビティ） を JSX 構文と組み合わせて提供する
  • signal を通じて変更された DOM にのみ直接アクセスし、reconciliation のボトルネックを完全に回避する
  • 卓越した性能と簡潔な状態管理の強みを持つ
  • まだ採用事例は限られているが、初期導入チームの経験を見ると、効率性・コードの単純さの両面で大きな革新を体験している

• Qwik: Resumability の革新

  • Qwik は traditional hydration の代わりに、resumability により即時の startup を強みとしている
  • 現在必要な機能だけを段階的にロードし、状態・コードの両方をシリアライズ可能にする
  • 大規模サイト、長時間セッション、低速ネットワークで卓越した成果を示す
  • まだ多くのチームは試していないが、導入したチームでは 初期読み込み時間とリソース効率 の両方で大きな改善が報告されている

• React API の複雑さと代替フレームワークの単純さ

  • React API は hook、context、reducer、memoization などの複雑な概念を含んでおり、開発者の認知負荷が高い
  • 誤用すると依存関係の問題によるバグ発生や過剰な設計負担が大きい
  • たとえば、Cloudflare の 2025 年 9 月 12 日の障害原因も、useEffect の依存配列設定ミスによって発生した
  • 一方で、Svelte・Solid・Qwik などの代替案は、はるかに小さく集中した API によって シンプルさと Web の根本原理を強調している
  • この 3 つのフレームワークはいずれも技術的優位性を十分に備えているが、React というデフォルト文化のために、ほとんど実験すらされないのが現実である

ネットワーク効果の牢獄

• React 支配は自己強化的な障壁を生み出している
• 求人市場では「React 開発者」ばかりが求められ、組織ごとに コンポーネントライブラリや開発習慣などが React 向けに固定化される
• リスク回避志向のリーダーは当然のように安全な React を選び、教育機関もそれに合わせる
• こうした構造は 健全な競争が失われた生態系の特徴である

ネットワーク効果を破る

• そこから脱するには 意識的な選択が必要だ
• 技術リーダーは惰性を捨て、要件に応じて構造を決めるべきであり、企業はパイロット予算を割り当てて代替案を試すことができる
• 開発者も単一のパラダイムに固執せず、さまざまなフレームワークの思想を身につける必要がある
• 教育機関は フレームワーク非依存の概念に関する授業を増やすべきであり、オープンソース貢献者は小さな生態系の支援に力を注げる
  変化は自然には訪れず、意図的に作り出さなければならない。

フレームワーク評価チェックリスト

新規プロジェクトでは、次を評価基準にできる

• 性能要件: 初期読み込み、更新効率、バンドルサイズなどと、コンパイル時最適化の有無
• チーム能力と学習曲線: 既存経験を考慮し、Solid のように React と親和性のある代替案も存在する
• 拡張性と保有コスト: 保守、依存関係管理、技術的負債を含む長期コストを評価する
• 生態系適合性: 成熟度と革新性のバランス、非中核業務でのパイロット導入や ROI テスト

よくある反論と対応

• 生態系の成熟度: 古い生態系が必然的に今日の問題により適しているとは限らない。サードパーティパッケージへの依存度が高まると、保守負担、セキュリティ脆弱性、バンドル肥大化などの副作用が大きい。むしろ小さな生態系は Web の根本により集中でき、AI ツールの発展によって容易かつ迅速にカスタムソリューションを開発できる。
• 採用問題: 需要がそのまま採用基準になる。中核でない領域で代替案を試した後、現場学習で不足する能力を補える。
• コンポーネントライブラリ: フレームワーク非依存のデザインシステムや Web Components の活用により、ロックインを減らしつつ生産性を維持できる。
• 安定性: React も hooks、Server Components など絶えず変化している。代替フレームワークのほうが、より一貫した API を提供する場合も多い。
• 大規模事例による検証の必要性: かつて jQuery も世界的な事例だった。過去の成功が未来にも有効だという保証はない。

生態系・産業全体に及ぶ害

• React の単一文化は Web の発展そのものを遅くする
• 才能と資本が React の課題解決にばかり集中し、プラットフォーム固有の革新は遅延する
• 教育機関も 即時の就業可能性重視のカリキュラムにより、移植性のない技術学習ばかりを増やしてしまう
• プラットフォーム（Web）自体の発展が「React さえあればよい」という答えに阻まれ、生態系の多様性不足が長期的には全員に損失として返ってくる

私たちが作れる望ましい生態系

• 多様性は健全な生態系の必須条件である
• 複数のパラダイムが競争し交流するとき、革新が生まれる
• 開発者は複数の思考様式を学びながら成長し、Web プラットフォーム自体も多様な挑戦意識のおかげで発展する

• 1 つのフレームワークにオールインすることは単一障害点になる。限界に達すれば成長は止まり、より良い機会も失われる
• プロジェクトごとに技術的制約と適合性を中心に選ぶべきであり、React のデフォルトにだけ依存しない姿勢が必要だ
• 多様性だけが真の革新を保証する

• 今こそ、みんなが同じ「種（React）」ばかりを植えるのではなく、より多様なフレームワーク実験を通じて Web 生態系をもっと強靭で革新的なものにしていく時だ
• 選択は私たちの手にある