Reactを始める新しい方法: Create React Appからフレームワークへ
(ko.react.dev)Create React Appが非推奨になって以降、Reactでは公式にフレームワークから始めることが推奨されています。
Reactを始める新しい方法: Create React Appからフレームワークへ
Reactで新しいアプリやWebサイトを構築するなら、フレームワークから始めるのが最善です。
アプリに既存のフレームワークでは十分に対応できない制約がある場合、自前のフレームワークを構築したい場合、あるいはReactアプリの基本だけを学びたい場合は、Reactアプリをゼロから構築することもできます。
フルスタックフレームワーク
これらの推奨フレームワークは、本番環境でアプリをデプロイし拡張するために必要なすべての機能をサポートしています。これらは最新のReact機能を統合し、Reactのアーキテクチャを活用しています。
フルスタックフレームワークにサーバーは必須ではありません
このページのすべてのフレームワークは、クライアントサイドレンダリング（CSR）、シングルページアプリ（SPA）、静的サイト生成（SSG）をサポートしています。これらのアプリは、サーバーなしでCDNまたは静的ホスティングサービスにデプロイできます。また、これらのフレームワークでは、ユースケースに適している場合にルートごとにサーバーサイドレンダリングを追加することもできます。
これにより、クライアント専用アプリとして開始し、後から要件が変わった場合でもアプリを書き直すことなく、個別のルートでサーバー機能を使うように選択できます。レンダリング戦略の設定方法については、各フレームワークのドキュメントを参照してください。
Next.js（App Router）
Next.jsのApp Routerは、Reactのアーキテクチャを最大限に活用してフルスタックReactアプリを実現するReactフレームワークです。
npx create-next-app@latest
Next.jsはVercelによってメンテナンスされています。Next.jsアプリを構築し、Node.jsやサーバーレスホスティング、あるいは自前のサーバーにデプロイできます。Next.jsはサーバー不要の静的エクスポートもサポートしています。Vercelは追加のオプトイン型有料クラウドサービスも提供しています。
React Router（v7）
React RouterはReactで最も人気のあるルーティングライブラリであり、Viteと組み合わせることでフルスタックReactフレームワークを作ることができます。標準Web APIを重視しており、さまざまなJavaScriptランタイムやプラットフォーム向けのすぐに使えるデプロイテンプレートがあります。
新しいReact Routerフレームワークを作成するには、次のコマンドを使ってください。
npx create-react-router@latest
React RouterはShopifyによってメンテナンスされています。
Expo（ネイティブアプリ向け）
Expoは、ネイティブUIを使ってAndroid、iOS、Web向けのユニバーサルアプリを作れるReactフレームワークです。 ネイティブ部分を簡単に扱えるようにするReact Native SDKを提供しています。新しいExpoプロジェクトを作成するには、次のコマンドを使ってください。
npx create-expo-app@latest
Expoを初めて使う場合は、Expoチュートリアルを参照してください。
ExpoはExpo（the company）によってメンテナンスされています。Expoでアプリを構築するのは無料で、GoogleやAppleのストアに制限なく提出できます。Expoは追加のオプトイン型有料クラウドサービスも提供しています。
その他のフレームワーク
フルスタックReactのビジョンに向かって進んでいる、もう一つの新興フレームワークもあります。
- TanStack Start（Beta）: TanStack StartはTanStack RouterをベースにしたフルスタックReactフレームワークです。NitroやViteと同様に、ドキュメント全体のSSR、ストリーミング、サーバー関数、バンドリングや多くの便利なツールを提供します。
- RedwoodJS: Redwoodは、簡単にフルスタックWebアプリケーションを作れるよう、パッケージと設定があらかじめ組み込まれたフルスタックReactフレームワークです。
Reactチームのフルスタックアーキテクチャのビジョンを構成する機能とは何ですか？
Next.jsのApp Routerバンドラーは、公式のReact Server Components仕様をすべて実装しています。これにより、ビルド時のコンポーネント、サーバー専用コンポーネント、インタラクティブなコンポーネントを単一のReactツリーに混在させることができます。
たとえば、サーバー専用のReactコンポーネントを、データベースやファイルを読み込む async 関数として記述できます。次に、そのデータをインタラクティブなコンポーネントに渡せます。
// このコンポーネントは *サーバー上でのみ*（またはビルド中のみ）実行されます。
async function Talks({ confId }) {
// 1. サーバー上であればデータレイヤーとやり取りできます。APIエンドポイントは不要です。
const talks = await db.Talks.findAll({ confId });
// 2. レンダリングロジックを追加しても、JavaScriptバンドルサイズは大きくなりません。
const videos = talks.map(talk => talk.video);
// 3. ブラウザで実行されるコンポーネントにデータを渡します。
return <SearchableVideoList videos={videos} />;
}
Next.jsのApp Routerは、Suspenseとデータ取得を統合します。これにより、React tree内で異なるユーザーインターフェースをローディング状態（たとえばスケルトンプレースホルダー）として直接指定できます。
<Suspense fallback={<TalksLoading />}>
<Talks confId={conf.id} />
</Suspense>
サーバーコンポーネントとSuspenseはNext.jsの機能ではなく、Reactの機能です。しかし、フレームワークレベルでこれらを採用するには、関与と小さくない実装作業が必要です。現時点では、Next.js App Routerが最も完全な実装です。Reactチームは、次世代フレームワークでこれらの機能をより簡単に実装できるよう、バンドラー開発者と協力しています。
ゼロから始める
アプリに既存のフレームワークでは十分に対応できない制約がある場合、自前のフレームワークを構築したい場合、あるいはReactアプリの基本を学びたい場合には、Reactプロジェクトをゼロから始めるために使える別の選択肢があります。
ゼロから始めると柔軟性は高まりますが、ルーティング、データ取得、その他の一般的な利用パターンに使うツールを選ぶ必要があります。既存のフレームワークを使う代わりに、自分自身のフレームワークを構築するのに近いものです。私たちが推奨するフレームワークには、こうした問題に対する組み込みの解決策があります。
自分自身のソリューションを構築したい場合は、Vite、Parcel、または RSbuild のようなビルドツールから始められる、ゼロからReactアプリを作るガイドを参照してください。
6件のコメント
ReactはコンポーネントベースのUIライブラリにすぎません。単にHTMLにコンポーネントを表示するのは簡単ですが、Webサイトやアプリを作るには多くの機能が必要です。そのため、フレームワークを推奨します。これはReactだからという話ではなく、現代の多くのWebはWebフレームワークを通じて作られています。また、Reactは必ずしもReactベースのフレームワークである必要はなく、さまざまな言語で作られたWebフレームワーク（例: Go、Rust、Java など）と一緒に使うこともできるため、最終的な選択は常にユーザー次第です。
プログラマーがどのような制約条件のもとでReactを使うのか分からない状況なら、公式ドキュメントはできるだけバニラに近い環境を前提に書かれるべきではないか、と思います。
React は必ずしも React ベースのフレームワークでなくても、さまざまな言語で作られた Web フレームワーク（例: Go、Rust、Java など）と一緒に使えるので
-> 実際、これを考えると React 公式ドキュメントの get started に関しては、できるだけほかの依存関係なしに React だけを使うようにガイドするのが正しいのではないかと思います。
うーん…私も最近Reactを勉強していた立場として、
CRAが終了してしまって、手元の学習用ソースがCRAベースだからどうしようかと思ってNextやReact Routerなどを見て回ったのですが、これらはそれぞれ独自の技術が加わった形なので、Reactを学ぶ立場からするとあまり適切ではない気がします。個人的には、まだViteのほうがましなのではないかと思います。
Reactでは公式にフレームワークから始めることが推奨されるように -> もうとっくに手遅れな話ではありますが、React公式ドキュメントの時点から特定のフレームワークやビルドツールを使って始めることを勧める流れで入っていくのが本当に正しいのか、と思わなくもありません。
既存のコードベースの中ではそのフレームワークやビルドツールを使えない場合もありますし、依存関係を増やすこと自体を負担に感じることもあるはずです。
scriptタグひとつをHTMLに入れれば、そのライブラリの機能をそのまま使えた時代のほうが、気持ちはずっと楽だった気がします。あまりに昔の話でしょうか...私も、本当にそうしなければならないのかと思ってしまいます。