大家好，我卡頌。

弋陽網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)！從網(wǎng)頁設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)公司等網(wǎng)站項(xiàng)目制作，到程序開發(fā)，運(yùn)營維護(hù)。創(chuàng)新互聯(lián)公司2013年成立到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)。

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

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

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

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

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

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

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

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

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

CRA的定位

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

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

0配置初始化項(xiàng)目

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

npx create-react-app 項(xiàng)目名

集成工具鏈

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

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

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

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

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

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

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

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

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

腳手架工具的不足

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

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

為什么不提供呢？因?yàn)樵贑RA發(fā)展的時(shí)期，這些方案還未形成最佳實(shí)踐。

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

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

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

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

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

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

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

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

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

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

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

新時(shí)代的框架

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

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

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

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

所以，這個(gè)方案不可取。

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

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

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

總結(jié)

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

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

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

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

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

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

React不死，他只會(huì)逐漸移居幕后。

參考資料

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

網(wǎng)頁名稱：React為什么不將Vite作為默認(rèn)推薦？
分享路徑：http://uogjgqi.cn/article/djsgpdg.html