-
Notifications
You must be signed in to change notification settings - Fork 7.7k
Updates from feedback #7624
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updates from feedback #7624
Changes from all commits
a6ba27d
18f7a7e
2aef7f7
3852170
f062f60
72f50c7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2,7 +2,7 @@ | |
title: "Sunsetting 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. We’re also providing docs for when a framework isn’t a good fit for your project, or you prefer to start by building a framework. | ||
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. | ||
--- | ||
|
||
February 14, 2025 by [Matt Carroll](https://twitter.com/mattcarrollcode) and [Ricky Hanlon](https://bsky.app/profile/ricky.fm) | ||
|
@@ -11,7 +11,9 @@ February 14, 2025 by [Matt Carroll](https://twitter.com/mattcarrollcode) and [Ri | |
|
||
<Intro> | ||
|
||
Today, we’re deprecating [Create React App](https://create-react-app.dev/) for new apps, and encouraging existing apps to migrate to a [framework](/learn/creating-a-react-app). We’re also providing docs for when a framework isn’t a good fit for your project, or you prefer to start by [building a framework](/learn/building-a-react-framework). | ||
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. | ||
|
||
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). | ||
|
||
</Intro> | ||
|
||
|
@@ -46,35 +48,44 @@ This error message will only be shown once per install. | |
</ConsoleLogLine> | ||
</ConsoleBlockMulti> | ||
|
||
We recommend [creating new React apps](/learn/creating-a-react-app) with a framework. All the frameworks we recommend support client-only SPAs, and can be deployed to a CDN or static hosting service without a server. | ||
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. | ||
|
||
## 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. | ||
|
||
For existing apps, these guides will help you migrate to a client-only 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/) | ||
|
||
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. | ||
## 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. | ||
|
||
To help users get started with Vite, Parcel or Rsbuild, we've published new docs for [Building a Framework](/learn/building-a-react-framework). Continue reading to learn more about the [limitations of Create React App](#limitations-of-create-react-app) and [why we recommend frameworks](#why-we-recommend-frameworks). | ||
For existing apps, these guides will help you migrate to a build tool: | ||
|
||
<Note> | ||
* [Vite Create React App migration guide](https://www.robinwieruch.de/vite-create-react-app/) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What's the best guide for migrating from CRA to Vite? (cc @yyx990803) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We can work on an official one and later send a PR. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks! To be honest, not having clear and official guides (and I hadn't actually tested these, like i have the framework guides) were the only reason I didn't include this section in the original draft, and just linked to our new docs. That clearly sent the wrong message, and I needed to add this quickly, so it would be nice to get more official guides. |
||
* [Parcel Create React App migration guide](https://stackoverflow.com/a/49605484) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What's the best guide for migrating from Parcel? (cc @devongovett) |
||
* [Rsbuild Create React App migration guide](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). | ||
|
||
#### Do you recommend Vite? {/*do-you-recommend-vite*/} | ||
<DeepDive> | ||
|
||
We provide several Vite-based recommendations. | ||
#### Do I need a framework? {/*do-i-need-a-framework*/} | ||
|
||
React Router v7 is a Vite based framework which allows you to use Vite's fast development server and build tooling with a framework that provides routing and data fetching. Just like the other frameworks we recommend, you can build a SPA with React Router v7. | ||
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. | ||
rickhanlonii marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
We also recommend using Vite when [adding React to an existing project](/learn/add-react-to-an-existing-project), or [building a framework](/learn/building-a-react-framework). | ||
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. | ||
|
||
Just like Svelte has Sveltekit, Vue has Nuxt, and Solid has SolidStart, React recommends using a framework that integrates with build tools like Vite for new projects. | ||
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. | ||
|
||
</Note> | ||
</DeepDive> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @ryansolid does this feel less "begrudging" and more in line with other library recommendations? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I was away for the weekend.. Only comment is "unusual constraints" still carries a tone of someone doing something wrong. But generally I think this will do it. It's tricky because there is a perceived history here, even if I don't think it's completely fair. Perceptions being as such makes the situation more delicate than would otherwise be merited. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, I can see how that has the wrong tone. The intent is to cover use cases like a VSCode plugin, chrome extension, or game which are (let's be real) uncommon and don't need URL routing integrated into data-fetching and will never need server features because they're not deployed to the web. But framed in a way where folks who are new won't mistakenly pattern match themselves into this category and go down the wrong path and get locked in to CSR only. Do you have suggestions on wording to clarify this and soften the tone? |
||
|
||
Continue reading to learn more about the [limitations of build tools](#limitations-of-create-react-app) and [why we recommend frameworks](#why-we-recommend-frameworks). | ||
|
||
## Limitations of Create React App {/*limitations-of-create-react-app*/} | ||
## 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. | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,143 @@ | ||
--- | ||
title: Build a React app from Scratch | ||
--- | ||
|
||
<Intro> | ||
|
||
If your app has constraints not well-served by existing frameworks, you prefer to build your own framework, or you just want to learn the basics of a React app, you can build a React app from scratch. | ||
|
||
</Intro> | ||
|
||
<DeepDive> | ||
|
||
#### Consider using a framework {/*consider-using-a-framework*/} | ||
|
||
Starting from scratch is an easy way to get started using React, but a major tradeoff to be aware of is that going this route is often the same as building your own adhoc framework. As your requirements evolve, you may need to solve more framework-like problems that our recommended frameworks already have well developed and supported solutions for. | ||
|
||
For example, if in the future your app needs support for server-side rendering (SSR), static site generation (SSG), and/or React Server Components (RSC), you will have to implement those on your own. Similarly, future React features that require integrating at the framework level will have to be implemented on your own if you want to use them. | ||
|
||
Our recommended frameworks also help you build better performing apps. For example, reducing or eliminating waterfalls from network requests makes for a better user experience. This might not be a high priority when you are building a toy project, but if your app gains users you may want to improve its performance. | ||
|
||
Going this route also makes it more difficult to get support, since the way you develop routing, data-fetching, and other features will be unique to your situation. You should only choose this option if you are comfortable tackling these problems on your own, or if you’re confident that you will never need these features. | ||
|
||
For a list of recommended frameworks, check out [Creating a React App](/learn/creating-a-react-app). | ||
|
||
</DeepDive> | ||
|
||
|
||
## Step 1: Install a build tool {/*step-1-install-a-build-tool*/} | ||
|
||
The first step is to install a build tool like `vite`, `parcel`, or `rsbuild`. These build tools provide features to package and run source code, provide a development server for local development and a build command to deploy your app to a production server. | ||
|
||
### Vite {/*vite*/} | ||
|
||
[Vite](https://vite.dev/) is a build tool that aims to provide a faster and leaner development experience for modern web projects. | ||
|
||
<TerminalBlock> | ||
{`npm create vite@latest my-app -- --template react`} | ||
</TerminalBlock> | ||
|
||
Vite is opinionated and comes with sensible defaults out of the box. Vite has a rich ecosystem of plugins to support fast refresh, JSX, Babel/SWC, and other common features. See Vite's [React plugin](https://vite.dev/plugins/#vitejs-plugin-react) or [React SWC plugin](https://vite.dev/plugins/#vitejs-plugin-react-swc) and [React SSR example project](https://vite.dev/guide/ssr.html#example-projects) to get started. | ||
|
||
Vite is already being used as a build tool in one of our [recommended frameworks](/learn/creating-a-react-app): [React Router](https://reactrouter.com/start/framework/installation). | ||
|
||
### Parcel {/*parcel*/} | ||
|
||
[Parcel](https://parceljs.org/) combines a great out-of-the-box development experience with a scalable architecture that can take your project from just getting started to massive production applications. | ||
|
||
<TerminalBlock> | ||
{`npm install --save-dev parcel`} | ||
</TerminalBlock> | ||
|
||
Parcel supports fast refresh, JSX, TypeScript, Flow, and styling out of the box. See [Parcel's React recipe](https://parceljs.org/recipes/react/#getting-started) to get started. | ||
|
||
### Rsbuild {/*rsbuild*/} | ||
|
||
[Rsbuild](https://rsbuild.dev/) is an Rspack-powered build tool that provides a seamless development experience for React applications. It comes with carefully tuned defaults and performance optimizations ready to use. | ||
|
||
<TerminalBlock> | ||
{`npx create-rsbuild --template react`} | ||
</TerminalBlock> | ||
|
||
Rsbuild includes built-in support for React features like fast refresh, JSX, TypeScript, and styling. See [Rsbuild's React guide](https://rsbuild.dev/guide/framework/react) to get started. | ||
|
||
<Note> | ||
|
||
#### Metro for React Native {/*react-native*/} | ||
|
||
If you'd you're starting from scratch with React Native you'll need to use [Metro](https://metrobundler.dev/), the JavaScript bundler for React Native. Metro supports bundling for platforms like iOS and Android, but lacks many features when compared to the tools here. We recommend starting with Vite, Parcel, or Rsbuild unless your project requires React Native support. | ||
|
||
</Note> | ||
|
||
### Step 2: Build Common Application Patterns {/*step-2-build-common-application-patterns*/} | ||
|
||
The build tools listed above start off with a client-only, single-page app (SPA), but don't include any further solutions for common functionality like routing, data fetching, or styling. | ||
|
||
The React ecosystem includes many tools for these problems. We've listed a few that are widely used as a starting point, but feel free to choose other tools if those work better for you. | ||
|
||
#### Routing {/*routing*/} | ||
|
||
Routing determines what content or pages to display when a user visits a particular URL. You need to set up a router to map URLs to different parts of your app. You'll also need to handle nested routes, route parameters, and query parameters. Routers can be configured within your code, or defined based on your component folder and file structures. | ||
|
||
Routers are a core part of modern applications, and are usually integrated with data fetching (including prefetching data for a whole page for faster loading), code splitting (to minimize client bundle sizes), and page rendering approaches (to decide how each page gets generated). | ||
|
||
We suggest using: | ||
|
||
- [React Router](https://reactrouter.com/start/framework/custom) | ||
- [Tanstack Router](https://tanstack.com/router/latest) | ||
|
||
|
||
#### Data Fetching {/*data-fetching*/} | ||
|
||
Fetching data from a server or other data source is a key part of most applications. Doing this properly requires handling loading states, error states, and caching the fetched data, which can be complex. | ||
|
||
Purpose-built data fetching libraries do the hard work of fetching and caching the data for you, letting you focus on what data your app needs and how to display it. These libraries are typically used directly in your components, but can also be integrated into routing loaders for faster pre-fetching and better performance, and in server rendering as well. | ||
|
||
Note that fetching data directly in components can lead to slower loading times due to network request waterfalls, so we recommend prefetching data in router loaders or on the server as much as possible! This allows a page's data to be fetched all at once as the page is being displayed. | ||
|
||
If you're fetching data from most backends or REST-style APIs, we suggest using: | ||
|
||
- [React Query](https://react-query.tanstack.com/) | ||
- [SWR](https://swr.vercel.app/) | ||
- [RTK Query](https://redux-toolkit.js.org/rtk-query/overview) | ||
|
||
If you're fetching data from a GraphQL API, we suggest using: | ||
|
||
- [Apollo](https://www.apollographql.com/docs/react) | ||
- [Relay](https://relay.dev/) | ||
|
||
|
||
### Code-splitting {/*code-splitting*/} | ||
|
||
Code-splitting is the process of breaking your app into smaller bundles that can be loaded on demand. An app's code size increases with every new feature and additional dependency. Apps can become slow to load because all of the code for the entire app needs to be sent before it can be used. Caching, reducing features/dependencies, and moving some code to run on the server can help mitigate slow loading but are incomplete solutions that can sacrifice functionality if overused. | ||
|
||
Similarly, if you rely on the apps using your framework to split the code, you might encounter situations where loading becomes slower than if no code splitting were happening at all. For example, [lazily loading](/reference/react/lazy) a chart delays sending the code needed to render the chart, splitting the chart code from the rest of the app. [Parcel supports code splitting with React.lazy](https://parceljs.org/recipes/react/#code-splitting). However, if the chart loads its data *after* it has been initially rendered you are now waiting twice. This is a waterfall: rather than fetching the data for the chart and sending the code to render it simultaneously, you must wait for each step to complete one after the other. | ||
|
||
Splitting code by route, when integrated with bundling and data fetching, can reduce the initial load time of your app and the time it takes for the largest visible content of the app to render ([Largest Contentful Paint](https://web.dev/articles/lcp)). | ||
|
||
For code-splitting instructions, see your build tool docs: | ||
- [Vite build optimizations](https://v3.vitejs.dev/guide/features.html#build-optimizations) | ||
- [Parcel code splitting](https://parceljs.org/features/code-splitting/) | ||
- [Rsbuild code splitting](https://rsbuild.dev/guide/optimization/code-splitting) | ||
|
||
### Improving Application Performance {/*improving-application-performance*/} | ||
|
||
Since the build tool you select only support single page apps (SPAs) you'll need to implement other [rendering patterns](https://www.patterns.dev/vanilla/rendering-patterns) like server-side rendering (SSR), static site generation (SSG), and/or React Server Components (RSC). Even if you don't need these features at first, in the future there may be some routes that would benefit SSR, SSG or RSC. | ||
|
||
* **Single-page apps (SPA)** load a single HTML page and dynamically updates the page as the user interacts with the app. SPAs are easier to get started with, but they can have slower initial load times. SPAs are the default architecture for most build tools. | ||
|
||
* **Streaming Server-side rendering (SSR)** renders a page on the server and sends the fully rendered page to the client. SSR can improve performance, but it can be more complex to set up and maintain than a single-page app. With the addition of streaming, SSR can be very complex to set up and maintain. See [Vite's SSR guide]( https://vite.dev/guide/ssr). | ||
|
||
* **Static site generation (SSG)** generates static HTML files for your app at build time. SSG can improve performance, but it can be more complex to set up and maintain than server-side rendering. | ||
|
||
* **React Server Components (RSC)** lets you mix build-time, server-only, and interactive components in a single React tree. RSC can improve performance, but it currently requires deep expertise to set up and maintain. See [Parcel's RSC examples](https://github.com/parcel-bundler/rsc-examples). | ||
|
||
Your rendering strategies need to integrate with your router so apps built with your framework can choose the rendering strategy on a per-route level. This will enable different rendering strategies without having to rewrite your whole app. For example, the landing page for your app might benefit from being statically generated (SSG), while a page with a content feed might perform best with server-side rendering. | ||
|
||
Using the right rendering strategy for the right routes can decrease the time it takes for the first byte of content to be loaded ([Time to First Byte](https://web.dev/articles/ttfb)), the first piece of content to render ([First Contentful Paint](https://web.dev/articles/fcp)), and the largest visible content of the app to render ([Largest Contentful Paint](https://web.dev/articles/lcp)). | ||
|
||
### And more... {/*and-more*/} | ||
|
||
These are just a few examples of the features a new app will need to consider when building from scratch. Many limitations you'll hit can be difficult to solve as each problem is interconnected with the others and can require deep expertise in problem areas you may not be familiar with. | ||
|
||
If you don't want to solve these problems on your own, you can [get started with a framework](/learn/creating-a-react-app) that provides these features out of the box. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Saw this PR a bit late but I want to point out the "unusual constraints" phrasing here is among those that makes users who find Vite + React just fine feel that their preference is being invalidated - when in fact there are massive amount of users falling into this category.
As evidence, here's a chart comparing number of plain Vite + React users (calculated from total of the two official Vite React plugins minus Remix) vs. Next - the numbers are quite close and we expect this to overtake Next at some point.
Another point I want to make is this section is talking about "Migration" - a term that mostly applies to existing applications. Most existing CRA apps likely already have their routing / data fetching implemented in some way (e.g. with older versions of React Router). Moving to something like Vite is the most proven and safe path to adopt modern tooling, without the risk of having to refactor their (currently working) routing and data fetching logic. I really wouldn't call this "unusual constraints" - rather, this is probably the most practical constraints: replace something deprecated with something that is actively maintained, improve the DX, while minimizing the migration cost / risk.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I appreciate the feedback. Maybe there's some tweaking we can do to the language here. This specific sentence is just copy pasted from the intro of Build a React App from Scratch. Here we're just trying to explain that you can migrate to a build tool if you want. In the deep dive it says:
The goal isn't to invalidate preferences, because the goal isn't to document preferences at all. The goal is to encourage users to use a setup that will allow them to build the best user experience possible, which means allowing them to integrate data fetching into routing easily, and to opt in to server features if they want instead of getting locked into a network-waterfall prone bloated CSR bundle that requires a lot of work to fix later (fwiw, this isn't a critique of Vite, since solving these problems are for frameworks and not a build tool).
As for the migration pain - you can use all of the same routing you're already using in the migration guides we provided. Both the Next guide and the React Router guide explain the steps to migrate using your existing routing and you can incrementally migrate to the file based routing. I don't think it's fair to developers to frame that as less safe, or more work. There are plenty of stories of pain points migrating from Create React App to Vite (as well as successes).
Also, if we're going to compare usage, we should also include React Router (not just Remix), which has almost as many downloads as Next and Vite React combined. This is important context because it shows that most Vite users immediately install React Router. So most Vite apps are already using React Router (the library), and can choose React Router (the framework) to continue using Vite: