Reactがこれまでどのように開発されてきたかについての詳細な考察と、コミュニティでよく見られる混乱や懸念事項についての説明

はじめに

今日、Reactとそのエコシステムの状況は複雑で分裂しており、成功、懐疑、そして論争が入り混じっています。

ポジティブな面として、Reactは最も広く利用されているUIフレームワークであり、そのコンセプトはJSエコシステムの他の部分にも影響を与えてきました。Reactチームは数年にわたる開発の末、先日React 19をリリースしました。これは、公式に安定版となったReact Server Componentsのサポート、Promiseを扱うための新しいuseフック、複数の新しいフォーム連携、そして長らく非推奨であった多くの時代遅れな機能の削除を含む、大規模なリリースでした。

しかし、私が観察し、また経験してきたところでは、Reactコミュニティでは、Reactの向かう先やその開発方法、推奨される利用アプローチ、そしてReactチームとコミュニティ間の相互作用について、たくさんの意見が交わされています。これは、過去数年間にわたってReactおよびWeb開発コミュニティ全体で飛び交ってきた何十もの異なる議論や、Reactの動作に関する特定の技術的懸念、他の類似JSフレームワークとの比較、そして今後Webアプリをどのように構築すべきかといった問題と重なっています。

事態をさらに悪化させているのは、誰もがこれらの懸念の異なる一部分について議論や討論をしており、表明されている懸念の多くが誤りであるか、完全なFUDであることです。残念ながら、これらの議論と恐怖は、Reactチームと開発者間の適切なコミュニケーションの不足などによって、さらに複雑化しています。これら全てが密接に絡み合っているのです。 不安や懸念、不透明感

私はソーシャルメディア上で関連する多くの議論に参加してきました。Reactチームを擁護し、また批判するコメントを数多く書き、彼らが特定の決定を下した理由や物事の実際の経緯を説明し、ドキュメントや説明の改善を求め、その他多くの活動を行ってきました。 これらのトピックのほんの一部をカバーしようとするだけでも、広範で詳細な記事が必要となります（そして私は、「Reactは悪いのか/Reactは他のツールと比べてどうなのか？」という、さらにスコープ外のトピックには触れるつもりすらありません）。しかし、あまりにも多くの時間を討論と説明に費やしてきた今、これらのトピックの多くをまとめて扱う統合的な記事を書く必要性を感じています。 また、私は過去にこの記事のトピックに基づいた講演も行っています。

この記事の目的

この記事における私の目的は以下の通りです。

• Reactが時間と共にどのように発展してきたかの概要を説明する
• Reactの開発を推進する力を説明する
• Reactの最近の開発の方向性がなぜ、どのようにして起こったのかを明確にし、その作業の背景にあるアーキテクチャ上の決定のいくつかを説明する
• Reactの開発の背後にある動機と意図に関するFUDと混乱を明確にし、払拭する

背景：私のReactコミュニティにおける役割と関与

（もしくは「私は何者で、なぜ私の説明を信頼すべきで、そしてなぜあなたはこの件に関する私の意見を気にかけるべきなのか？ 😄」）

私は実際のReactチームの一員ではありませんし、これまでもそうであったことはありません。とはいえ、私は2015年からReactエコシステムに深く関わっており、MetaやVercelの外部の人間としては、誰よりも「Reactコミュニティのインナーサークル」の一員であると言って差し支えないでしょう。

要約すると、以下の通りです。

• 2015年からReactを使用
• Reduxライブラリファミリーのメンテナーであり、Reactにコントリビュートし、Reactエコシステムの議論に関与
• ReactとReduxに関する多数の詳細なチュートリアルを執筆し、ReactとReduxについて頻繁に講演
• そのほとんどの期間、主要なReactコミュニティセクションのモデレーターとして関与

もし詳細を知りたければ：

これらの実績を挙げたのは、私がReactの開発方法、Reactコミュニティで何が起こっているか、Reactチームの内部で何が起こっているか、そして人々がReactとReduxを学ぶのを助けることに関して、長い歴史と専門知識を持っていることを示すためです。

バイアスと注意点

ここはインターネットなので、私がこれを書くことに対して皆さんが抱くかもしれないいくつかの懸念を先取りしておこうと思います。

私は間違いなく常に正しいわけではありませんし、知識の限界、誤解、あるいは要約のしすぎによって、いくつかの事柄を誤って説明してしまうことは間違いありません。とはいえ、私は歴史、動機、行動をできる限り正直かつ正確に記述するための最善の努力としてこれを書いています。

さらに詳しくは：

さて、これらの注意点を全て述べたところで、本題に入りましょう。

Reactの簡単な歴史

初期の歴史は、Reactドキュメンタリーなど他の場所でより詳しく語られていますが、この記事の残りの部分の文脈を提供するために少し触れておきます。

Reactは2011年から12年頃にFacebook内部で開発され、2013年にオープンソース化されました。外部のコントリビューターも少数集まりましたが、最近まで実際の開発は全てFacebook/Meta内部のReactコアチームによって行われていました。

Reactの核となるコンセプト（コンポーネント、props、state、データフロー）は常に同じですが、実装の詳細、公開API、スコープの広さは時間と共に変化してきました。ReactはcreateClassでコンポーネントを作成する方式から、ES6のclass MyComponent extends React.Componentへ、そしてfunction MyComponent()へと移行しました。ReactはWeb専用からReact Nativeでモバイルをサポートするように分離し、その後、カスタマイズ可能なreact-reconcilerコアを介してWebGL（react-three-fiber）やCLI（ink）など他のプラットフォームにも対応可能になりました。内部は新しい「Fiber」アーキテクチャに完全に書き直され、さらなるアーキテクチャの変更が可能になりました。2018年のフックのリリースにより、関数コンポーネントはstateと副作用を持つ能力を得ました。

