In the documentation, the preferred way Reactto build a new application is (create-react-app).ReactCRA

CRAIt was launched in 2016. At that time, there were no systematic Reactscaffolding tools for everyone to use. In addition, it was an official tool and it was very popular as soon as it was launched. As of now, CRAthe warehouse has harvested nearly 100,000 yuan star.

However, over time, many excellent alternatives have emerged, such as parcelthe viteprovided Reacttemplates.

However, CRAits progress is slowing down, and its last submission dates back to September 8 last year:

In addition, CRAthe support for some popular tools is not very good. For example, TailwindCSSit is not recommended in the documentation CRA:

Recently, Theo , a front-end Internet celebrity with 100,000 YouTube fans, Reactlaunched a PR in the document warehouse , calling on Reactdocuments to no longer be recommended by default CRA, but should be used Viteas the first choice for building applications.

Judging by the number of onlookers, you can see how concerned everyone is about this sensitive issue:

So, Reacthow does the team view this issue? Will they Vitemake it their first choice when building apps?

This article will talk about Dan ( Reactcore member)’s views on this issue.

Welcome to join the human high-quality front-end exchange group and lead flying

CRA’s positioning

Since it is the target of public criticism CRA, first we need to understand its positioning CRAunder Reactthe system, and then see Viteif we can replace the former under this positioning.

CRAThe period of its birth (2016) was SPAthe hottest period (single-page applications). At that time, he solved two pain points very well:

0Configuration initialization project

This does not need to be introduced too much. A CSR(client-side rendering) Reactproject can be generated by executing the following command:

npx create-react-app project name

Integrated tool chain

CRAEncapsulate some of the engineering best practices at the time under react-scriptsthe package and smooth out the incompatibilities of these tools.

Developers enjoy out-of-the-box best practices and don’t have to worry about the impact of certain tool upgrades on the project ( CRAit will be dealt with).

Later, many excellent scaffolding tools (such as Vite, Parcel) also followed this out-of-the-box concept.

In addition to the above two points, with CRAthe popularity of , Reactthe team will also use it as a rapid distribution channel for new features, such as:

• Fast Refresh(For Reacthot updates, component status will not be lost)
• HookslintA series of rules after the launch

Relying on CRAthe huge installed capacity and usage, these integrated CRAfeatures can be quickly deployed into developers’ projects to quickly increase penetration.

Just imagine, without CRAthe promotion, it would be difficult for Hooksthe lintrules to have such a high popularity among developers, and Hooksthe concept would not sweep the entire front-end framework field so quickly.

From the above three points, Viteit can become CRAa substitute with better performance.

But Reactthe team’s considerations go beyond that.

Disadvantages of scaffolding tools

Although CRAit can be used out of the box, the capabilities it provides are not comprehensive. For example, it does not provide:

• State management solution
• Routing plan
• Data request plan

Why not provide it? Because during CRAthe development period, these solutions have not yet formed best practices.

Over time, developers gradually figured out best practices for solving these problems. For example, in the request waterfall problem, consider the following components:

function  App () {
   const [data, update] = useState ( null );
   useEffect ( () => {
     fetch ( 'http://...' ). then ( res =>  update (res. json ()))
  }, [])
  
  return  < Child  data = {data}/ > 
}

Data can only Appbe requested after the component is rendered. This request timing is relatively lagging. If Childyou rely dataon requesting your own data, the request will also be lagging due Appto the lagging of the request . This is the request waterfall problem.Child

A common solution to this problem is to converge the logic of requesting data into the routing scheme.

For another example, as the business continues to iterate, the size of the business code is getting larger and larger, and a common optimization method is lazy loading of components.

However, manually performing lazy loading often creates unexpected problems. For example, there is a chart component on the page <Chart/>. If the developer loads this component lazily, but the component on mountrequests data at the same time, it will fall into the request waterfall problem.

To completely solve this problem, three types of technical solutions are needed:

• Data request solution (solve data flow problem)
• Routing scheme (solve the problem of data request timing)
• Packaging solution (solve the implementation problem of lazy loading)

There are many similar problems, such as CSRthe slow rendering speed of the first screen (which needs to SSRbe solved).

It can be seen that CRAit only provides CSRan out-of-the-box template for the environment, but as the project becomes more and more complex, some business details CRAdo not provide out-of-the-box solutions.

From this perspective, Viteyou will still face the same problem even if you switch to .

A new era framework

As the best practices for various common problems are explored, some frameworks based on Reactthem , such as Next.js.Remix

Among them, Remixit is React-Routera full-stack framework that is gradually developed based on (routing solution) and includes routing, data request, and rendering.

So, can it be CRAiterated into a full-stack framework like this to solve the lack of various best practices once and for Next.jsall ?RemixCRA

ReactThe team believes that doing so requires extremely high development costs, and as the times evolve, there will always be more CRAunsupported best practices (just like the problem he is currently facing), which CRAwill one day be eliminated again.

Therefore, this solution is not advisable.

Since this solution is undesirable, the Vitereplacement CRAsolution is also undesirable. Because simple use Vitedoes not solve the lack of best practices, and those best practices must be implemented on this basis (such as routing, data requests…), then it is back to developing a full-stack framework .

In the end, Reactthe team prefers the following solution: it will be used CRAas a scaffolding tool. After startup, it will recommend different frameworks according to the user’s different scenario needs (such as yes SSRor no ), and then it will be used as a fallback solution when the framework is not used .CSRCRA

Moreover, in terms of implementation, it is possible to webpackswitch to Vite.

Summarize

From Reactthe team’s thinking, we can find that Reactit has always positioned itself as a state-driven UI library.

With the development of the times, using this library alone can no longer meet daily development needs. Frameworks that use React + to implement various best practice patterns based on the bottom layer will become more and more popular.

Recently, Next.jsit reached the 100,000 starachievement and became the 14th ranked warehouse Githubin China , indirectly confirming this trend.star

Back to the opening question: Reactwhy not Viterecommend it as the default?

If the packaging tool is used Viteinstead webpackof CRAAS, it may be possible in the future. However, this is not the primary issue.