大家好，我卡頌。

在React文檔中，對于構(gòu)建新的React應(yīng)用，首推的方式是CRA（create-react-app）。

CRA推出于2016年，彼時還沒有成體系的React腳手架工具供大家使用，再加上這是官方工具，一經(jīng)推出就受到了歡迎。截止當(dāng)前，CRA倉庫已經(jīng)收獲快10wstar。

但是，隨著時間的推移，出現(xiàn)了很多優(yōu)秀的替代品，比如parcel、vite提供的React模版。

而CRA本身的進(jìn)步速度卻在放緩，其上一次提交要追溯到去年9月8日：

此外，CRA對一些流行工具的支持也不是很好，比如在TailwindCSS文檔中就不推薦使用CRA：

近日，油管10w粉絲的前端網(wǎng)紅「Theo」就在React?文檔倉庫發(fā)起了一個PR[1]，號召React?文檔不要再默認(rèn)推薦CRA?，而是應(yīng)該將Vite作為構(gòu)建應(yīng)用的首選。

看這圍觀群眾的數(shù)量就知道大家對這種敏感問題有多關(guān)心了：

那么，React?團(tuán)隊是如何看待這個問題的呢？他們會將Vite作為構(gòu)建應(yīng)用的首選項么？

本文來聊聊「Dan」（React核心成員）對這一問題的看法。

CRA的定位

既然眾矢之的是CRA，那么首先我們需要明白CRA在React體系下的定位，再來看看Vite能否在這個定位下取代前者。

CRA誕生的時期（2016年），是SPA（單頁應(yīng)用）最火熱的時期。在當(dāng)時，他很好的解決了兩個痛點(diǎn)：

0配置初始化項目

這點(diǎn)不用過多介紹，執(zhí)行如下命令后就能生成一個CSR（客戶端渲染）的React項目：

npx create-react-app 項目名

集成工具鏈

CRA?將當(dāng)時的一些工程化最佳實踐都封裝在react-scripts包下，并抹平這些工具不兼容的地方。

開發(fā)者既享受了開箱即用的最佳實踐，又不用擔(dān)心某些工具升級后對項目造成的影響（CRA會處理）。

后來的很多優(yōu)秀腳手架工具（比如Vite?、Parcel），也都沿用了這種「開箱即用」的理念。

除了以上兩點(diǎn)，隨著CRA?的走紅，React團(tuán)隊還將他作為新特性的快速分發(fā)渠道，比如：

• Fast Refresh?（針對React的熱更新，不會丟失組件狀態(tài)）
• Hooks?推出后的一系列l(wèi)int規(guī)則

依托CRA?龐大的裝機(jī)量與使用量，這些集成到CRA的特性可以快速部署到開發(fā)者的項目中，達(dá)到快速提高普及率的目的。

試想，如果沒有CRA?的推動，Hooks?的lint?規(guī)則很難在開發(fā)者中有這么高普及率，Hooks的理念也就不會這么快席卷整個前端框架領(lǐng)域。

從以上三點(diǎn)來看，Vite?完全可以成為比CRA性能更優(yōu)的替代品。

但是，React團(tuán)隊的考量不僅如此。

腳手架工具的不足

雖然CRA開箱即用，但他提供的能力并不全面，比如他并不提供：

• 狀態(tài)管理方案
• 路由方案
• 數(shù)據(jù)請求方案

為什么不提供呢？因為在CRA發(fā)展的時期，這些方案還未形成最佳實踐。

隨著時間發(fā)展，開發(fā)者逐漸摸索出解決這些問題的最佳實踐。比如請求瀑布問題，考慮如下組件：

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

只有當(dāng)App組件渲染后才能開始請求數(shù)據(jù)，這個請求時機(jī)是比較滯后的，如果Child依賴data來請求自己的數(shù)據(jù)，那么由于App請求的滯后導(dǎo)致Child的請求也滯后了，這就是請求瀑布問題。