長年、ReactはUIに特化した最小限のレンダリングライブラリとして自らを位置づけていました（「MVCのV」、「ユーザーインタフェースを構築するためのJSライブラリ」）。AngularやEmberのような他のフレームワークは完全に「全部入り（batteries included）」で、アプリの構築方法や構造について強い意見を持っていましたが、Reactチームはそれら全てをコミュニティに委ねていました。これは、良くも悪くもエコシステムの大爆発につながりました。考えられるあらゆるライブラリカテゴリで、重複する問題を解決する何十もの競合ツールが存在しました。状態管理（Redux、Mobx、Zustand...）、CSSとスタイル（Styled-Components、Emotion、CSS Modules...）、データフェッチ（React Query、Apollo、SWR、RTK Query...）、ビルドツール（Babel、Webpack、ESBuild、Vite、Parcel...）、その他数百です。

Reactユーザーは常に、プロジェクトを開始する際に、アプリのさまざまなユースケースを解決するための一連のライブラリを選び出す必要がありました。さらに、Reactは多くの方法で使用できました。シングルページアプリ（SPA）でクライアントサイドで全ての要素をレンダリングする、サーバーレンダリングされたページに複数のサブツリーをアタッチする、マルチページアプリ（MPA）の一部としてサーバー上で使用するなど、多岐にわたります。エコシステムのオプションの柔軟性と多様性は、強みであると同時に弱みでもありました。プロジェクトに必要なツールの正確な組み合わせを選ぶことができる一方で、ツールの組み合わせを選ばなければならないのです。それは決定疲れ、プロジェクトのコードベースのばらつき、そして一般的に使用されるツールの絶え間ない変化につながります。

全体として、ReactライブラリとReactチームの両方が意図的に意見を持たない（unopinionated）姿勢を保っていました。彼らはエコシステム内の特定のツールをえこひいきしたくなく、彼らの時間と注意はReact自体の構築に集中しており、Reactのスコープをある程度狭いものと見なしていました。

そのエコシステムの多様性は柔軟性をもたらしましたが、同時に複雑さも生み出しました。これは特にビルドツールで顕著でした。初期のReactチュートリアルでは、最初のReactコンポーネントを書く前に、「WebpackとBabelの設定方法」を説明するために何ページも費やすことがよくありました。このためReactチームは、Create React App（CRA）と呼ばれるパッケージ化済みのビルドツール設定を構築することになりました。CRAは、テンプレートから新しいReactプロジェクトを生成できるCLIツールであり、非常に複雑でカスタマイズされたWebpack + Babel設定で構築されていました。これは、単一のコマンドで新しいプロジェクトを簡単に始められるように設計されていました。その設定は、複雑さを隠すためにブラックボックスとしてカプセル化されていました。

Reactにはデータフェッチの組み込みメソッドがなかったため、データをフェッチしてキャッシュするためにサードパーティのライブラリを使用するのが標準でした。Reactには早くからサーバーレンダリング（SSR）機能があり、ReactコンポーネントツリーをHTML文字列やストリームとしてレンダリングするメソッドがありましたが、これらはサーバーハンドラで手動で使用する必要がありました。時が経つにつれて、他のパッケージ済みのReactビルドシステムや「フレームワーク」が人気を博しました。Next.jsもWebpackをラップしましたが、ファイルシステムベースのルーティング規約による組み込みのサーバーレンダリングやページベースのデータフェッチなど、より多くの機能を追加しました。GatsbyはGraphQLベースのデータソースからサイトを生成しました。後に、Remixはサーバーの「データローダー」を追加し、よりHTML/プラットフォームベースの使用規約を推進しました。

2020年後半、Reactチームは「React Server Components」のプロトタイプを発表しました。これは、非同期Reactコンポーネントがサーバー上で実行されてデータをフェッチし、その後子コンポーネントをレンダリングして子とデータをクライアントで実行されているReactに渡すことを可能にするアーキテクチャ的アプローチでした。これはデータフェッチに対するReactらしい解決策として意図されており、Reactの当初の「クライアント上のビューだけ」という歴史的な売り文句からの大きな転換を示しました。RSCの開発中に、Reactコアチームのメンバーの一部がMetaを去り、Next.jsの開発元であるVercelに参加しました。彼らは初期のRSC実装の構築を続け、Next開発チームと協力して新しい「App Router」でNextを再設計しました。これはRSCの最初の本番実装でした。

Reactチームはまた、2020年から2023年にかけてReactのドキュメントサイトをゼロから完全に書き直しました。react.devにある新しいReactドキュメントには、Reactのコンセプトを段階的に解説する素晴らしいチュートリアルがあり、実行可能なサンドボックス内に多数のページ内サンプルが含まれているほか、APIリファレンスページも大幅に改善されています。

新しいドキュメントが公開されたとき、ReactチームはReactの推奨される使用方法を大きく転換しました。以前は、古いReactドキュメントは、学習中またはクライアントサイドのSPAを構築している場合にはCRAから始めることを推奨し、SSRや静的サイトが必要な場合にはNextやGatsbyのような他のいくつかのフレームワークを指し示していました。新しいドキュメントで、Reactチームはアプローチを変更し、「Reactアプリを書くためにはフレームワークを使うべきだ - それらにはルーティング、データフェッチ、ビルド機能が組み込まれている」と明確かつ強く推奨し始めました。これはRSCを構築する作業にも関連していました。この一環として、「新しいReactプロジェクトを始める」ページでは、フレームワークなしでReactを使用することに対して明確に警告していました。Nextはそのドキュメントページで目立つように記載されていました - 「フレームワーク」リストの最初に（Pagesルーターについて）順序付けられ、さらに下で唯一利用可能なRSC実装として言及されていました。Vercelで働くReactチームのメンバーは、「来るべきNext.jsのリリースを『本当の』React 18のリリースだと考えている」と述べたと引用されています。

これは、Create React Appが2022年頃に事実上非推奨になったことと関連していました。それ以前からしばらくメンテナンスされていませんでした。「CRAを非推奨としてマークし、Viteを推奨する」というPRが提出されたとき、Dan AbramovはCRAが作成された理由、CRAの問題点、フレームワークの台頭、そしてReactのビジョンの転換について詳細なコメントを書きました。これに応えて、Reactコミュニティは一斉にCRAから移行し、ドキュメントもそれを推奨するのをやめましたが、公式に「非推奨」とマークするための措置は何も取られませんでした。

Reactとそのオーナーとの関係

今日、Reactの開発作業は2つの企業によって後援され、所有されています。Meta（旧Facebook）とVercelです。

