2025年のReactとコミュニティの現状

 (blog.isquaredsoftware.com)
26 ポイント 投稿者 GN⁺ 2025-06-16 | 16件のコメント | WhatsAppで共有
  • Reactは依然として最も広く使われているUIフレームワークだが、ここ数年でコミュニティ内の混乱・論争・不信感が増大しており、公式チームと外部開発者のコミュニケーション不足や不適切なマーケティングが重なって懸念が増幅している
  • React 19が正式リリースされ、Server Components、新しい use フック、フォーム統合など大規模な機能が追加されたが、「フレームワークのみ推奨」方針とNext.js中心の構図が多くの利用者の不満を招いている
  • 「ReactはもうNext.jsでしかまともに使えない」「まもなくクライアント専用サポートが打ち切られる」といった誤解やFUDが広まったが、実際にはクライアントレンダリング機能がなくなることは決してなく、RSC・サーバー機能もあくまで選択肢にすぎない
  • Reactチームのフレームワーク中心方針は、性能・構造の標準化とユーザー体験改善が目的だが、SPAや多様なアーキテクチャへの敬意の不足、非公式的で不親切なドキュメントがコミュニティの混乱を深めている
  • 最近になってようやくVite・ParcelベースのSPAなど多様な方法が公式ドキュメントに含まれるようになったが、サーバーコンポーネント（RSC）に関する公式説明の不足とコミュニケーション不全は依然として残っている

序論と目的

  • 2025年時点でReactコミュニティは成功・不信・論争が入り混じる複雑な局面にある
  • この記事の目的は、Reactの発展過程、開発の方向性、主要な決定の背景を整理し、FUDと混乱を解消すること

筆者の背景とコミュニティ参加の経歴

  • Reactチームのメンバーではないが、2015年からReactエコシステムに深く関与
  • Reduxファミリーのライブラリ（特にRedux Toolkit）のメンテナーであり、主要なコミュニティ活動家でもある
  • 数多くのReact/Reduxチュートリアルやブログ、講演、ポッドキャストに参加
  • Reactiflux Discord、/r/reactjs subreddit など主要コミュニティで運営・モデレーター役を担当
  • Reactチームとの協業経験（例: useSyncExternalStore フックのアルファテスター）や、さまざまな内部フィードバックグループへの参加経験がある
  • React DevTools、sourcemaps、Replay DevTools など多様な技術的貢献

  • バイアスと限界に関する断り書き

    • 自分が常に正しいとは限らず、情報の限界・誤解・要約の過程で一部に不正確な説明が含まれる可能性を認める
    • Reduxを保守しており、Reactの利用経験も主に社内ツールやSPA形態に偏っている
    • SSR、RSC、大規模トラフィック、i18n などの実務経験は限られている
    • コミュニティ内部で深く議論された話題には詳しいが、一般的なアプリ開発者の日常とはやや乖離がある
    • Reactチームとの個人的な良い経験・悪い経験の両方が見方に影響している
    • 歴史的・構造的背景の説明では、できる限り誠実に事実を伝えるよう努めている

