recently, t3dotgg, a foreign netizen, suggested that React officially use Create React App to create a new project instead of in the document . It is recommended to use Vite to create a new project . Most netizens agree with this:
React's new official document is about to be released (99% is now complete). However, Create React App is still recommended in the Beta version of the official document to create a new project. Two additional alternatives are provided: Vite , Parcel .
looking at Create React App's Github repository, we can see that it has not been updated for 5 months, accumulating 1500 + issues .
on January 31, Dan Abramov, a core member of the React team, responded to this suggestion, explaining the tradeoffs made by React team members and providing some options. Let's take a look at the details (you can skip to the final conclusion)!
Evolution of Create React App
when Create React App was released in 2016, the environment of the tool was decentralized. If you want to add React to an existing application, you need to add a & lt;script> tag or import from npm, and then adjust the existing build tool configuration. However, if you want to create a new application built only using React from scratch, there is no clear way to do this.
before Create React App, you must install a bunch of tools and connect them together, provide correct presets to use JSX, make different configurations for development and production environments, provide correct settings for resource caching, configure linter, etc., which is very difficult to do correctly. People solve this problem by creating and sharing "template" repositories that can be cloned. However, this creates another problem: once the cloned template file is adjusted in the project, it is difficult to pull the template update. In this way, the settings of the project will become old, either abandoning the update or putting a lot of effort into getting all the tools to work together again. In fast-growing ecosystems, this is very difficult.
Create React App solves this problem by combining several tools in one package. Now, if you want to start a new project with React, there is a clear recommended method (Create React App) to do this! Then, at regular intervals, you can update the package to get updates for all the underlying tools. This model has become so popular that many tools work in this way today. Vite is indeed one of the best tools with a similar vision and takes it a step further in some ways.
The goal of
Create React App is to * * provide most React users with the best way to launch new React Web applications, and * * it supports a selection of features that work together. Over time, the out-of-the-box "baseline" it provides will expand as we find the right trade-off. For example, a mask layer has been added for run-time errors, support for different style options has been added, and a quick refresh has been added by default, which allows you to save the component's code and view changes without losing state. This is a huge milestone for the default React development experience. In general, because Create React App has complete control over the compilation pipeline, it is easy to add compilation-related functionality.
having such a well-planned setting is still of great value to the ecosystem. When React Hooks appears, the React team adds React Hooks lint rules to the default settings. In addition, Create React App allows React teams to deploy important tool changes (quick refresh support, React Hooks lint rules) to the widest possible audience. Without the popular templates planned by the React team, it would be difficult to roll out these tool changes so widely.
problems with Create React App
over time, Create React App stagnates. Many people point out that it is slower than alternatives and does not support some of the popular tools that people want to use today. In principle, the React team can solve these problems. For example, you can update the interior of Create React App to use faster bundler, or even use Vite internally. Or you can advise people to migrate from Create React App to applications like Vite. However, the React team also wants to solve a deeper problem.
by design, Create React App generates a pure client application. This means that each application created with it contains an empty HTML file, a & lt;script> tag with React, and an application package. When an empty HTML file is loaded, the browser waits for the React code and all the application packages to download. This may take some time on a low-bandwidth connection, and the user does not see anything on the screen at this time. Then, load the application code. At this point, the user will see something on the screen-- but usually the data needs to be loaded. So the code sends a request to load the data, and the user needs to wait for it to return. Finally, the data is loaded, the component renders the data again, and the user sees the final result.
this is very inefficient, although it's hard to do better if you only run React on the client side. Compare it with a server-side framework such as Rails: the server immediately starts the data fetch and then generates a page containing all the data. In this case, the user will see a HTML file containing all the information instead of a blank file waiting for the script to be loaded. HTML is the cornerstone of Web-so why does creating a React application result in an empty HTML file? Why not take advantage of the most basic function of Web-the ability to quickly view content before all interactive code is loaded? Why wait until all client code has been loaded before starting to load data?
Create React App solves only one aspect of the problem, it provides a good development experience, but it does not impose enough structure to help us take advantage of the power of Web to get a good user experience. Developers can try to solve these problems on their own, but this goes against the purpose of Create React App. Every truly efficient React setting is custom, different, and cannot be implemented by Create React App.
these user experience issues are not specific to Create React App. They are not even specific to React. For example, applications created from the Vite home page templates of Preact, Vue, Lit, and Svelte all encounter the same problem. These problems are inherent in pure client applications without static site generation (SSG) or server-side rendering (SSR).
the rise of React framework
some people may not like to build entirely using React. For example, HTML pages can be generated on the server side or during the build process using different tools, such as Jekyll or Astro. This solves the problem of empty HTML files, but you must mix the two rendering techniques. Over time, the more interactivity you want to add, the more obvious the fragmentation of this technology will become.
this fragmentation not only harms the developer's experience-- it also affects the user experience. With tools that are truly HTML-centric and do not take full advantage of React, each page navigation becomes a full page reload, clearing all client states. Today, many users want to navigate smoothly within the app, rather than reloading the entire page in the style of the 1990s. Similarly, many developers prefer to use a single rendering model rather than mixing two different models to build their applications. Developers want to use React to build the whole application.
if you use React to build the entire application, it is important to be able to use SSG/SSR. Lack of support for them in Create React App. In addition, after years of ecosystem innovation, many other problems of React now have mature solutions. For example, network waterfalls and bundle sizes.
even if the application does not benefit from SSG or SSR as content-oriented sites do, it may be affected by the web waterfall. If you get data at mount time, the first data acquisition will not even begin until all the code is loaded and the components are rendered. This is a waterfall: if the application knows how to start fetching data while the code is still loaded, it can do in parallel. In navigation, if both the parent and child components need to get something, an even worse waterfall will result. When we talk about React performance, we can't avoid the fact that waterfall is a performance bottleneck for so many applications. To solve these waterfall, you need to integrate data acquisition and routing, and Create React App cannot do this.
our application code grows with each new feature and additional dependency added. If deployed frequently, the application may become very slow to load each time it is used, because it always needs to load all the code. There are several ways to solve this problem; you can move some code to run on the server side or during build (if the tool allows). Ideally, you can also split the code by route. However, if you try to split the code manually, it will usually make the performance worse. To solve this problem, you need to combine data acquisition with routing and packaging, which Create React App cannot do.
React itself is just a library. It does not specify how routing or data acquisition is used. Neither did Create React App. Unfortunately, this means that neither React nor the original design of Create React App can solve these problems. Server rendering is associated with static generation, data acquisition, packaging, and routing. When Create React App was released, React was very new, and there was still a lot to figure out how to make these features work independently, let alone how to put them together perfectly.
The
era is evolving, and it is becoming more and more difficult to recommend solutions that do not have access to these features. Even if they are not used immediately, they should be available when needed, and they can be utilized without having to migrate to different templates and rebuild all the code. Similarly, not all data acquisition or code splitting needs to be routing-based. But this is a good default setting and should apply to most React applications.
although you can integrate all these functions on your own, it's hard to be good. Just as Create React App itself integrates several compilation-related functions, tools such as Next.js, Gatsby, and Remix go one step further-- integrating compilation and rendering, routing, and data acquisition. Such tools that integrate compilation, rendering, routing, and data acquisition are called "frameworks" (or "meta-frameworks" if you like to call React frameworks). These frameworks provide a better user experience.
React as an architecture
We like the flexibility of React, which can be used to build a single button or an entire application using React. You can use it to build dashboards in 20-year-old Perl sites, or you can use React to create mixed SSG/SSR e-commerce sites. This flexibility is essential, and users love it.
The
React team also wants to provide better default settings for new applications built entirely using React. It would be great if the default recommended method for creating React applications supports SSG and SSR, automatic code splitting, routing preloading, navigation that preserves client-side UI state, and other features that provide an excellent user experience. At the very least, the default recommended way to create React applications should not be completely excluded from these features, as the existing client-only architecture does not implement these features.
React faces a challenge, and the best way to help the React framework provide a great user experience is to focus on the bottom of React. React itself can do some unique things in the rendering layer, which greatly improve the capabilities of the framework in other layers. For example, like & lt;Suspense> , a React API can unlock a series of framework optimizations for the framework behind the scenes.
React is a library that provides some API that allows you to define and combine components. React is also an architecture that provides building blocks that allow framework authors to take full advantage of their rendered models. We can use React without a framework. But you need to make sure that if you use it with the framework, the framework can take full advantage of React. Many of the features built over the past few years ( & lt;Suspense> , useTransition , streaming API (such as renderToPipeableStream , and experimental server-side components) are framework-oriented. They let the framework take full advantage of React by integrating packaging, routing, and data acquisition.
as you can see, some of these features are used in Next 13, Gatsby 5, and Remix 1.11. There is still a lot of work to be done, some of which is coming to an end from the experimental phase. Nevertheless, the React team is pleased to see that years of hard work has paid off and enabled the React framework (and its users) to release faster applications.
one library, multiple frames
the React ecosystem is more suitable for data acquisition solutions and routing solutions with many and many competitions. These choices get better every year. There are also a variety of solutions that integrate routing, data acquisition, rendering, and compilation-- multiple React frameworks.
We want to maintain this state and, where possible, encourage integration and benefit the React ecosystem. For example, different frameworks may use different mechanisms to load data. However, if they all use & lt;Suspense> as the load indicator, then the higher-level functionality in & lt;Suspense> will apply to all frameworks.
if the best way for most React applications to start with is to start with a framework, which framework should we recommend? Should we choose one? How do we decide which one to choose? What if it stagnates over time? This leads to the problems mentioned above.
what should we do with Create React App?
the original goal of Create React App is:
- provides an easy way to start a new React project without configuration;
- integrate compilation-related dependencies for easy upgrade;
- lets the React team deploy tool updates (such as quick refresh support, Hooks lint rules) as widely as possible.
however, it no longer meets its original goal of being the best way to create React applications. By raising standards and integrating compilation with rendering, routing, and data acquisition, the framework allows users to create React applications:
- make full use of Web API to provide fast applications and websites by default, regardless of size;
- make full use of React and its framework-level features;
- provides routing and data acquisition.
The
React ecosystem is worth recommending a default approach that can take full advantage of Web and React itself. This doesn't even mean that you have to rely on the Node.js server. Many popular frameworks do not require a server and can work in SSG mode, so they can also address "completely static" use cases. The advantage of the framework is that if you need SSR in the future, you don't need to migrate, and it works right out of the box like other features (for example, Remix provides mutation API out of the box).
so how to achieve this vision? You have the following choices:
option 1: create a new framework from scratch
you can try to redesign the Create React App architecture into a framework that integrates data acquisition, routing, packaging, and SSG/SSR. Building a high-quality new framework is a daunting task that requires a great deal of ecosystem expertise, and even if other projects are stopped to achieve this goal, there is a significant risk of stagnation over time, just like Create React App. It also further splits the ecosystem, even though there are no real users. Therefore, it is considered that this option is not practical at present.
option 2: deprecate Create React App and maintain a Vite template
you can discard Create React App and maintain your own Vite templates. In order to achieve this goal, the template must be very complex. In fact, it must be as complex as the React framework-- and it needs to integrate routing, data acquisition, and so on. This leads to the same problem: you are actually creating another framework.
option 3: discard Create React App and recommend using React framework
you can no longer emphasize or oppose Create React App as a tool, but more actively emphasize the React framework. This does not mean that you have to use one of the React frameworks, but it is recommended that you use one of them in most applications. The downside is that this will affect the React brand ("Why not recommend creating React applications?" ).
option 4: let Create React App use a single framework
you can select a specified frame and change the Create React App to create an application using that frame by default. The main problem with this approach is that it makes it difficult for other solutions to compete-especially when their tradeoffs are slightly different, but are roughly the same in popularity, feature set, and quality. This change in behavior is also destructive because all old tutorials are interrupted in an inconspicuous way.
option 5: turn Create React App into an initiator
you can leave Create React App as a command, but turn it into an initiator. It will suggest a list of recommended frameworks, followed by a "classic" frameless approach. The "classic" approach will produce a client-side dedicated application like CRA now (to avoid disrupting existing tutorials), but Vite may end up being used internally.
to enter the list of selected frames, the React framework must meet certain criteria. You need to consider the popularity and adoption rate of the community (to keep the list short), the feature set, the performance characteristics, the ability to take full advantage of the Web platform and React itself, whether it is actively maintained, and whether it is clear how to host it in various managed services and environments. The entry templates for each framework will be maintained by the React team to ensure that they have a consistent design and brand, are not linked to business services, and are structurally similar. How these choices are made needs to be clearly communicated to the community and will be reassessed on a regular basis.
suggestions from the React team
The
React team currently prefers option 5 ("turn Create React App into an initiator") . The original goal of Create React App is to provide most React users with the best way to launch new React web applications. Repurpose it, and the initiator clearly conveys the transformation that we think is best suited for most new Web applications. Unlike option 3, it avoids the idea that "creating an React application" is somewhat abandoned.
The
React team will develop more detailed RFC proposals to enrich these points. At the same time, I would like to hear more feedback on these issues.
what do you think of * * replacing Create React App,** with Vite? Welcome to share ~
in the comments area.
reference: github.com/reactjs/rea...
Comments