Facebook / Meta

当初から、ReactはFacebook/Metaが所有するプロジェクトでした。コードはオープンソース化され、誰でもPRを提出できましたが、本質的に開発作業は全てMetaのReactチームによって行われていました。

これはReactの開発方法に大きな影響を与えました。Reactコアチームの会議は通常内部で行われ、ロードマップも同様でした。Reactチームはしばしば問題領域に対して半ダースほどのアイデアをプロトタイプし、それをMetaのアプリチームに試してもらって検証しました。新しいReact機能が発表される頃には、それは多くの内部イテレーションを経て、実際の使用で検証されていました。同時に、ReactチームはMetaのアプリチームのバグ修正やその他のサポートにも責任を負ってきました。

それにもかかわらず、Reactチームはライブラリの開発方法においてかなり自由な裁量を持ってきました。ReactはFacebook内部でFacebookのために作られましたが、Reactチーム自身がライブラリの動作方法に関するロードマップと長期ビジョンを決定してきました。ほとんどの場合、Reactの実際の開発プロセスとロードマップは、Facebook/Meta内部の他の影響力によってではなく、彼ら自身によって推進されてきました。とはいえ、彼らは自分たちの業績とプロジェクトがMetaにどのように利益をもたらすかを正当化する必要もあります。

Meta自身のReactの使用は広範であり、コミュニティの使用方法とは異なります。Metaは独自の巨大なサーバーインフラを持っており、データフェッチ、ルーティング、セキュリティなどのための標準的な技術を含んでいます。MetaはGraphQLプロトコル、およびRelay GraphQLクライアントレイヤーを発明し、それらをReactコードで頻繁に使用しています。これは、MetaのReact使用が、ルーティング、状態管理、スタイリング、またはコミュニティの他の部分で一般的な他の問題に対して、サードパーティのライブラリをほとんど必要としないことを意味します。

Vercel, Next, and React

Vercelは主にWebアプリのホスティングプラットフォームです。彼らは主に、より多くの人々が彼らのプラットフォームでアプリをホストすることで収益を上げ、より簡単に使用できるという利便性をもたらすことで課金を促しています。彼らはNext.jsフレームワークの構築（および他のフレームワークのサポート）に膨大なエンジニアリング時間を費やし、Vercelインフラ上でNextアプリを簡単にセットアップしてデプロイできるようにしています。

VercelのCEOであるGuillermo Rauchは、Reactとその能力の長年の信奉者であり、それは彼の2015年のブログ投稿Pure UIがReactのレンダリングモデルの力について語っていることからも示されています。

2021年後半、ReactチームのリードであったSebastian MarkbageがMetaを去り、Vercelに参加しました。これは、フルタイムのReactコアチームメンバーがMeta以外のどこかで働く初めての事例でした。後に、コアチームメンバーのAndrew Clarkと元React組織リードのTom Occhinoが彼に加わりました。ReactチームはすでにReact内部でRSC機能に関する重要なプロトタイピングを行っており、Next.jsのApp Routerを設計していました。そしてVercelは追加のエンジニアをReactのコアとサーバーレンダリング機能に貢献させ始めました。

今日、ReactチームはMetaとVercelの間で分かれています（大多数はまだMetaにいます）、加えて外部に数人のチームメンバーまたは継続的なコントリビューターがいます。

Reactの利用パターン

標準的なReactのアーキテクチャ

React（特にReactDOM）ライブラリ自体は、ページ内でどのように使用されるかを気にしません。ほぼ空のHTMLプレースホルダーを提供し、クライアントサイドでページ全体のコンテンツを生成するReactツリーをレンダリングして、シングルページアプリ（「SPA」）として機能させることができます。サーバーが各リクエストに動的に応答するサーバーレンダリング（「SSR」）や、ビルド時に静的なHTMLページを事前に生成する静的サイトジェネレーション（「SSG」）にReactを使用することもできます。任意の言語やフレームワーク（Python + Django、Ruby + Rails、PHP + WordPress、.NETなど）を使用して静的またはサーバーレンダリングされたHTMLページを提供し、ページ全体にReactの断片を散りばめてインタラクティビティを追加することもできます。

とはいえ、2015年までにはReactはクライアントサイドのSPAアーキテクチャで最も一般的に使用されるようになっていました。何事にもトレードオフがあるように、これらにも長所と短所がありました。ページコンテンツの生成が容易になり（全てReactコンポーネント）、ユーザーのインタラクションが高速化し（ページ全体のリフレッシュの代わりにクリックやルート変更で別のコンポーネントを表示）、よりリッチなアプリ体験が可能になりました。バックエンドが何であれ（JS、Java、PHP、.NET、Python）、JSON APIを公開してデータをフェッチするだけでした。しかし、最初のページのバンドルをロードするのが遅く、クライアントサイドのルーティングがネイティブのブラウザの動作とは異なる不自然なインタラクションにつながる可能性もありました。

これらのクライアントでのデータフェッチは、当初はかなり手動であり、副作用における慎重なロジックを必要としました（例えば、コンポーネントが最初にレンダリングされたときにデータをリクエストするためにcomponentDidMountでフェッチをトリガーするなど）。これはしばしば、フェッチとキャッシングを処理するためにReduxベースのロジックで行われましたが、そのコードは通常、ボイラープレートと複雑さに満ちていました。後に、React Query、Apollo、SWR、RTK Queryのような専用のデータフェッチライブラリがクライアントでのデータフェッチを大幅に簡素化し、専用のuseQueryフックと事前構築されたキャッシングメカニズムを提供しました。

NextやRemixのようなフレームワークは、Reactをサーバーレンダリングするための標準化されたアプローチを提供し、組み込みのファイルシステムルーティング規約を備えていました。しかし、サーバーベースのデータフェッチに関する規約はありませんでした。Nextは、コンポーネントと並行してフェッチするための非同期関数を指定するgetServerSidePropsメカニズムを発明しました。Remixは後に同様のアーキテクチャで「ローダー」を発明しました。どちらもReactの思想に合っていない感じがしました。

