大家好，我是 CUGGZ。

最近，網(wǎng)友 t3dotgg 建議把 React 官方文檔中關(guān)于建議使用 Create React App 來創(chuàng)建新項(xiàng)目更換為建議使用 Vite 來創(chuàng)建新項(xiàng)目。該建議引起了網(wǎng)友的熱議，多數(shù)網(wǎng)友對此表示贊同：

新的 React 官方文檔發(fā)布在即（目前顯示已完成 99%），Beta 版文檔中仍然推薦使用 Create React App 創(chuàng)建新項(xiàng)目。另外提供了兩個(gè)備選方案：Vite、Parcel。

查看 Create React App 的 Github 倉庫可以發(fā)現(xiàn)，其已經(jīng) 5 個(gè)月沒有更新了，積累了 1500+ 個(gè) issues。

1 月 31 日，React 團(tuán)隊(duì)核心成員 Dan Abramov 對此建議進(jìn)行了回復(fù)，解釋了 React 團(tuán)隊(duì)成員對此建議的權(quán)衡并提供了一些選項(xiàng)，下面就來看看詳細(xì)內(nèi)容吧（可以跳到最后看結(jié)論）！

Create React App 的演變

在 2016 年發(fā)布 Create React App 時(shí)，工具的環(huán)境是分散的。如果想要將 React 添加到現(xiàn)有應(yīng)用，需要添加一個(gè) <script> 標(biāo)簽或從 npm 中導(dǎo)入，然后調(diào)整現(xiàn)有的構(gòu)建工具配置。但是，如果要從頭開始創(chuàng)建一個(gè)僅使用 React 構(gòu)建的新應(yīng)用，則沒有明確的方法可以做到這一點(diǎn)。

在 Create React App 之前，必須安裝一堆工具并將它們連接在一起，提供正確的預(yù)設(shè)以使用 JSX，為開發(fā)和生產(chǎn)環(huán)境進(jìn)行不同的配置，為資源緩存提供正確的設(shè)置，配置 linter 等，想要正確完成這一系列工作非常困難。人們通過創(chuàng)建和共享可以克隆的“樣板”存儲庫來解決了這個(gè)問題。然而，這產(chǎn)生了另外一個(gè)問題：一旦在項(xiàng)目中調(diào)整了克隆的樣板文件，就很難再拉取樣板的更新。這樣，項(xiàng)目的設(shè)置會變得舊，要么放棄更新，要么花費(fèi)大量精力讓所有工具再次協(xié)同工作。在快速發(fā)展的生態(tài)系統(tǒng)中，這非常困難。

Create React App 通過將多個(gè)工具組合在一個(gè)包中解決了這個(gè)問題?，F(xiàn)在，如果想用 React 開始一個(gè)新項(xiàng)目，有一個(gè)明確的推薦方法（Create React App）可以做到這一點(diǎn)！然后，每隔一段時(shí)間，可以更新這個(gè)包，以獲得所有底層工具的更新。這種模型變得很流行，以至于今天有很多工具都以這種方式工作。Vite 確實(shí)是擁有相似愿景的最佳工具之一，并且在在某些方面更進(jìn)一步。

Create React App 的目標(biāo)是為大多數(shù) React 用戶提供啟動(dòng)新 React Web 應(yīng)用的最佳方式，它支持一組協(xié)同工作的精選功能。隨著時(shí)間的推移，它提供的開箱即用的“baseline”會隨著我們找到正確的權(quán)衡而擴(kuò)大。例如，為運(yùn)行時(shí)錯(cuò)誤添加了一個(gè)遮罩層，添加了對不同樣式選項(xiàng)的支持，默認(rèn)添加了快速刷新，它允許保存組件的代碼并查看更改而不會丟失狀態(tài)。對于默認(rèn)的 React 開發(fā)體驗(yàn)來說，這是一個(gè)巨大的里程碑?？偟膩碚f，由于 Create React App 完全控制了編譯管道，因此添加編譯相關(guān)的功能是很容易的。

有這樣一個(gè)精心策劃的設(shè)置對生態(tài)系統(tǒng)仍然很有價(jià)值。當(dāng) React Hooks 出現(xiàn)時(shí)，React 團(tuán)隊(duì)將 React Hooks lint 規(guī)則添加到默認(rèn)設(shè)置中。除此之外，Create React App 還允許 React 團(tuán)隊(duì)向盡可能廣泛的受眾部署重要的工具更改（快速刷新支持、React Hooks lint 規(guī)則）。如果沒有 React 團(tuán)隊(duì)策劃的流行模板，將很難如此廣泛地推出這些工具更改。

