React 爲什麼不將 Vite 作爲默認推薦？

大家好，我卡頌。

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

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

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

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

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

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

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

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

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

CRA 的定位

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

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

0 配置初始化項目

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

npx create-react-app 項目名

集成工具鏈

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

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

後來的很多優秀腳手架工具（比如Vite、Parcel），也都沿用了這種**「開箱即用」**的理念。

除了以上兩點，隨着CRA的走紅，React團隊還將他作爲新特性的快速分發渠道，比如：

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

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

從以上三點來看，Vite完全可以成爲比CRA性能更優的替代品。

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

腳手架工具的不足

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

爲什麼不提供呢？因爲在CRA發展的時期，這些方案還未形成最佳實踐。

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

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

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

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

再比如，隨着業務不斷迭代，業務代碼體積越來越大，常見的優化手段是懶加載組件。

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

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

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

可見，CRA僅僅提供了CSR環境下一個開箱即用的模版，但是隨着項目變得越來越複雜，一些業務細節問題CRA是沒有提供開箱即用的解決方案的。

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

新時代的框架

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

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

那麼，能否將CRA迭代爲類似Next.js、Remix這樣的全棧框架，一勞永逸解決CRA對各種最佳實踐的缺失呢？

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

所以，這個方案不可取。

既然這個方案不可取，那麼用Vite取代CRA的方案也不可取。因爲單純使用Vite並沒有解決最佳實踐的缺失，必須在此基礎上實現那些最佳實踐（比如路由、數據請求...），那又回到了 「開發一個全棧框架」。

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

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

總結

從React團隊的思考可以發現，React始終將自己定位爲一個 「狀態驅動 UI」 的庫。

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

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

回到開篇的問題：React爲什麼不將Vite作爲默認推薦？

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

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

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

參考資料

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

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/CEvWtJAsRDBo0XTkSHbTdw

猜你喜歡