これは、Reactエコシステムにおける一般的な考え方の転換につながりました。ページの読み込み体験を改善し、ページに必要なJSの量を最小限に抑えるために、SSRベースのアーキテクチャへの推進が強まっています。また、クライアントサイドでデータフェッチライブラリを使用する必要性をなくす動きもあります。Reactチームは、ページの読み込みパフォーマンスを改善するためにデータフェッチにおける「ウォーターフォール」に声高に反対しており、React RouterやTanStack Routerのようなクライアントサイドのルーターでさえ、コンポーネントツリーの奥深くでフェッチをトリガーするのではなく、ルート/ページレベルでデータをプリフェッチする方法を提供しています。

Reactビルドツールの利用状況

いくつかの主要なReact関連のビルドツールとフレームワークのダウンロード統計を見て、エコシステムにおける使用規模の経時的な変化と現状を把握する価値があります。 大まかに言うと、今日の主要な選択肢は、マインドシェアおよび／またはダウンロード数の観点から以下の通りです。

• Next.js (SSR / SSG / RSC / SPA)
• Remix / React-Router v7 (SSR / SSG / SPA)
• Vite (SPA)
• Create React App (SPA)

また、Vite自体はVueエコシステムから始まったものの、多くの異なるクライアントサイドフレームワークをサポートする標準化された広く使用されるビルドツールになったことにも注目する価値があります。また、Reactサポート用のプラグインを含むプラグインエコシステムもあり、さまざまなフレームワークのビルドツールとして選ばれるようになっています。これにはRemix / React-Routerも含まれており、最近、内部でESBuildを使用するのをやめ、SSRとSSGのサポートを有効にするためのViteプラグインを提供するように切り替えました。

以下は、過去数年間のこれらのツールのNPMダウンロード数のグラフです。ReactDOMをスケールとして示しています。

最近まで、ReactドキュメントはGatsbyをWeb向けの推奨フレームワークとして、ExpoをReact Native向けの唯一の推奨フレームワークとしてリストアップしていました。GatsbyはNetlifyに買収された後、事実上その役目を終えました。一方、AstroはReactを含む多くのフレームワークをサポートする、より汎用的な静的サイト指向のツールです。比較のために彼らのダウンロード統計を以下に示します。

これらの統計からのいくつかの要点：

• Next.jsが最も広く使用されている

• ViteのReactプラグインは着実に成長しており、現在では2番目に広く使用されている

• React関連のビルドツールである

• CRAの使用は2023年半ばにピークに達し、それ以降減少しているが、依然としてかなりの使用量がある

• Remixは現時点で口コミでの評価は高いものの、規模は比較的小さめです。React Routerは非常に広く使われていますが、「フレームワークモード」に対応した新しいバージョンは、まだそれほど普及していません。

• GatsbyはNext、CRA、Viteほどの勢いはなく、最近Astroに追い越された

• AstroはReact固有ではないが、Remixとほぼ同じダウンロード数がある

• ViteとCRAを合わせるとNextの使用量に匹敵し、Reactエコシステムには依然としてプレーンなSPAプロジェクトに対する強い需要があることを示している

React Server Componentsの内側

React Server Componentの開発とVercel

Reactチームは、Metaのインフラストラクチャからのサーバーベースのデータフェッチや、JSバンドルの自動分割とコードの遅延読み込みの経験がありました。しかし、以前のReactの機能開発とは異なり、Meta内部でRSCをイテレーションして出荷するための選択肢は限られていました。Metaの既存のサーバーインフラと技術は、コミュニティの他の人々が実際に使用して恩恵を受けられるような方法でRSCを完全に設計することを困難にしていました。

注目すべきは、React Server Componentsは、将来Reactアプリを記述する方法に関するReactチームのビジョンであったことです。私の知る限り、これはMetaやVercelが考案したり、Reactチームに構築を強要したりしたものではありません。

長年にわたり、「Reactの開発は全てMetaの従業員によって行われている」という断続的な議論や不満があり、「『React財団』のようなものや、Metaの外部の人々が直接Reactに取り組んでいればいいのに」というコメントが時折ありました。関係する実際の議論は知りませんが、外部からの私の理解では、ReactチームがVercelにアプローチし、RSCのビジョンを提案し、VercelがRSCが開発される新しい実験場となることに同意した、ということです。これにより、Sebastian Markbage（そして後にAndrew Clark）がMetaからVercelに移り、NextチームはRSCの最初の実用的な実装としてNext App Routerを設計・構築するために膨大な時間、資金、エンジニアリングの労力を費やしました。 Dan Abramovが説明したように：

そのプロセスに他のフレームワークや企業を関与させようとする努力はありました。ShopifyのHydrogenフレームワークはRSCの非常に初期のテストとフィードバックを行いましたが、最終的に彼らにとっては合わないと結論付けました。Remixチームは何度か関与を打診されましたが、当初は独自のアプローチに集中することを選択しました。

その結果、Nextは最初の（そして事実上今でも唯一の）「本番環境対応」のRSC実装となりました。今日、他のいくつかのフレームワーク（Parcel、React Router、Wakuを含む）がRSC統合に取り組んでいますが、NextのApp Routerが現在RSCを使用するための唯一の広範な選択肢です。

RSC、フレームワーク、バンドラ

「なぜRSCはバンドラやフレームワークを必要とするのですか？なぜReactに組み込むだけではだめなのですか？」といった質問をよく目にします。

Reactの既存のサーバーレンダリングメソッド、例えばrenderToStringやrenderToPipeableStreamは、Expressのルートハンドラなど、どこでも呼び出すことができました。しかし、アーキテクチャ的にRSCはずっと複雑です。RSCの機能は、'use client'と'use server'ディレクティブを探すためにコードを解析し、そのコードを変換してRSCのコア機能にクライアントコンポーネントとサーバー関数を登録するための適切な呼び出しを挿入する必要があります。これにはバンドラとの緊密な統合が必要で、それによってサーバーとクライアントの両方の全てのモジュールグラフを正しく決定し、適切にコンパイルすることができます。

