diff --git a/src/content/blog/2025/02/14/sunsetting-create-react-app.md b/src/content/blog/2025/02/14/sunsetting-create-react-app.md index 9ced6231c..70a7f7501 100644 --- a/src/content/blog/2025/02/14/sunsetting-create-react-app.md +++ b/src/content/blog/2025/02/14/sunsetting-create-react-app.md @@ -1,8 +1,8 @@ --- -title: "Sunsetting Create React App" +title: "Create React App の非推奨化" author: Matt Carroll and Ricky Hanlon date: 2025/02/14 -description: Today, we’re deprecating Create React App for new apps, and encouraging existing apps to migrate to a framework, or to migrate to a build tool like Vite, Parcel, or RSBuild. We’re also providing docs for when a framework isn’t a good fit for your project, you want to build your own framework, or you just want to learn how React works by building a React app from scratch. +description: 本日、新規アプリに対して Create React App を非推奨とし、既存のアプリにはフレームワークへの移行、または Vite、Parcel、RSBuild などのビルドツールへの移行を推奨します。また、フレームワークがプロジェクトに適していない場合や独自のフレームワークを構築したい場合、あるいは React がどのように動作するかを学ぶためにゼロから React アプリを構築したい場合のためのドキュメントも提供します。 --- February 14, 2025 by [Matt Carroll](https://twitter.com/mattcarrollcode) and [Ricky Hanlon](https://bsky.app/profile/ricky.fm) @@ -11,29 +11,29 @@ February 14, 2025 by [Matt Carroll](https://twitter.com/mattcarrollcode) and [Ri -Today, we’re deprecating [Create React App](https://create-react-app.dev/) for new apps, and encouraging existing apps to migrate to a [framework](#how-to-migrate-to-a-framework), or to [migrate to a build tool](#how-to-migrate-to-a-build-tool) like Vite, Parcel, or RSBuild. +本日、新しいアプリに対して [Create React App](https://create-react-app.dev/) を非推奨とします。既存のアプリに対しては、[フレームワーク](#how-to-migrate-to-a-framework)への移行、または Vite、Parcel、RSBuild などの[ビルドツールへの移行](#how-to-migrate-to-a-build-tool)を推奨します。 -We’re also providing docs for when a framework isn’t a good fit for your project, you want to build your own framework, or you just want to learn how React works by [building a React app from scratch](/learn/build-a-react-app-from-scratch). +また、フレームワークがプロジェクトに適していない場合や、独自のフレームワークを構築したい場合、あるいは[ゼロから React アプリを構築する](/learn/build-a-react-app-from-scratch)ことで React がどのように動作するかを学びたい場合のためのドキュメントも提供します。 ----- -When we released Create React App in 2016, there was no clear way to build a new React app. +2016 年に Create React App をリリースした当時は、新しい React アプリを構築するための明確な方法が存在しませんでした。 -To create a React app, you had to install a bunch of tools and wire them up together yourself to support basic features like JSX, linting, and hot reloading. This was very tricky to do correctly, so the [community](https://github.com/react-boilerplate/react-boilerplate) [created](https://github.com/kriasoft/react-starter-kit) [boilerplates](https://github.com/petehunt/react-boilerplate) for [common](https://github.com/gaearon/react-hot-boilerplate) [setups](https://github.com/erikras/react-redux-universal-hot-example). However, boilerplates were difficult to update and fragmentation made it difficult for React to release new features. +React アプリを作成するには、多くのツールをインストールしてそれらを自分で組み合わせ、JSX、リンタ、ホットリロードなどの基本機能をサポートしていく必要がありました。これを正しく行うのは非常に難しかったため、[コミュニティは](https://github.com/react-boilerplate/react-boilerplate) [セットアップを](https://github.com/kriasoft/react-starter-kit) [共通化するために](https://github.com/petehunt/react-boilerplate) [様々なボイラープレートを](https://github.com/gaearon/react-hot-boilerplate) [作成しました](https://github.com/erikras/react-redux-universal-hot-example)。しかし、ボイラープレートは更新が難しく、分断化が進むにつれ React が新機能をリリースするのは困難となっていきました。 -Create React App solved these problems by combining several tools into a single recommended configuration. This allowed apps a simple way to upgrade to new tooling features, and allowed the React team to deploy non-trivial tooling changes (Fast Refresh support, React Hooks lint rules) to the broadest possible audience. +Create React App は、いくつかのツールを単一の推奨セットアップにまとめることでこれらの問題を解決しました。これにより、アプリが新しいツールの機能を使うためのアップグレードが簡単になり、React チームは大きめのツールの変更（Fast Refresh のサポートやフックのリントルールなど）を最大限広範なユーザに展開できるようになりました。 -This model became so popular that there's an entire category of tools working this way today. +このモデルは非常に人気があるため、今日ではこのように動作するツール群が一大勢力として存在しています。 -## Deprecating Create React App {/*deprecating-create-react-app*/} +## Create React App の非推奨化 {/*deprecating-create-react-app*/} -Although Create React App makes it easy to get started, [there are several limitations](#limitations-of-build-tools) that make it difficult to build high performant production apps. In principle, we could solve these problems by essentially evolving it into a [framework](#why-we-recommend-frameworks). +Create React App は簡単に始められるものの、[いくつかの制限](#limitations-of-build-tools)があり、本番環境用の高性能なアプリを構築することが困難となっています。原理的には、これらの問題は Create React App を[フレームワーク](#why-we-recommend-frameworks)へと発展させることで解決可能でしょう。 -However, since Create React App currently has no active maintainers, and there are many existing frameworks that solve these problems already, we’ve decided to deprecate Create React App. +しかし、現在 Create React App にはアクティブなメンテナがいない一方で、これらの問題をすでに解決している多くの既存のフレームワークが存在します。このため、Create React App を非推奨とすることに決定しました。 -Starting today, if you install a new app, you will see a deprecation warning: +本日より、新しいアプリをインストールすると、非推奨の警告が表示されます。 @@ -48,48 +48,48 @@ This error message will only be shown once per install. -We've also added a deprecation notice to the Create React App [website](https://create-react-app.dev/) and GitHub [repo](https://github.com/facebook/create-react-app). Create React App will continue working in maintenance mode, and we've published a new version of Create React App to work with React 19. +また、Create React App の[ウェブサイト](https://create-react-app.dev/)と GitHub [リポジトリ](https://github.com/facebook/create-react-app)にも非推奨の通知を追加しました。Create React App はメンテナンスモードで動作を続けます。React 19 で動作する新しいバージョンの Create React App を公開しました。 -## How to Migrate to a Framework {/*how-to-migrate-to-a-framework*/} -We recommend [creating new React apps](/learn/creating-a-react-app) with a framework. All the frameworks we recommend support client-side rendering ([CSR](https://developer.mozilla.org/en-US/docs/Glossary/CSR)) and single-page apps ([SPA](https://developer.mozilla.org/en-US/docs/Glossary/SPA)), and can be deployed to a CDN or static hosting service without a server. +## フレームワークへの移行方法 {/*how-to-migrate-to-a-framework*/} +フレームワークを使用して[新しい React アプリを作成する](/learn/creating-a-react-app)ことをお勧めします。私たちが推奨するすべてのフレームワークは、クライアントサイドレンダー ([CSR](https://developer.mozilla.org/en-US/docs/Glossary/CSR)) とシングルページアプリ ([SPA](https://developer.mozilla.org/en-US/docs/Glossary/SPA)) をサポートしており、サーバなしで CDN や静的ホスティングサービスにデプロイ可能です。 -For existing apps, these guides will help you migrate to a client-only SPA: +既存のアプリをクライアント専用の SPA に移行したい場合は以下のガイドが役立ちます。 -* [Next.js’ Create React App migration guide](https://nextjs.org/docs/app/building-your-application/upgrading/from-create-react-app) -* [React Router’s framework adoption guide](https://reactrouter.com/upgrading/component-routes). -* [Expo webpack to Expo Router migration guide](https://docs.expo.dev/router/migrate/from-expo-webpack/) +* [Next.js の Create React App 移行ガイド](https://nextjs.org/docs/app/building-your-application/upgrading/from-create-react-app) +* [React Router のフレームワーク採用ガイド](https://reactrouter.com/upgrading/component-routes) +* [Expo webpack から Expo Router への移行ガイド](https://docs.expo.dev/router/migrate/from-expo-webpack/) -## How to Migrate to a Build Tool {/*how-to-migrate-to-a-build-tool*/} +## ビルドツールへの移行方法 {/*how-to-migrate-to-a-build-tool*/} -If your app has unusual constraints, or you prefer to solve these problems by building your own framework, or you just want to learn how react works from scratch, you can roll your own custom setup with React using Vite, Parcel or Rsbuild. +アプリに特異な制約がある場合や、独自のフレームワークを構築することでこれらの問題を解決したい場合、またはゼロから React がどのように動作するかを学びたい場合は、Vite、Parcel、Rsbuild を使用して React を用いたカスタムセットアップを作成できます。 -For existing apps, these guides will help you migrate to a build tool: +既存のアプリをこのようなビルドツールに移行したい場合は以下のガイドが役立ちます。 -* [Vite Create React App migration guide](https://www.robinwieruch.de/vite-create-react-app/) -* [Parcel Create React App migration guide](https://parceljs.org/migration/cra/) -* [Rsbuild Create React App migration guide](https://rsbuild.dev/guide/migration/cra) +* [Vite の Create React App 移行ガイド](https://www.robinwieruch.de/vite-create-react-app/) +* [Parcel の Create React App 移行ガイド](https://parceljs.org/migration/cra/) +* [Rsbuild の Create React App 移行ガイド](https://rsbuild.dev/guide/migration/cra) -To help get started with Vite, Parcel or Rsbuild, we've added new docs for [Building a React App from Scratch](/learn/build-a-react-app-from-scratch). +Vite、Parcel、Rsbuild を使用して始めるために、[ゼロから React アプリを構築する](/learn/build-a-react-app-from-scratch)ための新しいドキュメントを追加しました。 -#### Do I need a framework? {/*do-i-need-a-framework*/} +#### フレームワークは必要？ {/*do-i-need-a-framework*/} -Most apps would benefit from a framework, but there are valid cases to build a React app from scratch. A good rule of thumb is if your app needs routing, you would probably benefit from a framework. +ほとんどのアプリはフレームワークの恩恵を受けますが、ゼロから React アプリを構築する正当なケースもあります。目安として、アプリにルーティングが必要なら、おそらくフレームワークの恩恵を受ける可能性が高いでしょう。 -Just like Svelte has Sveltekit, Vue has Nuxt, and Solid has SolidStart, [React recommends using a framework](#why-we-recommend-frameworks) that fully integrates routing into features like data-fetching and code-splitting out of the box. This avoids the pain of needing to write your own complex configurations and essentially build a framework yourself. +Svelte には Sveltekit、Vue には Nuxt、Solid には SolidStart があるように、React は、ルーティングをデータフェッチやコード分割などの機能に完全に統合した[フレームワークを使用することを推奨しています](#why-we-recommend-frameworks)。これにより、複雑な設定を自分で書いて実質的に自分用のフレームワークを構築してしまうような必要がなくなります。 -However, you can always [build a React app from scratch](/learn/build-a-react-app-from-scratch) using a build tool like Vite, Parcel, or Rsbuild. +しかし Vite、Parcel、Rsbuild などのビルドツールを使用して[ゼロから React アプリを構築する](/learn/build-a-react-app-from-scratch)ことも可能です。 -Continue reading to learn more about the [limitations of build tools](#limitations-of-build-tools) and [why we recommend frameworks](#why-we-recommend-frameworks). +以下で、[ビルドツールの制約](#limitations-of-build-tools)と[フレームワークを推奨する理由](#why-we-recommend-frameworks)についてさらに述べていきます。 -## Limitations of Build Tools {/*limitations-of-build-tools*/} +## ビルドツールの制約とは {/*limitations-of-build-tools*/} -Create React App and build tools like it make it easy to get started building a React app. After running `npx create-react-app my-app`, you get a fully configured React app with a development server, linting, and a production build. +Create React App やそれに類するビルドツールを使えば、React アプリの構築を簡単に始められます。`npx create-react-app my-app` を実行すると、開発用サーバ、リンタ、本番用ビルド機能が完全に設定された React アプリが手に入ります。 -For example, if you're building an internal admin tool, you can start with a landing page: +たとえば、内部向けの管理ツールを構築している場合、さっそく以下のようなランディングページから始めることができるでしょう。 ```js export default function App() { @@ -101,13 +101,13 @@ export default function App() { } ``` -This allows you to immediately start coding in React with features like JSX, default linting rules, and a bundler to run in both development and production. However, this setup is missing the tools you need to build a real production app. +これにより、JSX、デフォルトのリントルール、開発環境と本番環境の両方で実行するためのバンドラといった機能がある状態で、すぐに React でコーディングを始めることができます。しかし、このセットアップには、実際の本番用アプリを構築するために必要なツールが欠けています。 -Most production apps need solutions to problems like routing, data fetching, and code splitting. +ほとんどの本番用アプリでは、ルーティング、データフェッチ、コード分割などの問題に対する解決策も必要なのです。 -### Routing {/*routing*/} +### ルーティング {/*routing*/} -Create React App does not include a specific routing solution. If you're just getting started, one option is to use `useState` to switch between routes. But doing this means that you can't share links to your app - every link would go to the same page - and structuring your app becomes difficult over time: +Create React App には、特定のルーティングソリューションは含まれていません。始めたばかりの場合、ページを切り替えるために `useState` を使用する、というのがひとつの選択肢です。しかし、こうするとアプリ内リンクの共有が不可能（すべてのリンクが同じページに移動してしまう）になりますし、時間が経つにつれてアプリを組み立てるのが難しくなります。 ```js import {useState} from 'react'; @@ -127,7 +127,7 @@ export default function App() { } ``` -This is why most apps that use Create React App solve add routing with a routing library like [React Router](https://reactrouter.com/) or [Tanstack Router](https://tanstack.com/router/latest). With a routing library, you can add additional routes to the app, which provides opinions on the structure of your app, and allows you to start sharing links to routes. For example, with React Router you can define routes: +このため、Create React App を使用するほとんどのアプリは、[React Router](https://reactrouter.com/) や [Tanstack Router](https://tanstack.com/router/latest) などのルーティングライブラリを使用してルーティングを追加します。ルーティングライブラリを使用することで、アプリに追加のルート (route) を追加でき、アプリの組み立て方に対する指針が生まれ、各ページへのリンクを共有できるようになります。たとえば、React Router では以下のようにルートを定義できます。 ```js import {RouterProvider, createBrowserRouter} from 'react-router'; @@ -148,15 +148,15 @@ export default function App() { } ``` -With this change, you can share a link to `/dashboard` and the app will navigate to the dashboard page . Once you have a routing library, you can add additional features like nested routes, route guards, and route transitions, which are difficult to implement without a routing library. +これにより、`/dashboard` というリンクを共有すれば、アプリはダッシュボードページに移動するようになります。ルーティングライブラリには、ルートのネスト、ルートガード、ルート間画面遷移効果 (root transition) などの追加機能もあり、これらはルーティングライブラリなしには実装困難です。 -There's a tradeoff being made here: the routing library adds complexity to the app, but it also adds features that are difficult to implement without it. +ルーティングライブラリを使うとアプリは複雑になりますが、その代わりに、それなしでは作れないような機能も使えるようになる、というトレードオフがあるのです。 -### Data Fetching {/*data-fetching*/} +### データフェッチ {/*data-fetching*/} -Another common problem in Create React App is data fetching. Create React App does not include a specific data fetching solution. If you're just getting started, a common option is to use `fetch` in an effect to load data. +Create React App でのもうひとつの一般的な問題はデータフェッチです。Create React App には、特定のデータフェッチソリューションは含まれていません。まだ始めたばかりという場合、一般的な選択肢はデータをロードするためにエフェクト内で `fetch` を使用することです。 -But doing this means that the data is fetched after the component renders, which can cause network waterfalls. Network waterfalls are caused by fetching data when your app renders instead of in parallel while the code is downloading: +しかし、これを行うと、データがコンポーネントのレンダー後にフェッチされるため、ネットワークウォーターフォールが発生します。ネットワークウォーターフォールは、コードとデータを並行でダウンロードするのではなく、アプリのレンダー後にデータをフェッチすることで発生します。 ```js export default function Dashboard() { @@ -177,9 +177,9 @@ export default function Dashboard() { } ``` -Fetching in an effect means the user has to wait longer to see the content, even though the data could have been fetched earlier. To solve this, you can use a data fetching library like [React Query](https://react-query.tanstack.com/), [SWR](https://swr.vercel.app/), [Apollo](https://www.apollographql.com/docs/react), or [Relay](https://relay.dev/) which provide options to prefetch data so the request is started before the component renders. +エフェクト内でフェッチするということは、ユーザがコンテンツを見るまでの待ち時間が長くなるということです。データはもっと早く取得できていたかもしれないのです。これを解決するために、[React Query](https://react-query.tanstack.com/)、[SWR](https://swr.vercel.app/)、[Apollo](https://www.apollographql.com/docs/react)、[Relay](https://relay.dev/) などのデータフェッチライブラリを使用すると、コンポーネントのレンダーより前にデータをプリフェッチできるオプションが使用可能です。 -These libraries work best when integrated with your routing "loader" pattern to specify data dependencies at the route level, which allows the router to optimize your data fetches: +これらのライブラリは、ルートのレベルで依存データを指定するための、「ルーティングローダ」パターンと統合することで最適に機能します。これによりルータがデータフェッチを最適化可能です。 ```js export async function loader() { @@ -198,21 +198,21 @@ export default function Dashboard({loaderData}) { } ``` -On initial load, the router can fetch the data immediately before the route is rendered. As the user navigates around the app, the router is able to fetch both the data and the route at the same time, parallelizing the fetches. This reduces the time it takes to see the content on the screen, and can improve the user experience. +初回ロード時に、ルータはルートがレンダーされる前にデータを即座にフェッチできます。ユーザがアプリ内を移動する際、ルータはデータとルートのフェッチを並列化して同時に行えます。これにより、画面上のコンテンツを見るまでの時間が短縮され、ユーザエクスペリエンスが向上します。 -However, this requires correctly configuring the loaders in your app and trades off complexity for performance. +ただし、これにはアプリ内のローダを正しく設定する必要があり、パフォーマンスのために複雑さが犠牲になっています。 -### Code Splitting {/*code-splitting*/} +### コード分割 {/*code-splitting*/} -Another common problem in Create React App is [code splitting](https://www.patterns.dev/vanilla/bundle-splitting). Create React App does not include a specific code splitting solution. If you're just getting started, you might not consider code splitting at all. +Create React App における次の一般的な問題は[コード分割](https://www.patterns.dev/vanilla/bundle-splitting)です。Create React App には、特定のコード分割ソリューションは含まれていません。始めたばかりの場合、コード分割について考えることは全くないかもしれません。 -This means your app is shipped as a single bundle: +その場合、アプリは単一のバンドルとしてホストされます。 ```txt - bundle.js 75kb ``` -But for ideal performance, you should "split" your code into separate bundles so the user only needs to download what they need. This decreases the time the user needs to wait to load your app, by only downloading the code they need to see the page they are on. +しかし、理想的なパフォーマンスのためには、コードを別々のバンドルに「分割」し、ユーザが必要とするものだけをダウンロードするようにする必要があります。これにより、ユーザは現在いるページを表示するために必要なコードだけをダウンロードするようになり、アプリをロードするまでの待ち時間が短縮されます。 ```txt - core.js 25kb @@ -220,7 +220,7 @@ But for ideal performance, you should "split" your code into separate bundles so - dashboard.js 25kb ``` -One way to do code-splitting is with `React.lazy`. However, this means that the code is not fetched until the component renders, which can cause network waterfalls. A more optimal solution is to use a router feature that fetches the code in parallel while the code is downloading. For example, React Router provides a `lazy` option to specify that a route should be code split and optimize when it is loaded: +コード分割を行う方法のひとつは、`React.lazy` を使用することです。しかし、この方法ではレンダーされる段階になって初めてコードが取得されるため、ネットワークウォーターフォールが発生する可能性があります。より良い解決策は、コードがダウンロードされる間に並行してコードをフェッチするためのルータ機能を使用することです。例えば、React Router は `lazy` オプションを提供しており、これを使ってルートをコード分割対象として指定し、読み込みタイミングを最適化できます。 ```js import Home from './Home'; @@ -233,88 +233,88 @@ const router = createBrowserRouter([ ]); ``` -Optimized code-splitting is tricky to get right, and it's easy to make mistakes that can cause the user to download more code than they need. It works best when integrated with your router and data loading solutions to maximize caching, parallelize fetches, and support ["import on interaction"](https://www.patterns.dev/vanilla/import-on-interaction) patterns. +コード分割を正しく行うことは難しく、ユーザが必要以上のコードをダウンロードしてしまうというミスがよく発生します。コード分割が最大限活躍するのは、ルータやデータロード処理と結合することで、キャッシュを最大限活用し、フェッチを並行して行い、["import on interaction"](https://www.patterns.dev/vanilla/import-on-interaction) パターンをサポートした場合です。 -### And more... {/*and-more*/} +### ほかにも… {/*and-more*/} -These are just a few examples of the limitations of Create React App. +以上は、Create React App における制約のほんの一部に過ぎません。 -Once you've integrated routing, data-fetching, and code splitting, you now also need to consider pending states, navigation interruptions, error messages to the user, and revalidation of the data. There are entire categories of problems that users need to solve like: +ルーティング、データフェッチ、コード分割を組み込んだ後も、今度は送信中状態、ナビゲーションの中断、ユーザへのエラーメッセージ、データの再検証を考慮する必要があります。開発者が解決しなければならない問題領域は大量に存在するのです。
-All of these work together to create the most optimal [loading sequence](https://www.patterns.dev/vanilla/loading-sequence). +これらすべてが最適な[ロードシーケンス](https://www.patterns.dev/vanilla/loading-sequence)を作成するために連携します。 -Solving each of these problems individually in Create React App can be difficult as each problem is interconnected with the others and can require deep expertise in problem areas users may not be familiar with. In order to solve these problems, users end up building their own bespoke solutions on top of Create React App, which was the problem Create React App originally tried to solve. +Create React App でこれらの問題を個別に解決することは困難です。各問題は他の問題と相互に関連しており、開発者が慣れていない問題領域での深い専門知識を必要とすることがあります。これらの問題を解決しようとすると、開発者は Create React App の上に独自の特注ソリューションを構築していく羽目になりますが、本来 Create React App はそういうことをしないで済むためのもののはずでした。 -## Why we Recommend Frameworks {/*why-we-recommend-frameworks*/} +## 我々がフレームワークを推奨する理由 {/*why-we-recommend-frameworks*/} -Although you could solve all these pieces yourself in a build tool like Create React App, Vite, or Parcel, it is hard to do well. Just like when Create React App itself integrated several build tools together, you need a tool to integrate all of these features together to provide the best experience to users. +Create React App、Vite、Parcel などのビルドツールでこれらの要素をすべて自分で解決することも可能ですが、うまくやることは困難です。Create React App 自体がいくつかのビルドツールを統合したときのように、これらの機能をすべて統合してユーザに最高のエクスペリエンスを提供するためのツールが必要です。 -This category of tools that integrates build tools, rendering, routing, data fetching, and code splitting are known as "frameworks" -- or if you prefer to call React itself a framework, you might call them "metaframeworks". +ビルドツール、レンダー、ルーティング、データフェッチ、コード分割のすべてを統合する、というツールのカテゴリは「フレームワーク」として知られています。React 自体をフレームワークと呼ぶことを好む場合は、「メタフレームワーク」と呼ぶこともできるでしょう。 -Frameworks impose some opinions about structuring your app in order to provide a much better user experience, in the same way build tools impose some opinions to make tooling easier. This is why we started recommending frameworks like [Next.js](https://nextjs.org/), [React Router](https://reactrouter.com/), and [Expo](https://expo.dev/) for new projects. +ビルドツールにも多少の使い方に関する規約があるのと同様、フレームワークにもより良いユーザ体験を提供するためにどのようにアプリを構造化するのかについて、規約が存在します。これが、我々が [Next.js](https://nextjs.org/)、[React Router](https://reactrouter.com/)、[Expo](https://expo.dev/) などのフレームワークを新しいプロジェクトに推奨し始めた理由です。 -Frameworks provide the same getting started experience as Create React App, but also provide solutions to problems users need to solve anyway in real production apps. +フレームワークは Create React App と同様の始めやすさを提供しつつ、実際のプロダクションアプリで開発者がいずれにせよ解決する必要のある問題に対するソリューションも提供するのです。 -#### Server rendering is optional {/*server-rendering-is-optional*/} +#### サーバレンダーはオプションです {/*server-rendering-is-optional*/} -The frameworks we recommend all provide the option to create a [client-side rendered (CSR)](https://developer.mozilla.org/en-US/docs/Glossary/CSR) app. +私たちが推奨するフレームワークはすべて、[クライアントサイドレンダー (CSR)](https://developer.mozilla.org/en-US/docs/Glossary/CSR) によるアプリを作成するためのオプションを提供しています。 -In some cases, CSR is the right choice for a page, but many times it's not. Even if most of your app is client-side, there are often individual pages that could benefit from server rendering features like [static-site generation (SSG)](https://developer.mozilla.org/en-US/docs/Glossary/SSG) or [server-side rendering (SSR)](https://developer.mozilla.org/en-US/docs/Glossary/SSR), for example a Terms of Service page, or documentation. +あるページにとって CSR が正しい選択となることはありますが、多くの場合はそうではありません。アプリのほとんどがクライアントサイドという場合でも、[静的サイト生成 (SSG)](https://developer.mozilla.org/en-US/docs/Glossary/SSG) や [サーバサイドレンダリング (SSR)](https://developer.mozilla.org/en-US/docs/Glossary/SSR) などのサーバレンダー機能の恩恵を受けることができる個別ページはしばしば存在します。たとえば利用規約ページやドキュメントなどです。 -Server rendering generally sends less JavaScript to the client, and a full HTML document which produces a faster [First Contentful Paint (FCP)](https://web.dev/articles/fcp) by reducing [Total Blocking Time (TBD)](https://web.dev/articles/tbt), which can also lower [Interaction to Next Paint (INP)](https://web.dev/articles/inp). This is why the [Chrome team has encouraged](https://web.dev/articles/rendering-on-the-web) developers to consider static or server-side render over a full client-side approach to achieve the best possible performance. +サーバレンダーによりクライアントに送信される JavaScript を全体的に削減し、完全な HTML ドキュメントを生成することで、[First Contentful Paint (FCP)](https://web.dev/articles/fcp) を高速化し、[Total Blocking Time (TBD)](https://web.dev/articles/tbt) を削減し、またそれにより [Interaction to Next Paint (INP)](https://web.dev/articles/inp) を低下させることができます。これが、Chrome チームが開発者に静的またはサーバサイドレンダリングを[検討するよう促した](https://web.dev/articles/rendering-on-the-web)理由でもあります。 -There are tradeoffs to using a server, and it is not always the best option for every page. Generating pages on the server incurs additional cost and takes time to generate which can increase [Time to First Byte (TTFB)](https://web.dev/articles/ttfb). The best performing apps are able to pick the right rendering strategy on a per-page basis, based on the tradeoffs of each strategy. +サーバを使用することにはトレードオフがあり、すべてのページにとって常に最良の選択肢というわけではありません。サーバでページを生成することにより追加のコストと生成時間がかかるため、[Time to First Byte (TTFB)](https://web.dev/articles/ttfb) を増加させる可能性があります。最高のパフォーマンスのアプリでは、それぞれの戦略のトレードオフに基づいて、ページごとに適切なレンダー戦略を選択できます。 -Frameworks provide the option to use a server on any page if you want to, but do not force you to use a server. This allows you to pick the right rendering strategy for each page in your app. +フレームワークは、必要に応じて好きなページでサーバを使用するオプションを提供しますが、サーバの使用を強制するわけではありません。これにより、アプリ内の各ページごとに、適したレンダー戦略を選択できるようになっています。 -#### What About Server Components {/*server-components*/} +#### サーバコンポーネントについて {/*server-components*/} -The frameworks we recommend also include support for React Server Components. +私たちが推奨するフレームワークは、React Server Components のサポートも含んでいます。 -Server Components help solve these problems by moving routing and data fetching to the server, and allowing code splitting to be done for client components based on the data you render, instead of just the route rendered, and reducing the amount of JavaScript shipped for the best possible [loading sequence](https://www.patterns.dev/vanilla/loading-sequence). +サーバコンポーネントでは、ルーティングとデータフェッチをサーバ側に移動し、クライアントコンポーネントのコード分割を（レンダーするページ単位のみならず）レンダーするデータの種類に基づいて行うことで、これらの問題を解決します。送信される JavaScript の量を減らすことで、最適な[ローディングシーケンス](https://www.patterns.dev/vanilla/loading-sequence)を実現します。 -Server Components do not require a server. They can be run at build time on your CI server to create a static-site generated app (SSG) app, at runtime on a web server for a server-side rendered (SSR) app. +サーバコンポーネントはサーバを必要としません。ビルド時に CI サーバで実行して静的サイト生成 (SSG) アプリを作成するためにも使えますし、ランタイム時にウェブサーバで実行してサーバサイドレンダー (SSR) アプリを作成するためにも使えます。 -See [Introducing zero-bundle size React Server Components](/blog/2020/12/21/data-fetching-with-react-server-components) and [the docs](/reference/rsc/server-components) for more info. +詳細については、[バンドルサイズゼロの React サーバコンポーネントの紹介](/blog/2020/12/21/data-fetching-with-react-server-components) と [ドキュメント](/reference/rsc/server-components) を参照してください。 -#### Server Rendering is not just for SEO {/*server-rendering-is-not-just-for-seo*/} +#### サーバレンダーは SEO のためだけではない {/*server-rendering-is-not-just-for-seo*/} -A common misunderstanding is that server rendering is only for [SEO](https://developer.mozilla.org/en-US/docs/Glossary/SEO). +サーバレンダーは [SEO](https://developer.mozilla.org/en-US/docs/Glossary/SEO) のためだけにある、というのはよくある誤解です。 -While server rendering can improve SEO, it also improves performance by reducing the amount of JavaScript the user needs to download and parse before they can see the content on the screen. +サーバレンダーは SEO も改善しますが、ユーザが画面上のコンテンツを見るためにダウンロード・パースする必要のある JavaScript の量を減らすことで、パフォーマンスも向上させるものです。 -This is why the Chrome team [has encouraged](https://web.dev/articles/rendering-on-the-web) developers to consider static or server-side render over a full client-side approach to achieve the best possible performance. +これが、Chrome チームが開発者に対し、最高のパフォーマンスを達成するために、完全なクライアントサイドのアプローチではなく、静的ないしサーバサイドレンダリングを検討するよう[促している](https://web.dev/articles/rendering-on-the-web)理由です。 --- -_Thank you to [Dan Abramov](https://bsky.app/profile/danabra.mov) for creating Create React App, and [Joe Haddad](https://github.com/Timer), [Ian Schmitz](https://github.com/ianschmitz), [Brody McKee](https://github.com/mrmckeb), and [many others](https://github.com/facebook/create-react-app/graphs/contributors) for maintaining Create React App over the years. Thank you to [Brooks Lybrand](https://bsky.app/profile/brookslybrand.bsky.social), [Dan Abramov](https://bsky.app/profile/danabra.mov), [Devon Govett](https://bsky.app/profile/devongovett.bsky.social), [Eli White](https://x.com/Eli_White), [Jack Herrington](https://bsky.app/profile/jherr.dev), [Joe Savona](https://x.com/en_JS), [Lauren Tan](https://bsky.app/profile/no.lol), [Lee Robinson](https://x.com/leeerob), [Mark Erikson](https://bsky.app/profile/acemarke.dev), [Ryan Florence](https://x.com/ryanflorence), [Sophie Alpert](https://bsky.app/profile/sophiebits.com), [Tanner Linsley](https://bsky.app/profile/tannerlinsley.com), and [Theo Browne](https://x.com/theo) for reviewing and providing feedback on this post._ +_Create React App を作成した [Dan Abramov](https://bsky.app/profile/danabra.mov)、および Create React App を長年にわたりメンテナンスしてきた [Joe Haddad](https://github.com/Timer)、[Ian Schmitz](https://github.com/ianschmitz)、[Brody McKee](https://github.com/mrmckeb)、そして[他の多くの方々](https://github.com/facebook/create-react-app/graphs/contributors)に感謝します。この投稿をレビューし、フィードバックを提供していただいた [Brooks Lybrand](https://bsky.app/profile/brookslybrand.bsky.social)、[Dan Abramov](https://bsky.app/profile/danabra.mov)、[Devon Govett](https://bsky.app/profile/devongovett.bsky.social)、[Eli White](https://x.com/Eli_White)、[Jack Herrington](https://bsky.app/profile/jherr.dev)、[Joe Savona](https://x.com/en_JS)、[Lauren Tan](https://bsky.app/profile/no.lol)、[Lee Robinson](https://x.com/leeerob)、[Mark Erikson](https://bsky.app/profile/acemarke.dev)、[Ryan Florence](https://x.com/ryanflorence)、[Sophie Alpert](https://bsky.app/profile/sophiebits.com)、[Tanner Linsley](https://bsky.app/profile/tannerlinsley.com)、および [Theo Browne](https://x.com/theo) に感謝します。_ diff --git a/src/content/blog/index.md b/src/content/blog/index.md index 33e1c2bb5..c9fa12c7b 100644 --- a/src/content/blog/index.md +++ b/src/content/blog/index.md @@ -16,9 +16,9 @@ Bluesky の [@react.dev](https://bsky.app/profile/react.dev) や Twitter の [@r
- + -Today, we’re deprecating Create React App for new apps, and encouraging existing apps to migrate to a framework, or to migrate to a build tool like Vite, Parcel, or RSBuild. We’re also providing docs for when a framework isn’t a good fit for your project, you want to build your own framework, or you just want to learn how React works by building a React app from scratch ... +本日、新規アプリに対して Create React App を非推奨とし、既存のアプリにはフレームワークへの移行、または Vite、Parcel、RSBuild などのビルドツールへの移行を推奨します。また、フレームワークがプロジェクトに適していない場合や独自のフレームワークを構築したい場合、あるいは React がどのように動作するかを学ぶためにゼロから React アプリを構築したい場合のためのドキュメントも提供します。