穿越小说完本,欢乐颂第二季

新聞中心

這里有您想知道的互聯網營銷解決方案

React為什么不將Vite作為默認推薦？

大家好，我卡頌。

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

在React文檔中，對于構建新的React應用，首推的方式是CRA（create-react-app）。

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

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

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

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

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

看這圍觀群眾的數量就知道大家對這種敏感問題有多關心了：

那么，React?團隊是如何看待這個問題的呢？他們會將Vite作為構建應用的選擇項么？

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

CRA的定位

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

CRA誕生的時期（2016年），是SPA（單頁應用）最火熱的時期。在當時，他很好的解決了兩個痛點：

0配置初始化項目

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

npx create-react-app 項目名

集成工具鏈

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

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

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

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

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

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

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

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

但是，React團隊的考量不僅如此。

腳手架工具的不足

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

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

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

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

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

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

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

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

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

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

數據請求方案（解決數據流向問題）
路由方案（解決數據請求時機問題）
打包方案（解決懶加載的實現問題）

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

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

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

新時代的框架

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

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

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

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

所以，這個方案不可取。

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

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

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

總結

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

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

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

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

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

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

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

參考資料

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

文章名稱：React為什么不將Vite作為默認推薦？
本文鏈接：http://m.fisionsoft.com.cn/article/djsgpdg.html