さらに、Reactコアが実際のRSC機能を実装し、シリアライズされたコンポーネントとデータをクライアントとサーバー間で送信するためのプリミティブを提供しますが、それらのプリミティブを実際に呼び出し、適切な場所で使用するのはフレームワーク次第です。これは主にルーターとの統合に関わることで、クライアントアプリが適切な遅延読み込みされたクライアントコンポーネントを受け取り、アクションとデータを含む適切なエンドポイントを呼び出すようにするためです。

これはまた、各フレームワークのRSCの使用と実装が異なることを意味します。NextはApp Routerでレイアウトとルーティングを処理するために非常に具体的な実装決定を行いました。Waku、Parcel、React Routerのような他のフレームワークやビルドツールは、すでにいくつかの非常に異なる設計決定を行っています。

全体として、RSCは珍しいハイブリッド機能です。主要な機能はReactコアパッケージに直接組み込まれていますが、その機能はバンドラ／ルーター／フレームワークの何らかの組み合わせに統合されるまで使用できません。

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

これら全ての歴史と文脈を念頭に置いて、頻繁に繰り返されるいくつかの懸念事項（混乱しているか、FUDであるか、あるいは完全な陰謀論であるか）に答えていきましょう（そして、うまくいけば明確にし、払拭していきたいです）。

懸念：Vercel、Next、そしてReact

「VercelがReactの開発を主導しており、その目的はサイトをホスティングしてより多くの収益を上げることだ」という見解が、今や非常に一般的になっています。一例として、これは今年の初めにあったRedditのスレッドで最も多く支持されたコメントです：

これは、他のいくつかの関連する懸念点と結びついています：

• NextはReactのドキュメントで最初に推奨されており、Next App Routerも「Reactチームのフルスタックアーキテクチャビジョンを構成する機能は何か？」の下で主な例として言及されている
• Nextは依然としてRSCの唯一の本番実装である
• Reactチームのメンバーは「このNextのリリースが本当のReact 18だ」と述べたと引用されている

人々がこの結論に至る理由は理解できます。VercelはReactチームのメンバーを何人か雇用し、彼らはReact自体とNextの両方に取り組んでいます。時系列的には、これは自然にRSCの開発と、ユーザーにフレームワークの使用を促すという新しいシフトと一致しました...そして見てください、その「明白な」フレームワークはまさにNextです！一方、VercelはNextをVercel上で簡単にデプロイしてホストするために、莫大な資金と労力を投入してきました。Nextを他の場所でホストすることは可能ですが、機能しなかったり、設定が難しかったりする機能が常にありました。

とはいえ、私が見てきた全てのことから、この見方は一般的に因果関係を逆転させており、ほとんどがFUDです。はい、もちろんVercelは最終的に自分たちに利益をもたらすと考える取り組みに投資してきました。しかし、前述の通り、SebとAndrewがVercelに移り、RSCの開発プロセスについて私が目にした全ての記述は、この一連の変更を推進したのはReactチームであったことを示しています。

RSCはReactチームのビジョンでした。Metaの内部では効果的にプロトタイプを作成してテストすることができなかったため、初めて、開発に投資し、設計を繰り返すための環境を提供する他のスポンサーが必要になりました。具体的な経緯は分かりませんが、私の理解では、ReactチームがVercelを説得してReactチームのビジョンに賛同させ、そしてそのビジョンに合致するApp Routerのアプローチを設計するためにNextを再設計することを彼らに任せた、ということです。

確かに、「Nextはこれを必要としている」といった類のReactへの変更はいくらかありました。あるNextConfsの前夜、重要なNextバージョンの発表があった際（おそらく13.4での安定版App Router？）、ReactリポジトリでいくつかのPRがマージされるのを見た記憶があります。しかし、その作業を行っていたのは依然としてReactチームのメンバーでした。

現時点で、Reactチームは分裂しています。大多数はまだMetaにいますが、Vercelのメンバーはコア実装の鍵を握っています。「Reactチームのミーティングは相変わらずだ」と読んだことがありますが、そのように分裂することから何らかの追加の複雑さが生じていても驚きません。

とはいえ、「VercelがReactを乗っ取った」というのは間違っており、「Reactコアの一部がVercelに移り、Vercelを説得してReactのビジョンに同調させた」という方が近いと私は考えています。また、「Vercel」がReactの設計を主導している、あるいはフレームワークとRSCへの重点化がVercelの収益を上げるという特定の意図を持っているという証拠も見当たりません。

懸念：ReactはNextでしか動かない

「Reactは今やNextでしか動かない」と、真剣に、あるいは不思議そうに言う人々のコメントをオンラインでいくつか見てきました。

これは簡単に反論できます。「新しいReactプロジェクトを始める」ページを見るだけでも、Nextではない他のフレームワークや、やや悪名高い「フレームワークなしでReactを使えますか？」セクションが表示されています。

明らかに、これはReactの仕組みに関する完全な誤解です。

しかし、これは同時に、React、「フレームワークを使え」というメッセージ、そしてVercelの影響力をめぐるメッセージングがいかに混乱しているかを物語っています。

これに非常に関連した「NextとReact、どちらを使うべきか？」という質問も付け加えておきます。これも頻繁に目にします。文字通りに読めば、「Next」と「React」は別物だということです。これも明らかに間違いです。NextはReactライブラリを使用するフレームワークです。それはスーパーセットであり、競合相手ではありません。ほとんどの人が意図しているのは、「Nextを使うべきか、それともCRAやViteのようなクライアントサイドSPAを使うべきか？」ということだと思いますが、それを明確に述べる語彙を持っていないのです。

これもまた、ここでの境界線についてどれほどの混乱があるかを示しています。

懸念：Reactがいつかクライアントアプリで動かなくなるかもしれない

この懸念もよく目にします。懸念は、「もしReactチームがサーバーを必要とする機能にこれほどの重点と労力を注いでいるなら、それはいつかクライアントサイドの機能が変わったりなくなったりする可能性があるということか？」というものです。

人々がこの恐怖を抱く理由は理解できます。それは、Reactチームからのトーンと重点の大きな変化、そして彼らがサーバーサイドの機能に注いできた労力の量によって引き起こされています。

