為什么是Vite2
在Vite2官網(wǎng)文檔中，有這么一段話：
然而，當(dāng)我們開始構(gòu)建越來越大型的應(yīng)用時(shí)，需要處理的 JavaScript 代碼量也呈指數(shù)級增長。大型項(xiàng)目包含數(shù)千個(gè)模塊的情況并不少見。我們開始遇到性能瓶頸 —— 使用 JavaScript 開發(fā)的工具通常需要很長時(shí)間（甚至是幾分鐘！）才能啟動開發(fā)服務(wù)器，即使使用 HMR，文件修改后的效果也需要幾秒鐘才能在瀏覽器中反映出來。如此循環(huán)往復(fù)，遲鈍的反饋會極大地影響開發(fā)者的開發(fā)效率和幸福感。
這就是為什么是Vite2的原因。
與webpack 比較
Webpack的HMR
第一次冷啟動慢的原因：
在之前的瀏覽器中沒有模塊化的設(shè)計(jì)，所以期望把所有源代碼編譯進(jìn)一個(gè) js 文件中提供給瀏覽器使用，所以在開發(fā)中當(dāng)我們運(yùn)行啟動命令的時(shí)候，webpack 總是需要從入口文件去索引整個(gè)項(xiàng)目的文件，編譯成一個(gè)或多個(gè)單獨(dú)的 js 文件，即使采用了代碼拆分，也需要一次生成所有路由下的編譯后文件（這也是為什么代碼拆分對開發(fā)模式性能沒有幫助）。這也導(dǎo)致了服務(wù)啟動時(shí)間隨著項(xiàng)目復(fù)雜度而指數(shù)增長。
webpack-dev-server的熱更新：
與本地服務(wù)器建立「socket」連接，注冊 hash 和 ok 兩個(gè)事件，發(fā)生文件修改時(shí)，給客戶端推送 hash 事件?？蛻舳烁鶕?jù) hash 事件中返回的參數(shù)來拉取更新后的文件。
HotModuleReplacementPlugin 會在文件修改后，生成兩個(gè)文件，用于被客戶端拉取使用。
在熱更新上反映的就是部分代碼變更， 整個(gè)模塊的代碼都需要重新編譯，然后在推送更新。
Vite2的HMR
Vite 是基于 native ES module —— 瀏覽器廠商的不懈努力，現(xiàn)代瀏覽器基本已經(jīng)全部支持了import/export 語法了。
在Vite中，啟動服務(wù)器時(shí)，是不需要提交編譯文件，而是在瀏覽器請求對應(yīng)URL時(shí)，再提供文件，實(shí)施了真正的路由懶加載，這個(gè)比起Webpack就要節(jié)省了不少時(shí)間。
而在工程中不是所有的引用模塊都是ES寫法，可能是CommonJS 和 UMD 、AMD 等等，
這個(gè)時(shí)候Vite 會進(jìn)行預(yù)構(gòu)建，將其轉(zhuǎn)換為ESM模塊，以支持Vite。
并且將有許多內(nèi)部模塊的ESM依賴轉(zhuǎn)換為單個(gè)模塊，以提高后續(xù)頁面加載性能。
對于JSX、或者TS 等需要編譯的文件，Vite是用esbuild來進(jìn)行編譯的，不同與Webpack的整體編譯，Vite是在瀏覽器請求時(shí)，才對文件進(jìn)行編譯，然后提供給瀏覽器。因?yàn)閑sbuild編譯夠快，這種每次頁面加載都進(jìn)行編譯的其實(shí)是不會影響加速速度的。
esbuild
- 使用 Go 編寫，并且編譯成了機(jī)器碼
- 大量使用并行算法
- esbuild 的所有內(nèi)容都是從零編寫的,避免了不要的數(shù)據(jù)轉(zhuǎn)換
- 更有效利用內(nèi)存
