■ 1. Reactの歴史とエコシステムの変遷
- Reactの初期: 2013年にオープンソース化され、当初はUIに特化した最小限のライブラリ（「MVCのV」）と位置付けられた。
- エコシステムの爆発: Reactチームが「unopinionated（意見を持たない）」な姿勢を貫いた結果、状態管理、データフェッチ、ビルドツールなど、様々な分野で多様なライブラリが乱立した。この柔軟性は、同時に開発者の「決定疲れ」やプロジェクトの「コードベースのばらつき」を招いた。
- Create React App（CRA）の登場: この課題を解決するため、Reactチームはビルド設定をカプセル化したCLIツール「CRA」を開発し、プロジェクト開始の複雑さを軽減した。
- React Server Components (RSC) のプロトタイプ発表: 2020年後半、Reactチームはサーバー上でデータをフェッチし、コンポーネントをレンダリングするRSCのプロトタイプを発表した。これは、Reactの「クライアント上のビューだけ」という従来の立ち位置からの大きな転換となった。
■ 2. コミュニティの懸念と実態
- 懸念：VercelによるReactの乗っ取り: Reactチームの一部メンバーがNext.jsを開発するVercelに移籍し、RSCの実装をNext.js App Routerで進めたことから、「VercelがReactを乗っ取り、自社サービスにユーザーを誘導している」という見方が広まった。
- 実態: この見方は因果関係が逆であり、ほとんどがFUD（恐怖、不確実性、疑念）である。RSCはReactチームのビジョンであり、Metaのインフラではテストが困難だったため、Vercelがそのビジョンに賛同し、Next.jsを再設計して実装の場を提供した経緯がある。
- 懸念：ReactはNextでしか動かない: ReactのドキュメントがNext.jsを強く推奨したことから、「Reactは今やNextでしか使えない」という誤解が生まれた。
- 実態: これは完全な誤解である。Reactは依然として様々なフレームワークや純粋なSPAでも動作する。この混乱は、React、Next、フレームワーク間の境界線が不明瞭になったことに起因する。
- 懸念：Reactのクライアント機能がなくなる: サーバーサイド機能への注力が強まったため、「将来クライアントサイドの機能がなくなるのではないか」という不安が広がった。
- 実態: この懸念はあり得ない。Meta自身が膨大なクライアントサイドReactコードを保有しているため、クライアントレンダリング機能がなくなることはない。RSCなどのサーバー機能は付加的であり、オプションである。
■ 3. Reactチームのフレームワーク推奨の意図と課題
- 推奨の理由:
- フレームワークは、ルーティングやデータフェッチなど、多くの共通課題に対する統合されたソリューションを「箱から出してすぐに」提供する。
- これにより、開発者が独自のセットアップを構築する手間を省き、デフォルトでより良いパフォーマンスを実現できる。
- RSCの機能を正しく動作させるには、フレームワークとの密接な統合が必要である。
- ドキュメントの課題:
- ニュアンスの欠如: フレームワーク推奨が「フレームワークを使わないのは間違いだ」という過度に広範な処方箋となり、SPAのような一般的なユースケースを「珍しい制約」と表現した。
- コミュニティの軽視: 「私たちはあなたを止めることはできません」といった表現が、SPAユーザーを軽視していると受け止められた。
- 情報不足: RSCの重要な機能がReactに組み込まれたにもかかわらず、公式ドキュメントにRSCに関する情報が不足し、Next.jsのドキュメントに頼るしかなかった。この情報不足が混乱を助長した。
■ 4. 教訓と今後の展望
- 不信感の原因: Reactチームの行動と発言は善意から出たものであったが、コミュニケーション不足とドキュメントの問題が、コミュニティに不信感を与え、FUDを強化してしまった。
- 今後の課題:
- コミュニケーションの改善: Reactチームはコミュニティの懸念を読み取り、存在を認め、明確に答える姿勢を強化する必要がある。
- ドキュメントの改善: SPAのような一般的なユースケースを適切に評価し、RSCのコンセプトや使い方を包括的に説明する公式ドキュメントを充実させるべきである。
- 結論: 広く使われるライブラリの維持と多様なニーズへの対応は非常に難しい。Reactチームは全体として良い仕事をしているが、コミュニケーションとドキュメントの不足が多くの不満を生んでいる。