Create React App 的問題

隨著時(shí)間的推移，Create React App 停滯不前。許多人指出它比替代品慢，并且不支持人們?nèi)缃裣胍褂玫囊恍┝餍泄ぞ?。原則上，React 團(tuán)隊(duì)可以解決這些問題。例如，可以更新Create React App 內(nèi)部，以使用更快的 bundler，甚至在內(nèi)部使用 Vite。或者可以建議人們從 Create React App 遷移到 Vite 這樣的應(yīng)用。然而，React 團(tuán)隊(duì)還想解決一個(gè)更深層次的問題。

按照設(shè)計(jì)，Create React App 會生成一個(gè)純客戶端應(yīng)用。這意味著用它創(chuàng)建的每個(gè)應(yīng)用都包含一個(gè)空的 HTML 文件、一個(gè)帶有 React 的 <script> 標(biāo)簽和應(yīng)用包。當(dāng)加載空的 HTML 文件時(shí)，瀏覽器會等待 React 代碼和全部應(yīng)用包下載。這在低帶寬連接上可能需要一段時(shí)間，并且此時(shí)用戶在屏幕上看不到任何內(nèi)容。然后，加載應(yīng)用代碼。此時(shí)用戶會在屏幕上看到一些內(nèi)容——但通常還需要加載數(shù)據(jù)。所以代碼發(fā)送了加載數(shù)據(jù)的請求，用戶需要等待它返回。最后，數(shù)據(jù)加載，組件重新渲染數(shù)據(jù)，用戶看到最終結(jié)果。

這是非常低效的，盡管如果只在客戶端運(yùn)行 React 很難做得更好。將其與 Rails 這樣的服務(wù)端框架進(jìn)行對比：服務(wù)端將立即啟動(dòng)數(shù)據(jù)獲取，然后生成包含所有數(shù)據(jù)的頁面。在這種情況下，用戶會看到包含所有信息的 HTML 文件，而不是等待加載腳本的空白文件。HTML 是Web 的基石——那么為什么創(chuàng)建React 應(yīng)用會產(chǎn)生一個(gè)空的 HTML 文件？為什么不利用 Web 最基本的功能——在所有交互代碼加載之前快速查看內(nèi)容的能力？為什么要等到所有客戶端代碼加載完成后才開始加載數(shù)據(jù)？

Create React App 只解決了問題的一方面，它提供了良好的開發(fā)體驗(yàn)，但它沒有強(qiáng)加足夠的結(jié)構(gòu)來幫助我們利用 Web 的強(qiáng)大功能獲得良好的用戶體驗(yàn)。開發(fā)者可以嘗試自己解決這些問題，但這違背了 Create React App 的宗旨。每個(gè)真正高效的 React 設(shè)置都是自定義的、不同的，并且是 Create React App 無法實(shí)現(xiàn)的。

這些用戶體驗(yàn)問題并不是 Create React App 特有的。它們甚至不特定于 React。例如，從 Preact、Vue、Lit 和 Svelte 的 Vite 主頁模板創(chuàng)建的應(yīng)用都會遇到相同的問題。這些問題是沒有靜態(tài)站點(diǎn)生成 (SSG) 或服務(wù)端渲染 (SSR) 的純客戶端應(yīng)用所固有的。

React 框架的興起

有些人可能不喜歡完全使用 React 進(jìn)行構(gòu)建。例如，可以在服務(wù)端或在構(gòu)建過程中使用不同的工具（如 Jekyll 或 Astro）生成 HTML 頁面。這解決了空 HTML 文件的問題，但是必須混合使用兩種渲染現(xiàn)技術(shù)。隨著時(shí)間的推移，想要添加的交互性越多，這種技術(shù)割裂就越明顯。

這種割裂不僅會損害開發(fā)人員的體驗(yàn)——用戶體驗(yàn)也會受到影響。使用真正以 HTML 為中心且未充分利用 React 的工具，每個(gè)頁面導(dǎo)航都會變成完整的頁面重新加載，從而清除了所有客戶端狀態(tài)。如今，許多用戶希望在應(yīng)用內(nèi)導(dǎo)航順暢，而不是 90 年代風(fēng)格的整頁重新加載。同樣，許多開發(fā)人員更喜歡使用單一的渲染模型而不是混合兩種不同的模型來構(gòu)建他們的應(yīng)用。開發(fā)者想用 React 構(gòu)建整個(gè)應(yīng)用。

