作者：範文傑

來源：SegmentFault 思否社區

一、Vite 是什麼

=================

2020 年 4 月，尤大大發了這麼一個推：

隨後，2021 年 2 月，Vite 2.0 它來了，上來就是一套組合拳：

• 基於 esbuild 實現的極速開發體驗

• 多框架支持

• 兼容 Rollup 的插件機制與 API

• SSR 支持

• 舊瀏覽器支持

一開始我是拒絕的，從 grunt、gulp ，到 Webpack、Rollup、Snowpack 以及若干知名不知名構建框架，都 2021 了，還來？然後試用了一下，嗯，是真的香！

二、Vite 的優勢

2.1 真 TM 快

Vite 非常非常快，對比 Vue-cli(基於 Webpack)：

示例代碼：Vue3 項目，10 個組件

測試兩者的 dev 命令運行耗時相差十倍，且理論上，項目越大性能差距越大，爲什麼呢？最大的原因是 Vite 在開發模式下並沒有做太多打包操作！

Webpack 啓動後會做一堆事情，經歷一條很長的編譯打包鏈條，從入口開始需要逐步經歷語法解析、依賴收集、代碼轉譯、打包合併、代碼優化，最終將高版本的、離散的源碼編譯打包成低版本、高兼容性的產物代碼，這可滿滿都是 CPU、IO 操作啊，在 Node 運行時下性能必然是有問題。

而 Vite 運行 Dev 命令後只做了兩件事情，一是啓動了一個用於承載資源服務的 service；二是使用 esbuild 預構建 npm 依賴包。之後就一直躺着，直到瀏覽器以 http 方式發來 ESM 規範的模塊請求時，Vite 纔開始 “按需編譯” 被請求的模塊。

這裏 Vite 預設的前提是：

• 現代瀏覽器大多數已經原生支持 ESM 規範，構建工具 —— 特別是開發環境下已經沒有太大必要爲了低版本兼容把大量的時間花在編譯打包上了！

這麼一對比，Webpack 是啥都做了，瀏覽器只要運行編譯好的低版本 (es5) 代碼就行；而 Vite 只處理問題的一部分，剩下的事情交由瀏覽器自行處理，那速度必然賊 TM 快。

除了啓動階段跳過編譯操作之外，Vite 還有很多值得一提的性能優化，整體梳理一下：

• 預編譯：npm 包這類基本不會變化的模塊，使用 Esbuild 在 預構建 階段先打包整理好，減少 http 請求數

• 按需編譯：用戶代碼這一類頻繁變動的模塊，直到被使用時纔會執行編譯操作

• 客戶端強緩存：請求過的模塊會被以 http 頭 max-age=31536000,immutable 設置爲強緩存，如果模塊發生變化則用附加的版本 query 使其失效

• 產物優化：相比於 Webpack ，Vite 直接錨定高版本瀏覽器，不需要在 build 產物中插入過多運行時與模板代碼

• 內置更好的分包實現：不需要用戶干預，默認啓用一系列智能分包規則，儘可能減少模塊的重複打包

• 更好的靜態資源處理：Vite 儘量避免直接處理靜態資源，而是選擇遵循 ESM 方式提供服務，例如引入圖片 import img from 'xxx.png' 語句，執行後 img 變量只是一個路徑字符串。

可以看出，Vite 的快是全方位的，從 Dev 到 Build，從 npm 包到項目源碼，再到靜態資源處理都在 ESM 規則框架下儘可能地實現各種優化措施，理論性能急劇提升。

2.2 簡單

Vite 的用法很簡單， 執行初始化命令：

yarn create @vitejs/app my-vue-app --template vue

就得到了一個預設好的開發環境，可以開始愉快地寫 demo 了，Vite 開箱就給你一堆功能，包括 css 預處理器、html 預處理器、hash 命名、異步加載、分包、壓縮、HMR 等：

這些功能，作者都按行業最佳實踐預設好了，通常不需要用戶介入做變更。