Reactの簡単な歴史

  • 2011〜2012年にFacebook（現Meta）内部で開発され、2013年にオープンソース化
  • 最近まで、すべての中核開発はFacebook/MetaのReactチームが主導してきた
  • 中核概念（コンポーネント、props、state、data flow）は維持されつつ、実装・API・適用範囲は継続的に拡張・変化してきた
    • createClass → ES6 class → 関数コンポーネント（Hooks対応）
    • React Native によるモバイル、react-reconciler による WebGL（react-three-fiber）、CLI（ink）など多様なプラットフォームへ拡張
    • 内部的には「Fiber」アーキテクチャへ全面リファクタリング（性能・構造の革新）
    • 2018年にHooksを導入し、関数コンポーネントに状態と副作用を付与
  • 「最小UIライブラリ（MVCのV）」戦略により、アーキテクチャ・上位フレームワーク・ビルド・状態管理などはコミュニティに委ねられた
    • その結果、Redux/Mobx/Zustand（状態）、Styled-Components/Emotion/CSS Modules（スタイル）、React Query/Apollo/SWR(RTK Query)（データ）、Webpack/Vite/Parcel など、数多くのサードパーティライブラリやビルドツールが登場した
  • 柔軟性は長所だが、プロジェクトごとに必要なライブラリ選定が必須であり、コードベースの多様化、疲労感、標準不在の問題も伴った

  • ビルドツールとCRA

    • 初期は Webpack/Babel などの複雑な設定が必須だった
    • Create React App(CRA): Webpack+Babel ベースのCLIで、複雑さを隠し、単一コマンドでプロジェクトを作成できた（ブラックボックス方式）
    • データフェッチや状態管理は別の3rd-partyツールに依存した
    • SSR（サーバーサイドレンダリング）機能は初期から存在したが、手動実装が必要だった
    • その後、**Next.js（SSR/ファイルシステムベースのルーティング、データフェッチ）、Gatsby（静的サイト、GraphQL）、Remix（サーバーデータローダー）**などのフレームワークが登場

  • React Server Components(RSC) とフレームワークへの転換

    • 2020年末にReact Server Components(RSC) のプロトタイプが公開され、非同期コンポーネントやサーバーデータフェッチをReactで標準化しようとするアーキテクチャ上の変化が起きた
    • 開発過程で一部のReactチームがVercelへ移籍し、Next.jsと協力して App Router と RSC の最初の実装を進めた
    • 2020〜2023年に React 公式ドキュメント（react.dev）が全面改訂され、対話型チュートリアルやAPIリファレンスが強化された

  • 公式推奨の使い方の変化

    • 以前の公式ドキュメントでは、CRAベースのSPA開始を推奨し、SSR/静的サイトが必要な場合は Next/Gatsby などの代替を案内していた
    • 新しいドキュメント（react.dev）ではフレームワーク利用を強く推奨し（ルーティング、データフェッチ、ビルド統合）、RSC実装としては Next.js のみを言及していた
    • CRA は 2022年ごろから事実上メンテナンス停止状態となり（公式に deprecated ではなかったが、コミュニティでは徐々に置き換えられた）
    • 公式ドキュメントやコミュニティ内でも「Next.jsこそ本当のReact 18」という意見が出るなど、Next.jsとの強い結びつきが強調された

Reactと所有企業（スポンサー）の関係

  • Meta(Facebook)

    • Reactは当初からFacebook/Metaが所有・主導してきたプロジェクト
    • オープンソースではあるが、実質的な開発はMetaのReactチームが担い、中核会議やロードマップもすべて社内中心だった
    • 新機能はMeta内部の複数のアプリチームで実際に検証・テストされた後に外部公開される
    • Reactチームは開発の自由度が高く、ロードマップとビジョン策定を主導的に進めてきた
    • 成果やプロジェクトがMetaの事業にどう貢献するかは社内で検証が必要
    • Metaは独自のサーバーインフラや GraphQL、Relay など自社技術を積極活用しており、ルーティングや状態管理でもコミュニティとは異なる形でReactを使っている
    • そのため Meta 社内では外部3rd-partyライブラリの活用頻度は低い

  • Vercel、Next.js、React

    • VercelはWebアプリホスティングプラットフォームであり、Next.jsフレームワークの開発元
    • ビジネスモデルは、Next などのフレームワーク普及 → Vercelプラットフォームへのホスティング誘導
    • CEO（Guillermo Rauch）は初期からReactのレンダリング思想に深い信頼と投資を行ってきた
    • 2021年、Reactチームリーダー Sebastian Markbage が Meta から Vercel へ移籍し、Andrew Clark・Tom Occhino など主要人材も加わった
    • Vercelへ移ったメンバーはReact Server Components(RSC) や Next.js App Router などの中核機能を React と Next.js の両方で実装した
    • Vercel所属エンジニアも React コアやサーバーレンダリング機能へ実質的に貢献している
    • 2025年現在、Reactチームは Meta と Vercel に分かれて活動しており（主力はMeta、主要コア実装にはVercelも関与）、外部貢献者も一部いる