しかし、これが決して起こりえないことも明らかです。Reactのクライアントレンダリング機能は、決してなくなりません！ Meta自身が何百万行もの既存のReactコードを持っているという事実だけでも、それが分かります。その上、Reactチームは常にコードレベルの後方互換性に関して非常に優れてきました - 破壊的変更を記述し、非推奨の機能を最終的に削除するまで何年も保持し、移行ガイドやcodemodを提供してきました。

また、React 19と19.1の機能の多くはクライアント専用であることにも注目する価値があります。どちらかと言えば、コミュニティはサーバーサイドの機能に注がれた労力を過大評価し、クライアントサイドの機能に注がれた労力を見逃してきました。

懸念：なぜReactはフレームワークを推すのか

そして、次の議論につながります。なぜReactチームは、「そうしないと間違いだ」と言ってまで、全てのReactユーザーにフレームワークを使わせることにそれほど固執するのでしょうか？

これは、私がより多くの共感と同感を持つ懸念です。私は彼らが「Nextを使わせてVercelでホスティングさせよう」という目標で「フレームワークを使え」と言っているのではないと述べましたが、ではその理由は何なのでしょうか？

Reactチームのフレームワークに対する見解

Andrew Clarkの2023年1月のツイートは、その意図をかなり明確に述べています。

同様に、Dan AbramovがCRAを非推奨と見なす理由を説明した際にも：

私はReactチームとの会話で、Reactアプリの読み込み時間が遅く、全体的なパフォーマンスが悪いという外部からの多くの不満を聞いていると直接言われたこともあります。ですから、フレームワークの重視はそれに対する直接的な反応であり、デフォルトでより多くのアプリがまともなパフォーマンスを持つようにするという目標があります。

それに基づくと、Reactチームのスタンスは次のように要約できます：

• フレームワークには、データフェッチ、ルーティング、サーバーレンダリングのための組み込みのアプローチがあり、それらは連携して動作するように設計されている
• それらは全て箱から出してすぐに提供されるため、部品を選んで組み合わせる（うまく連携しないかもしれない）時間を費やす必要がない
• フレームワークは、ビルド設定やより良いデータフェッチパターンにより、デフォルトでより良いパフォーマンスにつながる
• さらに、React Server Componentsは、正しく動作するためにフレームワークへの統合が必要である

これらの懸念は、Reactチームが今日Reactがどのように使用されるべきだと感じているかにとって極めて重要である

言い換えれば、それはイデオロギー的なスタンス、「これはあなたの時間と労力を節約する」という信念、そして「ほとんどのReactアプリは同様のパターンに従い、同様のソリューションを必要とする」という信念の組み合わせなのです。

フレームワーク、SSR、そしてSPA

また、「サーバーレンダリング」という特定の言及に注意してください。一般的に、Reactチームとエコシステムの他の主要メンバー（Remix / React RouterのRyan FlorenceとMichael Jacksonなど）の両方が、クライアントでのデータフェッチの「ウォーターフォール」（例えば、<List>がアイテムのセットをフェッチし、その子をレンダリングし、<ListItem>がマウント後に独自のフェッチを行うなど）を避けるためにサーバーレンダリングを行う必要性を強く強調してきました。NextやRemixのようなフレームワークは、箱から出してすぐにサーバーレンダリングをサポートするように特別に設計されています。

「より速い初期ページロード」、「クライアントのJSを少なくする」、「ウォーターフォールを避ける」といったSSRの正当化は、全て理にかなっています。私も、クライアントサイドのSPAがおそらく使われるべきでなかった多くの場所で使用されてきたこと（Reduxと本当に同じです）、そして、たとえすぐに全ての機能が必要でなくてもフレームワークから始めることが理にかなっていること、そうすれば後でそれらの機能が必要になったときに利用できるということに同意します。

NextとRemixには、静的なJS/HTMLアセットを出力するだけの「SPA / エクスポート」モードがあるので、それらを使ってNodeサーバープロセスを必要としない純粋なクライアントサイドアプリを作成することは可能です。しかし、それらはデフォルトではなく、コミュニティのほとんどがそれがオプションであることすら知らないだろうと私は推測します。

フレームワーク推奨にはニュアンスが欠けている

これら全てを踏まえて、私はReactチームがなぜデフォルトとしてフレームワークを推奨することに決めたのかを理解しています。それは合理的な意見であり、平均的なReactアプリを改善するための正当な意図だと思います。

しかし、私はまた、その「推奨」が、エコシステム全体でReactが実際に使用されている多様な方法を充分に評価しない、過度に広範な処方箋に変わってしまったと感じています。

フルスタックのReactフレームワークを使用する多くの正当な理由がありますが、使用しない理由もたくさんあります：

• フレームワークは多くの追加機能を追加しますが、それは学習する複雑さも追加し、Reactの使い方を把握しようとしている初心者にはあまり適していません。
• 追加された複雑さは、誤ってサーバーコンポーネントでContextやフックを使用してしまう（エラーをスローする）など、混乱につながる罠にもなり得ます。
• 多くの企業はJSバックエンドを運用していないかもしれず、それに対する規則や制限さえあるかもしれません。
• サーバー機能を持つフレームワークは実行に特定のホスティングを必要としますが、純粋なSPAは静的なHTMLとJSを提供する場所ならどこでも（Github PagesやAmazon S3を含む）簡単にホストできます。
• ライブラリを選び出す必要性は、しばしばReactユーザーにとって不満の源でしたが、それはプロジェクトを特定のニーズに合わせてカスタマイズすることを可能にします。意見の強いフレームワークは、それらの決定のほとんどを行う必要性をなくしますが、後で挙動をカスタマイズする能力を制限することもあります。
• 「サーバーレンダリング」への重点化は、一部の種類のアプリには明らかに役立ちますが、全てではありません - クライアントサイドだけで生きる必要があるアプリもたくさんあります。

ドキュメントの推奨事項は重要

Reactチームは「ドキュメントは初心者を対象としている」と述べており、そのため推奨されるツールやオプションのリストを混乱を避けるためにかなりシンプルに保ちたいと考えています。これは非常に合理的なスタンスです。

彼らはまた、「Viteを使うべきだと知っているほど経験豊富な人は、どのみちドキュメントにそれがリストされているのを見る必要はない」（意訳）とも述べています。それは技術的には真実です。

