一篇了解 Vite 的好與壞
本文轉(zhuǎn)載自微信公眾號「Tecvan」,作者范文杰。轉(zhuǎn)載本文請聯(lián)系Tecvan公眾號。
一、Vite 是什么
2020年4月,尤大大發(fā)了這么一個推:
隨后,2021年2月,Vite 2.0 它來了,上來就是一套組合拳:
- 基于 esbuild 實現(xiàn)的極速開發(fā)體驗
- 多框架支持
- 兼容 Rollup 的插件機制與 API
- SSR 支持
- 舊瀏覽器支持
一開始我是拒絕的,從 grunt、gulp ,到 Webpack、Rollup、Snowpack 以及若干知名不知名構(gòu)建框架,都2021了,還來?然后試用了一下,嗯,是真的香!
二、Vite 的優(yōu)勢
2.1 真 TM 快
Vite 非常非???,對比 Vue-cli(基于 Webpack):
Dev 啟動時長 | Dev 頁面加載速度 | Build 時長 | |
Vue-cli | 2568ms | 320ms | 5.14s |
Vite | 232ms | 379ms | 2.39s |
示例代碼:Vue3 項目,10個組件
測試兩者的 dev 命令運行耗時相差十倍,且理論上,項目越大性能差距越大,為什么呢?最大的原因是 Vite 在開發(fā)模式下并沒有做太多打包操作!
Webpack 啟動后會做一堆事情,經(jīng)歷一條很長的編譯打包鏈條,從入口開始需要逐步經(jīng)歷語法解析、依賴收集、代碼轉(zhuǎn)譯、打包合并、代碼優(yōu)化,最終將高版本的、離散的源碼編譯打包成低版本、高兼容性的產(chǎn)物代碼,這可滿滿都是 CPU、IO 操作啊,在 Node 運行時下性能必然是有問題。
而 Vite 運行 Dev 命令后只做了兩件事情,一是啟動了一個用于承載資源服務(wù)的 service;二是使用 esbuild 預(yù)構(gòu)建 npm 依賴包。之后就一直躺著,直到瀏覽器以 http 方式發(fā)來 ESM 規(guī)范的模塊請求時,Vite 才開始“「按需編譯」”被請求的模塊。
這里 Vite 預(yù)設(shè)的前提是:
- 現(xiàn)代瀏覽器大多數(shù)已經(jīng)原生支持 ESM 規(guī)范,構(gòu)建工具 —— 特別是開發(fā)環(huán)境下已經(jīng)沒有太大必要為了低版本兼容把大量的時間花在編譯打包上了!
這么一對比,Webpack 是啥都做了,瀏覽器只要運行編譯好的低版本(es5)代碼就行;而 Vite 只處理問題的一部分,剩下的事情交由瀏覽器自行處理,那速度必然賊 TM 快。
除了啟動階段跳過編譯操作之外,Vite 還有很多值得一提的性能優(yōu)化,整體梳理一下:
- 預(yù)編譯:npm 包這類基本不會變化的模塊,使用 Esbuild 在 「預(yù)構(gòu)建」 階段先打包整理好,減少 http 請求數(shù)
- 按需編譯:用戶代碼這一類頻繁變動的模塊,直到被使用時才會執(zhí)行編譯操作
- 客戶端強緩存:請求過的模塊會被以 http 頭 max-age=31536000,immutable 設(shè)置為強緩存,如果模塊發(fā)生變化則用附加的版本 query 使其失效
- 產(chǎn)物優(yōu)化:相比于 Webpack ,Vite 直接錨定高版本瀏覽器,不需要在 build 產(chǎn)物中插入過多運行時與模板代碼
- 內(nèi)置更好的分包實現(xiàn):不需要用戶干預(yù),默認啟用一系列智能分包規(guī)則,盡可能減少模塊的重復(fù)打包
- 更好的靜態(tài)資源處理:Vite 盡量避免直接處理靜態(tài)資源,而是選擇遵循 ESM 方式提供服務(wù),例如引入圖片 import img from 'xxx.png' 語句,執(zhí)行后 img 變量只是一個路徑字符串。
可以看出,Vite 的快是全方位的,從 Dev 到 Build,從 npm 包到項目源碼,再到靜態(tài)資源處理都在 ESM 規(guī)則框架下盡可能地實現(xiàn)各種優(yōu)化措施,理論性能急劇提升。
2.2 簡單
Vite 的用法很簡單, 執(zhí)行初始化命令:
- yarn create @vitejs/app my-vue-app --template vue
就得到了一個預(yù)設(shè)好的開發(fā)環(huán)境,可以開始愉快地寫 demo 了,Vite 開箱就給你一堆功能,包括 css 預(yù)處理器、html 預(yù)處理器、hash 命名、異步加載、分包、壓縮、HMR 等:
這些功能,作者都按行業(yè)最佳實踐預(yù)設(shè)好了,通常不需要用戶介入做變更。
Vite 的表現(xiàn)很容易讓人聯(lián)想到 vue-cli,不過兩者區(qū)別還是挺大的:vue-cli 底層依賴 Webpack,實際的構(gòu)建工作通常由各種 Webpack loader、plugin 實現(xiàn),比如 less => css 由 less-loader 實現(xiàn);圖片加載由 img-loader 實現(xiàn)等。這套設(shè)計很靈活,你可以在 Webpack 體系下做任何你能想到的變更,只需要學(xué)習(xí)一點點 Webpack 的知識,包括百來個配置項、成千上萬的插件、若干虛無縹緲的構(gòu)建概念等。
而 Vite 顯得特別簡潔,它只是暴露了極少數(shù)的配置項與 plugin 接口,設(shè)計上就沒打算讓你做太多自定義操作。。。這是因為 Vite 從一開始就沒打算做成另一個 Webpack,而是做成一套“能夠顯著提升前端開發(fā)體驗的前端構(gòu)建工具”,重在 「開發(fā)體驗」 啊同學(xué)們,Vite 可謂是用心良苦,想盡辦法降低學(xué)習(xí)入門成本,它就不希望你為了使用工具又學(xué)一大堆復(fù)雜、縹緲的概念,希望這些事情都在框架層面屏蔽了 —— 雖然代價是喪失靈活性。
簡單說吧,Vite 定位就是傻瓜式但強大的構(gòu)建工具,你專心寫好業(yè)務(wù)代碼,早點下班,不用再為了工具費神費力了。
2.3 生態(tài)
除了極致的運行性能與簡易的使用方法外,Vite 對已有生態(tài)的兼容性也不容忽略,主要體現(xiàn)在兩個點:
- 與 Vue 解耦,兼容支持 React、Svelte、Preact、Vanilla 等,這意味著 Vite 可以被應(yīng)用在大多數(shù)現(xiàn)代技術(shù)棧中
- 與 Rollup 極其接近的插件接口,這意味著可以復(fù)用 Rollup 生態(tài)中大部分已經(jīng)被反復(fù)錘煉的工具
說真的,這兩條擺上桌面,加上前面討論的性能優(yōu)勢和超低學(xué)習(xí)成本,一時半會真想不到拒絕的理由了。。。
三、Vite 的劣勢
Vite 還很新,雖然它從理論與體感上提供了非常極致的開發(fā)體驗,還是有一些值得關(guān)注的問題。
3.1 兼容性
默認情況下,無論是 dev 還是 build 都會直接打出 ESM 版本的代碼包,這就要求客戶瀏覽器需要有一個比較新的版本,這放在現(xiàn)在的國情下還是有點難度的。
不過 Vite 同時提供了一些彌補的方法,使用 build.polyfillDynamicImport 配置項配合 @vitejs/plugin-legacy 打包出一個看起來兼容性比較好的版本,我相信這一點會隨時間慢慢被抹平。
3.2 缺少 Show Case
Vite 太新了,直到最近才釋放出正式 2.0版本,社區(qū)還沒太反應(yīng)過來,自然也就沒什么大型、復(fù)雜的商業(yè)落地案例,誰都說不準這里面可能有多少坑。
不過好消息是社區(qū)對 Vite 的搜索熱度在最近幾個月急劇增長:
數(shù)據(jù)來自谷歌指數(shù) (https://trends.google.com/trends/explore?date=2021-01-01%202021-07-01&q=vite,webpack)
相信很快就會出現(xiàn)一大批布道者,畢竟這玩意兒是真的很有競爭力。
3.3 代價
不要忘記,工程化本身的復(fù)雜度不會憑空消失,只 Vite 背后的團隊在幫我們負重前行,這對 Vite 開發(fā)團隊而言,維護這么多構(gòu)建規(guī)則是一個不小的負擔(dān)。而站在用戶的角度,越容易上手的工具往往意味著越難被定制。
另外,如果只是在 Vite 預(yù)設(shè)好的邊框里面玩確實很容易,但隨著項目復(fù)雜度的提高,用戶遲早還是會接觸到底層的 esbuild 或 Rollup,高工們該補的知識還是遲早還是得補回來,逃不掉的。
三、總結(jié)
Vite 給我最大的啟示:Webpack 并不是標準答案,前端構(gòu)建工具可以有一些新的玩法:
- 「打包」 不是目的,「運行」 才是,2021年了,能夠交給瀏覽器做的事情就交給瀏覽器吧
- 一個靈活的框架,對作者而言可能意味著逐步失控的開發(fā)量;對用戶而言可能意味高學(xué)習(xí)成本,以及不斷重復(fù)的類似空格好還是 tab 好的爭論。那么,一套內(nèi)置好各種業(yè)界 「最佳實踐」,沒有太多定制空間的工具,某些情況下反而能提升大家的效率
我個人對 Vite 的態(tài)度:短期保持觀望,長期非常看好。
我相信現(xiàn)在開始上手學(xué)習(xí) Vite 是一個不錯的選擇,這東西封裝的太好了,學(xué)習(xí)成本極低(吹逼效果極好),可以寫點 Demo 或者就直接在一些用戶范圍可控的小型新項目落地。但是,建議不要激進地直接重構(gòu)一些已有的大型項目,別自己給自己埋坑了,早點下班不香嗎。