Reactの利用パターン

  • 標準アーキテクチャ

    • React自体はSPA、SSR、SSG、ハイブリッドなど多様な方式をすべてサポートしている
      • SPA: 空のHTMLにReactツリー全体をクライアントでレンダリング
      • SSR: サーバーでリクエストごとに動的HTMLを生成
      • SSG: ビルド時に静的HTMLを事前生成
      • Python/Django、Ruby/Rails、PHP/WordPress など複数の言語やフレームワークと組み合わせ可能
    • 2015年ごろからSPA（クライアントレンダリング）方式が標準だったが、初期表示速度・JSバンドルサイズ・ネイティブブラウザ動作との差異などのトレードオフがあった
    • データフェッチはもともと Redux などで直接ロジック実装していたが、その後 React Query/Apollo/SWR/RTK Query など専用フック/ライブラリの登場で簡素化された
    • Next.js、Remix などのフレームワークはSSR、SSG、ファイルシステムルーティングを標準化し、データフェッチ構造を整理することでReactの活用範囲を広げた
    • SSRベースのアーキテクチャ（サーバーレンダリング、プリフェッチ、コード分割など）へ移行するトレンドがある
    • Reactチームは「データフェッチの waterfall」現象を避け、ルート単位の事前フェッチなど性能改善パターンを推奨している

  • ビルドツールとフレームワークの利用状況

    • 主なツール/フレームワーク:
      • Next.js(SSR/SSG/RSC/SPA)
      • Remix / React-Router v7(SSR/SSG/SPA)
      • Vite(SPA、ビルドツール、多様なフレームワークプラグイン対応)
      • Create React App(SPA)
    • ViteはVueエコシステム発だが、React、Svelte など多数をサポート → React公式プラグイン、フレームワークのビルドツール標準
    • Remix/React-Router も最近は Vite ベースの SSR/SSG 対応構造へ移行している
    • ダウンロード統計の要約:
      • Next.js の利用率が圧倒的1位
      • Vite の React プラグインが急成長し、2番目によく使われている
      • CRA（react-scripts）は2023年以降下降傾向だが、依然として相当な利用量がある
      • Remix は口コミでの評価は高いが全体規模は限定的、React Router は framework mode への移行が遅い
      • Gatsby は Next/Vite/CRA よりかなり少なく、最近では Astro（マルチフレームワーク静的サイト）にも逆転されている
      • Astro は React 特化ではないが Remix と近い規模
      • Vite+CRA の利用量を合計すると Next と肩を並べる → SPA方式への需要も依然として高い

React Server Components(RSC) の内部とフレームワークとの関係

  • RSC開発の背景とVercelとの協力

    • Meta社内インフラにはすでに独自のサーバー構造が構築されており、RSC(React Server Components) の開発・テストには限界があった
    • RSCはReactチームが直接主導した未来志向の設計であり、MetaやVercelの指示や要求ではなく、Reactチームの独立したビジョンから始まった
    • ReactチームがVercelにRSCビジョンを提案し、Vercelが開発の実験場・支援者として加わった
    • Sebastian Markbage、Andrew Clark などReactコアメンバーが Meta → Vercel へ移り、Next.jsチームが App Router（最初の実用的RSC適用事例）を構築した
    • この過程でNext.jsはほぼゼロから再設計・再実装された
    • Shopify(Hydrogen)、Remix など他フレームワークにも初期テスト・協力の試みはあったが、本格参加は限定的だった
    • 結果として、Next.js App Router だけが実際の「本番級」RSC実装として定着し、他フレームワーク（React Router、Parcel、Waku など）は現在統合作業中だが、一般利用では Next が独占している

  • RSCとフレームワーク/バンドラーの統合構造

    • 「RSCはなぜフレームワークやバンドラーが必須なのか？」という疑問は多い
    • 従来のSSR（renderToString, renderToPipeableStream）はどこでも実行可能だったが、RSCは構造的にはるかに複雑
      • コード内の 'use client', 'use server' ディレクティブの解釈
      • クライアント/サーバーコンポーネントの分離と登録の自動化が必要
      • モジュールグラフ全体を解析・コンパイルするバンドラー（例: Webpack、Vite など）との緊密な統合が必須
    • ReactコアはRSCの中核ロジックとデータシリアライズAPIのみを提供し、実際の動作やルーティング、エンドポイント呼び出しなどはフレームワークが担う
    • 各フレームワークごとにRSCの活用法・アーキテクチャ・実装方式は異なる
      • Next.js App Router はレイアウト・ルーティングなど独自ルールを適用
      • Parcel、Waku、React Router などはそれぞれ異なる設計を導入中
    • 要するに:
      • RSCはReactコアに組み込まれたハイブリッド機能だが、実用には必ずバンドラー/フレームワークとの統合が必要
      • フレームワークが対応して初めてRSCの強みを実際に活用できる