這個問題常見的解決方法是 —— 將請求數(shù)據(jù)的邏輯收斂到路由方案中。

再比如，隨著業(yè)務(wù)不斷迭代，業(yè)務(wù)代碼體積越來越大，常見的優(yōu)化手段是懶加載組件。

但是，手動執(zhí)行懶加載常常會產(chǎn)生意料之外的問題。比如，頁面中有個圖表組件<Chart/>，如果開發(fā)者懶加載了這個組件，但是該組件在on mount時請求數(shù)據(jù)，這又會陷入請求瀑布問題。

要徹底解決這個問題，需要配合3類技術(shù)方案：

• 數(shù)據(jù)請求方案（解決數(shù)據(jù)流向問題）
• 路由方案（解決數(shù)據(jù)請求時機(jī)問題）
• 打包方案（解決懶加載的實現(xiàn)問題）

類似的問題還有很多，比如CSR首屏渲染速度慢的問題（需要通過SSR解決）。

可見，CRA僅僅提供了CSR環(huán)境下一個開箱即用的模版，但是隨著項目變得越來越復(fù)雜，一些業(yè)務(wù)細(xì)節(jié)問題CRA是沒有提供開箱即用的解決方案的。

從這個角度看，即使切換到Vite還是會面臨同樣的問題。

新時代的框架

隨著各種常見問題的最佳實踐被探索出來，逐漸誕生了一些以React?為基礎(chǔ)，集成各種業(yè)務(wù)問題最佳實踐的框架，比如Next.js、Remix。

其中，Remix?就是以React-Router（路由解決方案）為基礎(chǔ)，逐漸發(fā)展出來的囊括路由、數(shù)據(jù)請求、渲染為一體的全?？蚣?。

那么，能否將CRA?迭代為類似Next.js?、Remix?這樣的全?？蚣埽粍谟酪萁鉀QCRA對各種最佳實踐的缺失呢？

React?團(tuán)隊認(rèn)為，這樣做需要極高的開發(fā)成本，而且隨著時代發(fā)展，總會出現(xiàn)更多CRA?不支持的最佳實踐（就像他當(dāng)前面臨的問題一樣），那么CRA終有一天會被再度淘汰。

所以，這個方案不可取。

既然這個方案不可取，那么用Vite?取代CRA?的方案也不可取。因為單純使用Vite并沒有解決最佳實踐的缺失，必須在此基礎(chǔ)上實現(xiàn)那些最佳實踐（比如路由、數(shù)據(jù)請求...），那又回到了「開發(fā)一個全?？蚣堋?。

最終，React?團(tuán)隊更傾向如下解決方案：將CRA?作為一個腳手架工具，啟動后會根據(jù)用戶的不同場景需要（比如是SSR?還是CSR?）推薦不同的框架，再將CRA作為「不使用框架情況下的兜底方案」。

并且，在實現(xiàn)上，可能將兜底方案中的webpack?切換為Vite。

總結(jié)

從React?團(tuán)隊的思考可以發(fā)現(xiàn)，React始終將自己定位為一個「狀態(tài)驅(qū)動UI」的庫。

隨著時代的發(fā)展，單獨(dú)使用這個庫已經(jīng)不能滿足日常開發(fā)需要，基于「底層使用React」 + 「實現(xiàn)各種最佳實踐」模式的框架會越來越流行。

最近，Next.js?達(dá)到了10wstar?成就，成為Github?中star排名第14的倉庫，間接印證了這種趨勢。

回到開篇的問題：React?為什么不將Vite作為默認(rèn)推薦？

如果是用Vite?取代webpack?作為CRA的打包工具，未來可能會。但是，這不是最首要的問題。

如何協(xié)助上層的框架更好的服務(wù)開發(fā)者，才是React團(tuán)隊首要考慮的問題。

React不死，他只會逐漸移居幕后。

參考資料

[1]PR:https://github.com/reactjs/reactjs.org/pull/5487