Vite 的表現很容易讓人聯想到 vue-cli，不過兩者區別還是挺大的：vue-cli 底層依賴 Webpack，實際的構建工作通常由各種 Webpack loader、plugin 實現，比如 less => css 由 less-loader 實現；圖片加載由 img-loader 實現等。這套設計很靈活，你可以在 Webpack 體系下做任何你能想到的變更，只需要學習一點點 Webpack 的知識，包括百來個配置項、成千上萬的插件、若干虛無縹緲的構建概念等。

而 Vite 顯得特別簡潔，它只是暴露了極少數的配置項與 plugin 接口，設計上就沒打算讓你做太多自定義操作。。。這是因爲 Vite 從一開始就沒打算做成另一個 Webpack，而是做成一套 “能夠顯著提升前端開發體驗的前端構建工具”，重在 開發體驗 啊同學們，Vite 可謂是用心良苦，想盡辦法降低學習入門成本，它就不希望你爲了使用工具又學一大堆複雜、縹緲的概念，希望這些事情都在框架層面屏蔽了 —— 雖然代價是喪失靈活性。

簡單說吧，Vite 定位就是傻瓜式但強大的構建工具，你專心寫好業務代碼，早點下班，不用再爲了工具費神費力了。

2.3 生態

除了極致的運行性能與簡易的使用方法外，Vite 對已有生態的兼容性也不容忽略，主要體現在兩個點：

• 與 Vue 解耦，兼容支持 React、Svelte、Preact、Vanilla 等，這意味着 Vite 可以被應用在大多數現代技術棧中
• 與 Rollup 極其接近的插件接口，這意味着可以複用 Rollup 生態中大部分已經被反覆錘鍊的工具

說真的，這兩條擺上桌面，加上前面討論的性能優勢和超低學習成本，一時半會真想不到拒絕的理由了。。。

三、Vite 的劣勢

Vite 還很新，雖然它從理論與體感上提供了非常極致的開發體驗，還是有一些值得關注的問題。

3.1 兼容性

默認情況下，無論是 dev 還是 build 都會直接打出 ESM 版本的代碼包，這就要求客戶瀏覽器需要有一個比較新的版本，這放在現在的國情下還是有點難度的。

不過 Vite 同時提供了一些彌補的方法，使用 build.polyfillDynamicImport 配置項配合 @vitejs/plugin-legacy 打包出一個看起來兼容性比較好的版本，我相信這一點會隨時間慢慢被抹平。

3.2 缺少 Show Case

Vite 太新了，直到最近才釋放出正式 2.0 版本，社區還沒太反應過來，自然也就沒什麼大型、複雜的商業落地案例，誰都說不準這裏面可能有多少坑。

不過好消息是社區對 Vite 的搜索熱度在最近幾個月急劇增長：

數據來自谷歌指數

相信很快就會出現一大批佈道者，畢竟這玩意兒是真的很有競爭力。

3.3 代價

不要忘記，工程化本身的複雜度不會憑空消失，只 Vite 背後的團隊在幫我們負重前行，這對 Vite 開發團隊而言，維護這麼多構建規則是一個不小的負擔。而站在用戶的角度，越容易上手的工具往往意味着越難被定製。

另外，如果只是在 Vite 預設好的邊框裏面玩確實很容易，但隨着項目複雜度的提高，用戶遲早還是會接觸到底層的 esbuild 或 Rollup，高工們該補的知識還是遲早還是得補回來，逃不掉的。

三、總結

Vite 給我最大的啓示：Webpack 並不是標準答案，前端構建工具可以有一些新的玩法：

• 打包 不是目的，運行 纔是，2021 年了，能夠交給瀏覽器做的事情就交給瀏覽器吧

• 一個靈活的框架，對作者而言可能意味着逐步失控的開發量；對用戶而言可能意味高學習成本，以及不斷重複的類似空格好還是 tab 好的爭論。那麼，一套內置好各種業界 最佳實踐，沒有太多定製空間的工具，某些情況下反而能提升大家的效率

我個人對 Vite 的態度：短期保持觀望，長期非常看好。

我相信現在開始上手學習 Vite 是一個不錯的選擇，這東西封裝的太好了，學習成本極低 (吹逼效果極好)，可以寫點 Demo 或者就直接在一些用戶範圍可控的小型新項目落地。但是，建議不要激進地直接重構一些已有的大型項目，別自己給自己埋坑了，早點下班不香嗎。

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