コミュニティの懸念と混乱

  • 1. 「VercelがReactを支配した」という懸念

    • Vercelが主要なReactチームメンバーを雇用し、Next.jsがドキュメントや例で強調されたため、「VercelがReact開発を主導している」という疑念が広がった
    • 実際にはReactチームがRSCのビジョンとNext App Routerの構造を主導しており、Vercelは支援者・実験場の役割だった
    • VercelがReactを「支配」したというより、Reactコアチームの一部がVercelへ移籍してビジョンを実現した構図である

  • 2. 「ReactはもうNextでしか動かない」という誤解

    • Next.js だけが唯一の本番向けRSC実装として強調されたことで、この誤解が生まれた
    • React公式ドキュメントには Next 以外にも多様なフレームワークや、フレームワークなしでの使い方も記載されている
    • NextはReactベースのフレームワークにすぎず、React単体や他ツールでも引き続き利用可能

  • 3. 「クライアントアプリからReactが消えるかもしれない」という不安

    • サーバー機能（RSC、SSRなど）の強調によって、SPAクライアント対応が打ち切られるのではという懸念がある
    • Reactのクライアントレンダリング機能は決してなくならない
      • Metaなどの大規模コードベースでもクライアント方式は大量に使われている
      • Reactチームは互換性と移行支援に非常に慎重である

  • 4. 「なぜReactはフレームワーク利用を強いるのか？」

    • Reactチームはデータフェッチ・ルーティング・SSR統合などにおけるフレームワークの生産性・性能上の利点を理由に基本推奨としている
    • 「手動設定（カスタムSPA）は長期的に非効率で、フレームワークが業界標準」という立場
    • 実際には多様な利用パターンがあるのに、推奨があまりに一律になっている
      • 初学者の参入障壁、サーバーホスティングに制約のある企業、SPAホスティングの単純さなど、現実的な理由でSPAも依然として有効
    • 公式ドキュメントの「非フレームワーク方式」案内が副次的に扱われ、コミュニティに疎外感を与えた

  • 5. 公式ドキュメントの限界と改善を巡る議論

    • CRA（react-scripts）は公式に deprecated となり、代替ツール（Vite など）への言及が遅れたことで混乱が増した
    • SPAなどの「非フレームワーク」方式も公式に認められ、ガイドが追加された（2025年最新ドキュメント）
    • Vite など主要ビルドツールへの公式言及が遅かった点について、コミュニティやエコシステムの人物（Evan You など）も問題提起した
    • 改善された最新ドキュメントでは SPA、Vite/Parcel/RSPack なども推奨され、ルーターやデータフェッチの選択ガイドも提供されている

  • 6. RSCの公式ドキュメントと説明不足

    • Next.js、Vercel など外部資料に比べ、React公式ドキュメント内でのRSC説明や概念案内が不足している
    • API Reference に断片的な情報があるだけで、全体的な概念や適用ガイドが不十分
    • コミュニティや主要人物（Dan Abramov など）が積極的に補足説明をしているが、公式化不足が継続的な混乱を招いている
    • RSCのコンセプト、アーキテクチャ、導入事例、FAQ などのドキュメントセクション追加が必要と指摘されている

主な懸念点の整理

  • フレームワーク・サーバー機能の強調が「Vercelの利益のため」という誤解はコミュニティに根付いたが、実際には事実ではない
    • Reactチームのコミュニケーションや公式ドキュメントの表現が誤解を広げた面はある
  • Reactのクライアントレンダリング機能は今後も維持され、サーバー機能（RSC/SSRなど）はオプションにすぎず、SPAなど従来方式も引き続き利用可能
  • コミュニティの懸念と混乱には、Reactチームのコミュニケーション不足、DevRel活動の不十分さも一因としてある
    • 公式見解の表明、誤解の解消、多様なパターンの承認と案内が必要
  • 「フレームワーク利用」推奨は善意から出発したが、実際にはあまりに画一的に感じられ、多様な利用パターンを疎外したという批判がある
  • 2025年以降、公式ドキュメントは改善され、SPA/カスタムビルド方式も認められガイドが追加されたが、コミュニティのフィードバック反映には長い時間を要した
  • RSC(React Server Components) の概念、トレードオフなど中核内容の公式ドキュメント補強が必要
    • コミュニティの正しい理解と不要な論争の防止に役立つ

結び

  • 本文は、Reactがどのように発展してきたか、どのような影響や目標のもとで開発されているか、そして現在のエコシステムで利用パターンがどう定着しているかについてのさまざまな問いに答えている
  • Reactチームの方向性や変化に対して生じた混乱やFUD（恐怖・不確実性・疑念）を解消しようとした
    • 技術的方向性に同意しなかったり、RSCや大規模フレームワークをあえて使う必要を感じなかったとしても、Reactチームの意図と方向性には十分な妥当性がある
  • Reactチームの方針は性能標準化とコミュニティのUX改善という善意に由来しているが、不親切なコミュニケーションとドキュメントが不要な混乱を拡大させた
  • SPA、フレームワーク、多様なビルドツールなど実際の利用パターンの多様性への敬意と、公式ドキュメント改善の必要性が高まっている
  • 今後はコミュニティのフィードバック反映、多様なアーキテクチャを包摂するドキュメント改善、オープンなコミュニケーションがReactの健全な発展にとって重要になる

