前端開發的惡夢!轉譯器、捆綁器、編譯器、觀察器,讓你深陷苦難

游客2024-07-09 08:45:01

 1

作者| Anton

譯者| 核子可樂

策劃| 田曉旭

 2

不久之前,我開始為自己的新專案建立一套儀表板。這套儀表板中包含一個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 加進行開發,是因為這套組合在便利性、靈活性與強大的可重現性方面簡直無可匹敵。

解決方案:

是另一款捆綁器與縮小器。下面來看看它的強大能力。

閒言少敘,咱們用圖說:

 3

這是怎麼做到的?

它使用Go 語言編寫而成,Go 語言可以編譯為原生程式碼;

解析、輸出與來源映射產生完全以並行化方式進行;

不涉及資源成本高昂的資料轉換,只需要很少幾步即可完成所有操作。

對於像我這樣絕望的開發者來說,它的效果實在是太棒了。更重要的是,Vue 3 在其Vite 捆綁器中內置,所以我意識到要擺脫痛苦的生活,我得馬上轉移到Vue 3 加ESM 這片陣地上。

我將替換成了v-,其使用Vue 3 與。為此,我得做好學習新科技的準備:

但在看到Vite 在編譯新儀表板時的出色表現,我發現一切都物有所值。

Vite 的提速原理

Vite 使用ES 模組加帶來了極快的處理速度。具體的提速原理就是之前提到的三點。

ES 模組

它其實就是我們的老朋友中的「」語句。現在您已經可以在各種瀏覽器中直接使用,讚!

這項功能還無法支援所有網頁瀏覽器,也許還要再等一年才能全面普及。但它已經可以在最新的與中正常使用,因此大家不妨考慮將其引入開發當中。

Vite 會聰明地在適當的地方“偷工減料”,而且不需要把JS 文件捆綁到開發build 當中。

目前只有一個問題, 無法在編譯過程中驗證的正確性,但考慮到VS Code 與lang 已經完成了驗證工作,所以應該沒什麼關係。

結果

 4

就這樣,我的日常前端開發體驗又回歸了正常範圍。這裡建議大家在新專案中嘗試使用Vite(如果您更傾向於React 或其他框架,也可以嘗試使用ES 模組+)。雖然它還不完美,仍處於beta 測試階段,但開發者的體驗非常重要。 Vite,絕對值得一個機會!