しかし、ドキュメントを読むのは初心者だけではありませんし、ドキュメントが推奨するものは公式の承認の印としての影響力を持ちます。それが、Reactチームが歴史的に特定のライブラリや技術を推奨することを避けてきた大きな理由の一部です。

フレームワーク／ビルドツールの使用統計を振り返ると、今日、Vite ReactとCRAの使用量はNextを上回っており、SPAの使用が依然としてReactエコシステムの少なくとも半分を占めていることは明らかです。ドキュメントの推奨事項はその使用状況を反映すべきです。

エコシステムの軽視

新しいReactドキュメントが公開されたとき、フレームワーク以外のオプションについての唯一の言及は、「フレームワークなしでReactを使えますか？」と題された展開可能な詳細セクションで、「はい、しかし私たちはそれが良い考えだとは思いません」と述べるいくつかの段落がありました。

そして、そのセクションの最後で語られていたのがこちらの声明でした：

つまり、新しいセットアップページはCreate React Appをリストアップしなかっただけでなく、最も近い同等のツール（Vite）はページの外部セクションで意味のあるオプションとしてさえリストされていませんでした。代わりに、それはこの展開可能な説明の最後に単なる言及として記されていました。

また、「珍しい制約」というフレーズはここでは非常に不適切だと言いたいです。SPAはReactコミュニティで当初から標準的なアーキテクチャでした。CRAとViteは一般的に使用されています。SPAを構築することが、どうして突然「珍しい制約」になるのでしょうか？アーキテクチャ的な理由からビジネス上の理由、学習の単純さまで、SPAを望む理由はたくさんあります。それらは「珍しい」ものではありません - それらは全て一般的なユースケースです。

そしてそれを超えて...「私たちはあなたを止めることはできません」というフレーズに注目してください。そのフレーズは、多くの人々の目に、コミュニティを軽視する不適切な表現として、そしてReactチームが一夜にしてSPAをサポートされていないアプローチとして格下げしていることのしるしとして映りました。

この例として、2023年半ばのドキュメントにおける「フレームワーク」重視に関する議論からの引用を以下に示します：

ドキュメントの推奨事項の修正

Reactチームが最終的に2025年初頭にCRAを非推奨と発表したとき（私がそれを修正し、その非推奨を公式にするように彼らを後押しした後）、最初のドキュメント更新には新しい「独自のフレームワークを構築する」ページが含まれていました。そのコンセプトは、独自のルーターとデータフェッチのアプローチを選ぶことは、「本物の」フレームワークほど良くない特注のフレームワークを寄せ集めることと同等である、というものでした。

ここでのメンタルモデルは理解できますが、これもまた、エコシステムがアプリを構築してきた方法と、人々が独自のオプションを選択する能力の両方をかなり軽視しています。

一例として、Viteの作者であるEvan Youは彼の見解を投稿しました：

私は最終的に、トーンを改善し、プロジェクトセットアップツールの推奨にニュアンスを加え、アプローチを選択する際のアーキテクチャ的なガイダンスを提供するために、セットアップページを刷新するドラフトPRを提出しました。そのPRはクローズされましたが、Reactチームはいくつかのアイデアと言い回しを新しいPRにチェリーピックしました。

最終的に、彼らはかなり合理的な「Reactアプリをゼロから構築する」セットアップページに落ち着きました。それはSPAと独自のツールを選ぶことを有効なアプローチとして認識し、Vite / Parcel / RSPackを推奨ビルドツールとしてリストアップし、いくつかのルーターとデータフェッチライブラリを指し示し、プロジェクトを設定しようとしているユーザーに実際に役立つガイダンスを提供しています。

ドキュメントがその点に達するまでに数年かかったのは残念です:( 新しいドキュメントがリリースされた直後に、Reactチームがコミュニティから推奨された表現の変更のいくつかを適用していれば、混乱と苦悩の多くは避けられたかもしれません。

懸念：サーバーコンポーネントのドキュメントと説明

React Server Componentsに関する大きな問題点と混乱の原因の1つは、公式のドキュメントと情報が散在しており、残念ながら不足していることです。

Reactチームは2020年12月に説明ビデオ付きでRSCを発表し、それに続いてRSCを説明する詳細なRFCドキュメントが公開しました。これらは背景と主な動機を説明する上で、まずまずの内容でした。

しかし、RSCの開発プロセスと、設計上の選択を実装するのはフレームワーク次第であるという事実が相まって、実際のReactドキュメントはRSCを有意義に文書化することはありませんでした。

新しいApp Routerの形でRSCの最初の公式ベータ版がNext 13.0で公開されるまでにほぼ2年かかり、さらに6ヶ月後、2023年5月にNext 13.4が公式にApp Routerを「安定版」であり本番環境対応であると宣言しました。VercelとNextには小規模ながら非常に活発なdevrelチームがあり、Next 13.4のリリースの頃には、当時新しかったApp RouterをカバーするためにNextのドキュメントを大幅に書き直していました（「ベータ版」ドキュメントとして利用可能）。それには、RSCの使用について語るいくつかのドキュメントページが、「データフェッチ」カテゴリの下に含まれていました。また、後には「React Server Componentsを理解する」のような詳細なブログ投稿もありました。これらは、アーキテクチャとコンセプトの非常に役立つ説明を含む、優れたリソースでした。

それにもかかわらず、RSCの機能はReact自体の一部であったにもかかわらず、ReactのドキュメントにはRSCに関する情報が一切ありませんでした。「RSCとは何か」もなく、「RSCをどう使うか」もなく、そして間違いなく「自分のライブラリをRSCと統合するにはどうすればよいか」もありませんでした。Vercelのチームは実際の製品とReactとの重複部分を文書化する良い仕事をしましたが、実際のReactドキュメント自体にRSCに関する情報や説明がないことは人々にとって非常に混乱を招きました（時系列的には、それは数ヶ月前に公式にローンチされたばかりでした）。

ソーシャルメディア上では、個々のReactチームメンバーによる多くの議論があり、質問に答えたり、概念としてのRSCを擁護したり、RSCのセールスポイントを具体化しようとしたりしてきました。しかし、現在、RSCに関する唯一の公式コアドキュメントページはAPIリファレンス：サーバーコンポーネントです。しかしこのページは正直なところ混乱を招くだけで特に役立つようには思えません。それは内容的に間違いなく「APIリファレンス」ではなく、その内容にはRSCを紹介したり、いつ、どのように使用するかを説明したりする実際の文脈がありません - それはランダムなトピックのごちゃまぜです。

RSCのさまざまな側面を説明する優れた外部ブログ投稿がいくつかありました：

• Dan AbramovはRSCのメンタルモデルとそれらが解決する問題を説明する数多くの素晴らしい投稿を書いています。
• Vercelは素晴らしい「React Server Componentsを理解する」紹介ブログ投稿を公開しました。
• Daniel Saewitzは「サーバーコンポーネントは選択肢を与える」を書き、それらがツールボックスへの追加であることを説明しました。

これこそが、Reactのコアドキュメントにあるべき情報です - RSCのコンセプトと、なぜそれらを使いたいかの説明であり、特定のフレームワークがRSCをどのように実装したかとは無関係です。

これに関連して、コミュニティは「RSCはReactの未来である」、「Reactチームは私たちにRSCを常にどこでも使ってほしいと思っている」という考えを持ち帰ってしまいました。実際には、Reactチームのメンバーがソーシャルメディアで「RSCはオプションであり、私たちはただ人々にそれを正しく理解してほしいだけだ」と明言しているのを見てきました。その混乱を考えると、その点を特にドキュメントで指摘することが重要だと思われます。

個人的には、ReactのコアドキュメントにRSCに関するセクション全体が追加されるのを見たいです。例えば、以下のようなページです：

• 「RSC入門」
• メンタルモデル
• ユースケース / RSCを選択するタイミング
• 技術的なデータフロー / アーキテクチャ
• 採用 / 移行
• FAQ
• フレームワーク実装者ガイド

これらのドキュメントページがあっても、全ての疑問がなくなるわけではありません。そもそもドキュメントを読まない人もたくさんいます:) しかし、これらのトピックが公式にカバーされることで可視化され、ソーシャルメディアでこれらの質問が持ち上がるたびに答えるために使用できるリソースとして機能するでしょう。