如果使用 React 構(gòu)建整個(gè)應(yīng)用，那么能夠使用 SSG/SSR 很重要。在 Create React App 中缺乏對它們的支持。除此之外，經(jīng)過多年的生態(tài)系統(tǒng)創(chuàng)新，React 的許多其他問題現(xiàn)在都有了成熟的解決方案。例如，network waterfalls 和 bundle 大小。

即使應(yīng)用沒有像面向內(nèi)容的網(wǎng)站那樣從 SSG 或 SSR 中獲益，它也可能會受到網(wǎng)絡(luò)瀑布的影響。如果在掛載時(shí)獲取數(shù)據(jù)，則在加載所有代碼并渲染組件之前，第一次數(shù)據(jù)獲取甚至不會開始。這是一個(gè) waterfall：如果應(yīng)用知道如何在代碼仍在加載時(shí)開始獲取數(shù)據(jù)，那么就可以并行完成。在導(dǎo)航中，如果父組件和子組件都需要獲取某些內(nèi)容，則會產(chǎn)生更糟糕的 waterfall。當(dāng)我們談?wù)?React 性能時(shí)，無法回避一個(gè)事實(shí)：對于如此多的應(yīng)用來說，waterfall 是性能的瓶頸。要解決這些 waterfall，需要將數(shù)據(jù)獲取與路由集成起來，而Create React App 無法做到這一點(diǎn)。

我們的應(yīng)用代碼會隨著添加的每個(gè)新功能和額外依賴項(xiàng)而不斷增長。如果經(jīng)常部署，應(yīng)用在每次使用時(shí)加載速度可能會變得非常慢，因?yàn)樗偸切枰虞d所有代碼。有幾種方法可以解決這個(gè)問題；可以移動(dòng)一些代碼以在服務(wù)端或在構(gòu)建期間運(yùn)行（如果工具允許）。理想情況下，還可以按路由拆分代碼。然而，如果嘗試手動(dòng)進(jìn)行代碼拆分，通常會使性能更差。要解決這一問題，需要將數(shù)據(jù)獲取與路由和打包相結(jié)合，而 Create React App 無法做到這一點(diǎn)。

React 本身只是一個(gè)庫，它不規(guī)定如何使用路由或數(shù)據(jù)獲取，Create React App 也沒有。不幸的是，這意味著單靠 React 和最初設(shè)計(jì)的 Create React App 都無法解決這些問題。服務(wù)端渲染和靜態(tài)生成、數(shù)據(jù)獲取、打包和路由都是相關(guān)聯(lián)的。當(dāng) Create React App 發(fā)布時(shí)，React 還很新，如何讓這些功能獨(dú)立工作都還有很多東西需要弄清楚，更不用說如何完美地將它們組合在一起了。

時(shí)代在發(fā)展，現(xiàn)在，越來越難以推薦無法獲得這些功能的解決方案。即使不立即使用它們，它們也應(yīng)該在需要時(shí)可用，并且不必遷移到不同的模板并重新構(gòu)建所有代碼即可利用它們。同樣，并非所有數(shù)據(jù)獲取或代碼拆分都需要基于路由。但這是一個(gè)很好的默認(rèn)設(shè)置，應(yīng)該適用于大多數(shù) React 應(yīng)用。

雖然可以自己整合所有這些功能，但很難好。就像 Create React App 本身集成了與編譯相關(guān)的幾個(gè)功能一樣，Next.js、Gatsby 和 Remix 等工具跟進(jìn)一步——將編譯與渲染、路由和數(shù)據(jù)獲取集成在一起。這類集編譯、渲染、路由和數(shù)據(jù)獲取于一體的工具被稱為“框架”（或者，如果喜歡稱 React 為框架的話，可以稱它們?yōu)椤霸蚣堋保?。這些框架提供了更好的用戶體驗(yàn)。

React 作為一個(gè)架構(gòu)

我們喜歡 React 的靈活性，可以使用 React 構(gòu)建單個(gè)按鈕，也可以使用它構(gòu)建整個(gè)應(yīng)用?？梢允褂盟谝延?20 年歷史的 Perl 網(wǎng)站中構(gòu)建儀表板，或者可以使用 React 制作混合 SSG/SSR 的電子商務(wù)網(wǎng)站。這種靈活性是必不可少的，用戶也很喜歡它。

