作者| Anton
譯者| 核子可樂
策劃| 田曉旭
不久之前，我開始為自己的新專案建立一套儀表板。這套儀表板中包含一個Node.js API 閘道（仍處於起步階段），外加用於記錄的：
這就引出了本文的主題：很多朋友可能沒有意識到，膨脹已經成為前端世界的頭號難題。轉譯器、捆綁器、編譯器再加上觀察者，負責在保存過程中對項目進行重新編譯、在瀏覽器中進行熱重載，而這一切都讓普通開發者陷入了無窮無盡的苦難當中。
以下我為大家列出一份與Vue 相關的項目清單，正是它們給我過去半年裡的開發工作帶來諸多麻煩（全部使用15 英寸與16 英寸Pro 設備）：
Nuxt
啟動器應用的可調整空間太小，讓使用者感到頭痛不已。瀏覽器會不斷進行熱重載， 上的Nuxt 專案問題佇列中有很多評論都指向這方面內容。
我其實很喜歡這款Vue 儀表板的設計與細節，因此打算稍作調整用在自己的專案裡。在中（ Pro 16 吋），它的開發者模式啟動時長經常會超過2 分鐘，而com.. 顯示CPU 佔用率達400%。考慮到設備中只有4 GB 記憶體專供使用，可以想見它在這台Pro 上根本無法建立生產版本的檔案。很明顯，它應該想辦法使用6 GB 內存外加“指派”存儲卷進行設置，目前我已經根據VS Code 說明文檔的指示完成了這項調整：
#-the-mount--to--for-macos
但即使是在開發者模式下儲存檔案這麼簡單操作，也仍然需要至少10 秒鐘才能完成。
為什麼？
開發環境的出現，大大提升了陣營的整體實力。
據我了解，當大家將主機作業系統資料夾綁定至存儲卷時，我們實際上無法在某些JS 專案中保存某些文件，這就導致有相當一部分文件需要使用或類似的庫進行重新編譯，這種未經優化的垃圾堆會極大佔用硬體資源。雖然這一切與生產建置無關，但光是編譯器與捆綁器就足夠讓和開發者忙得焦頭爛額了。
如果大家每天只需要面對一個JS/TS 項目，而且壓根不用、只在自己的主機作業系統上進行開發的朋友來說，這可能不是什麼大問題。但對於面對完整開發堆疊的群體，以上問題就根本無法接受了。和我一樣，許許多多開發者都喜歡VS Code 項目，但這種愛也成為我們痛苦的根源。
沒錯， 本身也有問題，但至少在最近2、3 年中，它已經成為我在開發工作中的必選項目。這次之所以要使用VS Code 加進行開發，是因為這套組合在便利性、靈活性與強大的可重現性方面簡直無可匹敵。
解決方案:
是另一款捆綁器與縮小器。下面來看看它的強大能力。
閒言少敘，咱們用圖說：
這是怎麼做到的？
它使用Go 語言編寫而成，Go 語言可以編譯為原生程式碼；
解析、輸出與來源映射產生完全以並行化方式進行；
不涉及資源成本高昂的資料轉換，只需要很少幾步即可完成所有操作。
對於像我這樣絕望的開發者來說，它的效果實在是太棒了。更重要的是，Vue 3 在其Vite 捆綁器中內置，所以我意識到要擺脫痛苦的生活，我得馬上轉移到Vue 3 加ESM 這片陣地上。
我將替換成了v-，其使用Vue 3 與。為此，我得做好學習新科技的準備：
但在看到Vite 在編譯新儀表板時的出色表現，我發現一切都物有所值。
Vite 的提速原理
Vite 使用ES 模組加帶來了極快的處理速度。具體的提速原理就是之前提到的三點。
ES 模組
它其實就是我們的老朋友中的「」語句。現在您已經可以在各種瀏覽器中直接使用，讚！
這項功能還無法支援所有網頁瀏覽器，也許還要再等一年才能全面普及。但它已經可以在最新的與中正常使用，因此大家不妨考慮將其引入開發當中。
Vite 會聰明地在適當的地方“偷工減料”，而且不需要把JS 文件捆綁到開發build 當中。
目前只有一個問題， 無法在編譯過程中驗證的正確性，但考慮到VS Code 與lang 已經完成了驗證工作，所以應該沒什麼關係。
結果
就這樣，我的日常前端開發體驗又回歸了正常範圍。這裡建議大家在新專案中嘗試使用Vite（如果您更傾向於React 或其他框架，也可以嘗試使用ES 模組+）。雖然它還不完美，仍處於beta 測試階段，但開發者的體驗非常重要。 Vite，絕對值得一個機會！