懸念からの教訓

私は、Reactチームがインターネット上のFUDを払拭するために彼らの時間の全てを費やすのが彼らの仕事だとは思いません。多くの人が意見を持つでしょうし、その多くは異なるか間違っているでしょう。

とはいえ、「フレームワークとサーバーへのこの全ての強調は、Vercelにお金を稼がせるために私たちに強制されている」という一貫した強いテーマがあることは驚くべきことです。それは間違っていますが、人々をその信念に導くのに十分な状況証拠があり、Reactチームの行動と声明はある程度、それを反証するのではなく、その信念を強化してしまいました。残念ながら、現時点ではそれはコミュニティに永久に埋め込まれたミームのようになっており、私たちはそれをなくすことはできないと思います。

また、ユーザーがReactが将来どのように変化したり動作しなくなったりする可能性があるかについて心配したり、想定したりしていることも、本当に懸念すべきことです。特に、それらの懸念が明らかに間違っており、簡単に反証可能である場合はなおさらです。あなたはこれまで通りにReactを使い続けることができ、RSC / サーバーの機能は全て、完全に付加的でオプションです。

インターネットがそういうものである以上、実際のReactブログにそれらの声明を明確に反論するブログ投稿があったとしても、多くの人々の心を変えることはないでしょう。しかし、React組織からのより良いデベロッパーリレーションズ活動 - 懸念を読み、それらが存在することを認め、どこから来ているのかを理解し、それらを明確にして答えようとすることにもっと時間を費やすこと - で、その最悪の事態の一部は避けられたかもしれないと感じます。

「フレームワーク」への推進は本当に善意から出たものだと感じますが、同時にあまりにも広範で、最終的にはエコシステムにおける多様な使用パターンを軽視しているとも思います。はい、ニュアンスを提供するドキュメントを書き、推奨事項を提供するのは難しいですし、初心者を対象とし、エコシステムをより良い方向に導くために物事をシンプルに保とうとすることは理解できます...しかし、メンテナーであることの一部は、コミュニティによってあなたのツールが使用される多様な方法を認識し、サポートすることです。

私たちは最終的に、プロジェクトを自分でセットアップするための有用な指示を持ち、それを有効なアプローチとして認識する、合理的なReactプロジェクトセットアップドキュメントのセットにたどり着きました。その時点に到達するまでに数年かかったこと、そしてReactチームがそのセクションを改善する方法に関するコミュニティからの非常に声高なフィードバックを本質的に無視したことは残念です。ドキュメントは、アプリに適したツールとアーキテクチャを選択する方法に関するアドバイスがもっとあれば、依然として大いに恩恵を受けるでしょう。

同様に、RSCのコンセプトとトレードオフに関する公式のコアドキュメント情報の欠如が混乱を助長してきました。これらのトピックをカバーすることが、人々のRSCに対する理解とそれに伴う言説を大きく改善すると強く感じています。

最後に

この記事が、Reactがどのように、そしてなぜこのように発展してきたのか、Reactの開発プロセスにどのような影響があるのか、Reactチームの主な目標は何か、そして今日のReactの使用パターンはどのような状況にあるのか、といった多くの疑問に答えるものであれば幸いです。

また、Reactチームの動機や特定の方向に推進する理由に関する混乱やFUDの一部を払拭できたことを願っています。人々が技術的な方向性に同意しないこと、あるいはReact Server Componentsやより大きなフレームワークへの移行が必要ないと判断することは問題ありません。しかし、Reactチームの意図はここでも正当で純粋なものです。

広く使われているライブラリを維持し、コミュニティの多様なニーズや使用パターンを満たすことは、本当に難しいことです。私はReactチームが全体として良い仕事をしてきたと思います。残念ながら、コミュニケーションが不十分であった点やドキュメントの問題が、コミュニティにおける多くの不満や苦悩の大きな要因となってきました。

今後、私たちはそのコミュニケーションを改善する方法を見つけ、さらにはドキュメントの改善にもっと多くのコミュニティが関わってくれるようになることを期待しています。