React 團(tuán)隊(duì)也希望為完全使用 React 構(gòu)建的新應(yīng)用提供更好的默認(rèn)設(shè)置。如果默認(rèn)建議的創(chuàng)建 React 應(yīng)用的方法支持 SSG 和 SSR、自動(dòng)代碼拆分、路由預(yù)加載、保留客戶端 UI 狀態(tài)的導(dǎo)航以及其他可實(shí)現(xiàn)出色用戶體驗(yàn)的功能，就太好了。至少，創(chuàng)建 React 應(yīng)用的默認(rèn)建議方式不應(yīng)該完全被排除在這些功能之外，因?yàn)楝F(xiàn)有的僅客戶端架構(gòu)沒有實(shí)現(xiàn)這些功能。

React 面臨著挑戰(zhàn)，幫助 React 框架提供出色用戶體驗(yàn)的最佳方式就是專注于 React 的底層。React 本身可以在渲染層做一些獨(dú)特的事情，這些事情大大提高了框架在其他層的能力。例如，與<Suspense>一樣，一個(gè) React API 可以在幕后為框架解鎖一系列框架優(yōu)化。

React 是一個(gè)庫，它提供了一些 API，可讓定義和組合組件。React 也是一種架構(gòu)，它提供了讓框架作者充分利用其渲染模型的構(gòu)建塊。我們可以在沒有框架的情況下使用 React。但需要確保，如果將它與框架一起使用，框架能夠充分利用 React。在過去幾年中構(gòu)建的許多功能（<Suspense>、useTransition?、流式 API（如 renderToPipeableStream 和實(shí)驗(yàn)性的服務(wù)端組件）都是面向框架的。它們讓框架通過集成打包、路由和數(shù)據(jù)獲取來充分利用 React。

可以看到，Next 13、Gatsby 5 和 Remix 1.11 中采用了其中一些功能。還有很多工作要做，其中一些工作正在從實(shí)驗(yàn)階段結(jié)束。盡管如此，React 團(tuán)隊(duì)還是很高興看到多年的努力得到了回報(bào)，并使 React 框架（及其用戶）能夠發(fā)布更快的應(yīng)用。

一個(gè)庫，多個(gè)框架

React 生態(tài)系統(tǒng)更適合擁有眾多競爭，有多種競爭的數(shù)據(jù)獲取解決方案和路由解決方案。這些選擇每年都會變得更好。也有多種集成路由、數(shù)據(jù)獲取、渲染和編譯的解決方案——即多個(gè) React 框架。

我們希望保持這種狀態(tài)，也希望在可能的情況下鼓勵(lì)融合并使 React 生態(tài)系統(tǒng)從中受益。例如，不同的框架可能使用不同的機(jī)制來加載數(shù)據(jù)。但是，如果它們都采用 <Suspense>? 作為加載指示器，那么在 <Suspense> 中的更高級別的功能將適用于所有框架。

如果大多數(shù) React 應(yīng)用的最佳方式是從一個(gè)框架開始，那我們應(yīng)該建議使用哪個(gè)框架？我們應(yīng)該選擇一個(gè)嗎？我們?nèi)绾螞Q定選擇哪一個(gè)？如果它隨著時(shí)間的推移停滯不前怎么辦？這就引出了上面提到的問題。

我們應(yīng)該用 Create React App 做什么？

Create React App 最初的目標(biāo)是：

• 提供一種無需配置即可啟動(dòng)新 React 項(xiàng)目的簡單方法；
• 集成編譯相關(guān)依賴，方便升級；
• 讓 React 團(tuán)隊(duì)盡可能廣泛地部署工具更新（例如快速刷新支持、Hooks lint 規(guī)則）。

然而，它不再滿足最初的目標(biāo)，即成為創(chuàng)建 React 應(yīng)用的最佳方式。通過提高標(biāo)準(zhǔn)并將編譯與渲染、路由和數(shù)據(jù)獲取相集成，框架可以讓用戶創(chuàng)建 React 應(yīng)用時(shí)：

• 充分利用 Web API 來默認(rèn)提供快速的應(yīng)用和網(wǎng)站，無論大小；
• 充分利用 React 及其框架級功能；
• 提供路由和數(shù)據(jù)獲取。

React 生態(tài)系統(tǒng)值得推薦一種默認(rèn)的方法，它可以充分利用 Web 和 React 本身。這甚至并不意味著一定要依賴于 Node.js 服務(wù)器。許多流行的框架不需要服務(wù)器并且可以在 SSG 模式下工作，因此它們也可以解決“完全靜態(tài)”的用例?？蚣艿暮锰幘褪?，如果以后需要 SSR，不需要進(jìn)行遷移，它和其他功能一樣開箱即用（例如，Remix 提供了開箱即用的 mutation API）。

那該如何實(shí)現(xiàn)這一愿景？有以下選擇：

選項(xiàng) 1：從頭開始創(chuàng)建一個(gè)新框架