関連記事

16件のコメント

 
ahwjdekf 2025-06-19

React はどこかネジの外れた未完成ライブラリのように感じる……。たとえば useEffect の公式ドキュメントにずらずら書かれている内容を見ると……ただただ呆れるばかり……。こんなに多くのウサギ穴をあちこちに作っておいて、うまく使えという態度は何なんだろう……。あまり深く考えず、その場しのぎで対処しているように感じることが多い。
 
ahwjdekf 2025-10-23

AWS の事故が起きるのを見ながら、やっぱり……そんなことを思いました。
 
geek12356 2025-06-18

改善案を示せなければ、お前はジュニアだ
 
woonki 2025-06-17

React Native も似たような雰囲気。React にとっての Next.js が、React Native にとっては Expo。公式ドキュメントでも Expo フレームワークの利用が推奨されており、従来の CLI 方式は今では見つけにくくなっている。
 
preserde 2025-06-16

実際、ここではWebフロントエンド開発の話題はかなり少ないのですが……それでも最近 nextjs への言及があまりにも多いのは、ただ事ではないように感じます。
Server component だけが問題で、ほかは大丈夫〜という雰囲気ですね。
 
ahwjdekf 2025-06-16

JS/FE界隈はいったんエコシステムをきれいに滅ぼして、もう一度リセットしてほしい。ついでに状態管理みたいなものも全部含めたフレームワークを作ってほしい。選択肢が多すぎる？ それは自由じゃなくて、ただの無責任でしかない。
 
passerby 2025-06-16

フレームワークが便利だということと、React自体がCRAを放棄するのは、まったく次元の違う問題のように思います。変わったReactのドキュメントでいきなりNextを入れろと言われて、ちょっと違和感を感じたんですが、そう感じたのは私だけではなかったんですね。
 
dohyun682 2025-06-16

VercelとReact開発チームは別組織だと思っていましたが、実際にはもっと深いつながりがあるのですね
 
quilt8703 2025-06-16

Reactで、UIのインタラクション、内部状態の計算、状態表示くらいだけが必要なゲームのプロトタイピングをしています。数年前に create-react-app が公式ドキュメントから外されるかどうかという頃と比べると、最近は公式ドキュメントを見てセットアップするのが少し難しくなったと感じました。そのときに書いた文章が少し関連していそうです。
 
click 2025-06-16

RSCが最初からNext.jsベースで開発されていたという事実自体は変わらないようですね。
Next.jsがVercel以外の環境ではますます不安定になっていることまで合わせて考えると、
Reactチームの内部でどう考えているのかは分からないにせよ、「RSCが未来です！ でもRSCを動かすにはNext.jsを推奨し、Next.jsはVercelで使ってください」という論理の流れになってしまうので、これがVercelの利益と無関係かと言われると、うーん……
いくら誤解だと主張しても、結局人々は「VercelがReactを侵食した」と感じるしかないですし、その誤解を解くために素早く対応したわけでもないのではないでしょうか？
 
spp00 2025-06-17

今やReactの公式サイトは、Meta側のサーバーではなくVercel上で動いています。
 
moderna 2025-06-16

同意します。
 
click 2025-06-16

同じくVercelが出資しているSvelteは、規模が小さいからなのかは分かりませんが、こういうベンダーロックインがかかるケースはないように感じていたので、その違いも気になります。
 
spp00 2025-06-17

SvelteはVercelが支援しているだけで、Vercelが主導しているわけではありません。対してNextは、Vercelが完全に主導しています。

GitHubリポジトリのようなケースでも、NextはVercel組織の配下ですが、Svelteはそうではありません。

そしてNext.jsは公式サイトのフッターの著作権表記にVercelがありますが、Svelteにはありません。
 
click 2025-06-17

Vercelがリッチ・ハリスを雇ったのは、スポンサー的な性格だったんですね
 
spp00 2025-06-17

https://vercel.com/blog/vercel-welcomes-rich-harris-creator-of-svelte はい、これはスポンサー的な性格が強い雇用です。Svelte の開発にフルタイムで専念できるように給与を支払うということですね。Vercel 側も、Svelte は依然として独立したプロジェクトであることを明確にしています。