可以嘗試將 Create React App 重新設(shè)計(jì)架構(gòu)成為一個(gè)集成數(shù)據(jù)獲取、路由、打包和 SSG/SSR 的框架。構(gòu)建一個(gè)高質(zhì)量的新框架是一項(xiàng)艱巨的任務(wù)，需要大量的生態(tài)系統(tǒng)專業(yè)知識，即使停止其他項(xiàng)目來實(shí)現(xiàn)這一目標(biāo)，也會存在著隨著時(shí)間的推移出現(xiàn)停滯不前的重大風(fēng)險(xiǎn)，就像 Create React App 一樣。它還會進(jìn)一步分裂生態(tài)系統(tǒng)，盡管沒有真正的用戶。所以認(rèn)為這個(gè)選項(xiàng)目前不實(shí)用。

選項(xiàng) 2：棄用 Create React App，維護(hù)一個(gè)Vite模板

可以棄用 Create React App，維護(hù)自己的 Vite 模板。為了實(shí)現(xiàn)這個(gè)目標(biāo)，該模板必須非常復(fù)雜。事實(shí)上，它必須像 React 框架一樣復(fù)雜——并且需要集成路由、數(shù)據(jù)獲取等功能。這導(dǎo)致了同樣的問題：實(shí)際上是在創(chuàng)建另一個(gè)框架。

選項(xiàng) 3：棄用 Create React App，建議使用 React 框架

可以不再強(qiáng)調(diào)或反對將 Create React App 作為工具，而是更積極地強(qiáng)調(diào) React 框架。這并不意味著必須使用其中一個(gè)React框架，但建議在大多數(shù)應(yīng)用中使用其中一個(gè)框架。不利的一面就是，這將影響 React 的品牌（“為什么不推薦創(chuàng)建 React 應(yīng)用？”）。

選項(xiàng) 4：讓 Create React App 使用單一框架

可以選擇一個(gè)指定框架，并更改 Create React App 以默認(rèn)使用該框架創(chuàng)建應(yīng)用。這種方法的主要問題是它使其他解決方案很難競爭——尤其是當(dāng)它們的權(quán)衡略有不同，但在流行度、功能集和質(zhì)量方面大致相同時(shí)。這種行為上的改變也是具有破壞性的，因?yàn)樗械呐f教程都會以一種不明顯的方式中斷。

選項(xiàng) 5：將 Create React App 變成啟動(dòng)器

可以將 Create React App 保留為命令，但將其變成啟動(dòng)器。它將建議一個(gè)推薦框架列表，然后是“經(jīng)典”無框架方法。“經(jīng)典”方法將產(chǎn)生一個(gè)像 CRA 現(xiàn)在這樣的客戶端專用應(yīng)用（以避免破壞已有教程），但內(nèi)部最終可能會使用 Vite。

要想進(jìn)入精選框架列表，React 框架必須滿足特定條件。需要考慮社區(qū)的流行度和采用率（以保持列表簡短）、功能集、性能特征、充分利用 Web 平臺和 React 本身的能力、它是否得到積極維護(hù)以及是否清楚如何在各種托管服務(wù)和環(huán)境中托管它。每個(gè)框架的入門模板將由 React 團(tuán)隊(duì)維護(hù)，以確保它們具有一致的設(shè)計(jì)和品牌，不鏈接到商業(yè)服務(wù)，并且結(jié)構(gòu)相似。需要向社區(qū)清楚地傳達(dá)是如何做出這些選擇的，并且會定期重新評估它們。

React 團(tuán)隊(duì)的建議

React 團(tuán)隊(duì)目前傾向于選項(xiàng) 5（“將 Create React App 變成啟動(dòng)器”）。Create React App 的最初目標(biāo)是為大多數(shù) React 用戶提供啟動(dòng)新的 React web 應(yīng)用的最佳方式。重新調(diào)整它的用途，啟動(dòng)器明確傳達(dá)了我們認(rèn)為最適合大多數(shù)新 Web 應(yīng)用的轉(zhuǎn)變。與選項(xiàng) 3 不同，它避免了“創(chuàng)建一個(gè) React 應(yīng)用”在某種程度上被棄用的看法。

React 團(tuán)隊(duì)將制定更詳細(xì)的 RFC 提案，以充實(shí)這些要點(diǎn)。同時(shí)，希望聽到對這些問題的更多反饋。

對于使用 Vite 替換 Create React App，你有什么看法？歡迎在評論區(qū)分享~

參考：https://github.com/reactjs/reactjs.org/pull/5487#issuecomment-1409720741