打包

目前前端世界主流的前 3 名模塊打包器仍然是Webpack、Rollup和Esbuild。

Webpack

本質上，Webpack 是一個用于現代 JavaScript 應用程序的靜態模塊打包工具。當 Webpack 處理應用程序時，它會在內部從一個或多個入口點構建一個依賴圖(dependency graph)，然后將你項目中所需的每一個模塊組合成一個或多個 bundles，它們均為靜態資源，用于展示你的內容。

(資料圖片僅供參考)

使用如下命令來安裝：webpacknpm install webpack -g

安裝完后，可以輸入webpack -v命令查看是否安裝成功。

文檔：https://webpack.docschina.org/concepts/

Esbuild

Esbuild 是一個用 Go 編寫的模塊打包工具。因為它大量利用了 Go 中并行的特性，所以 Esbuild 非?？臁?/p>Esbuild 內部的算法經過精心設計，在可能的情況下它將飽和使用所有可用的 CPU 內核Esbuild 中的所有功能在開始編寫時就充分考慮了性能

文檔：https://esbuild.github.io/

Rollup

Rollup 是一個 JavaScript 模塊打包工具，可以將多個小的代碼片段編譯為完整的庫和應用。與傳統的 CommonJS 和 AMD 這一類非標準化的解決方案不同，Rollup 使用的是ES6版本 Javascript 中的模塊標準。

與 Webpack 相比快速且輕量級支持 Tree Shaking

文檔：https://www.rollupjs.com/

Parcel

Parcel 是一個眾所周知的零配置 Web 應用程序打包器。

默認啟用 Tree Shaking使用 Rust 編寫的 Javascript 編譯器，以利用并行性并提高性能支持原生 ES Moduls 和 CommonJS 兩種模塊標準自動代碼拆分

文檔：https://parceljs.org/docs/

Turbopack

Turbopack建立在 Turbo 之上：Turbo 是一種用于Rust的開源增量記憶框架。Turbo 可以緩存程序中任何函數的結果。當程序被執行多次時，函數不會重新運行，除非它們的輸入發生變化。

這種方法使 Turbopack 在計算增量更新方面非?？?。這也優化了 Turbopack 使得開發過程中增量更新非常快，確保 dev server 能夠快速響應代碼變更。

Turbopack 還使用請求級編譯方法來只編譯請求的代碼。如果瀏覽器請求某些 CSS，則只會編譯該 CSS，而不編譯引用的 images。采用請求級編譯有助于減少請求數量并能夠快速編譯它們。

目前，Turbopack 比現有打包工具快 10 倍～700 倍。但它目前只可以在 Next.js v13 中使用。未來計劃發布獨立的 CLI、插件 API，并支持 Svelte 和 Vue 等其他框架。

文檔：https://turbo.build/pack/docs

Nobundle：Vitejs

Vite 通過在一開始將應用中的模塊區分為依賴和源碼兩類，改進了開發服務的啟動時間。

依賴大多為在開發時不會變動的純 JavaScript。一些較大的依賴（例如有上百個模塊的組件庫）處理的代價也很高。依賴也通常會存在多種模塊化格式（例如 ESM 或者 CommonJS）。Vite 將會使用 esbuild (https://esbuild.github.io/) 預構建依賴(https://cn.vitejs.dev/guide/dep-pre-bundling.html)。源碼通常包含一些并非直接是 JavaScript 的文件，需要轉換（例如 JSX，CSS 或者 Vue/Svelte 組件），時常會被編輯。同時并不是所有的源碼都需要同時被加載（例如基于路由拆分的代碼模塊）。Vite 以 原生 ESM (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules) 方式提供源碼。這實際上是讓瀏覽器接管了打包程序的部分工作：Vite 只需要在瀏覽器請求源碼時進行轉換并按需提供源碼。根據情景動態導入代碼，即只在當前屏幕上實際使用時才會被處理。

對于生產環境，Vitejs 使用 Rollup 進行打包。

文檔：https://vitejs.cn/

編譯工具

編譯工具（Compiler）可以理解為將一種語言編寫的源代碼轉換為另一種語言的過程。在前端開發過程中，我們經常遇到如下兩類編譯場景：

將 TS 轉換為 JS；將新版本 JS 語法轉換為低版本瀏覽器支持的語法；

當前前端界的編譯工具，如下四個占據了大部分市場：

名稱	描述	Star	底層語言
Babel (https://babeljs.io/)	JS 編譯器，用于將新版本 JS 語法轉換為向后兼容的 JS 語法。也可以通過插件(https://babeljs.io/docs/en/babel-plugin-transform-typescript)支持 TS 語法編譯，但不支持類型檢查。	41.8K	JS
TSC (https://www.typescriptlang.org/)	TS 官方編譯器，用于將 TS 編譯成 JS。同時也支持舊版本語法轉換，但不能自動 polyfill。	87.5K	TS
SWC (https://swc.rs/)	新一代 JS 編譯器，特點是速度非常快，宣稱單核下比 Bable 快 20 倍。支持 TS 編譯，但不會做類型檢查。	25.5K	Rust
esbuild (https://esbuild.github.io/)	一款超級快且融合編譯&打包的工具，宣稱比現在生態（說的就是你：webpack + babel）快10-100倍。支持 JS/TS，編譯 TS 不會做類型檢查。	34.3K	Go

Babel

最早開始出現JS編譯工具之一，也是目前使用最多的 JS 編譯工具。隨著 Babel 的出現，前端開發者可以直接編寫現代 JS 代碼，同時又不失去對舊瀏覽器的支持。

簡單來說，Babel 是一個工具鏈，主要用于將 ECMAScript 2015+ 版本的代碼轉換為向后兼容的 JavaScript 語法，以便能夠運行在當前和舊版本的瀏覽器或其他環境中。Babel 可以做如下事情：

語法轉換，比如 const、let、?.、箭頭函數等最新 ES API 和 ES 實例/靜態方法的 Polyfill，如 Promise、Array.prototype.includes等。這部分主要通過第三方庫來 polyfill，如 core-js (https://github.com/zloirock/core-js)源碼轉換（codemods）

Babel 官方提供一個 在線編譯網站(https://babeljs.io/repl)，大家可以使用它便捷的體驗 Babel 的編譯效果。

Babel 構建在插件之上，默認情況下，Babel 不做任何處理，需要借助插件來完成語法的解析、轉換、輸出。

TSC

TSC（TypeScript Compiler） 是 TS 語言官方的編譯器，最初 TS 語言只能使用 TSC 進行編譯，隨著 Babel 等工具也相繼支持編譯 TS，你可能有疑問，他們之間有什么區別嗎？答案是有的， 相對于 Babel，TSC 有如下 優勢：

可以進行類型檢查；可以識別所有的類型并生成 .d.ts 類型文件；

原因在于 Babel 是單個文件編譯的，不會解析其他文件的信息，而 TSC 的類型檢查需要拿到整個工程的類型信息，需要做類型的引入、多文件 namespace 的合并等。而 Babel 編譯 TS 只是去掉類型聲明，保留原有 JS 功能。

通過配置 target也可以讓 TSC 編譯出低版本瀏覽器支持的代碼，但存在一些 缺點：

對一些新語法缺乏支持，如提案階段的語法；對于ESAPI和 ES 實例/靜態方法無法解析，需要單獨添加polyfill；

綜上，現在的前端 TS 項目一般還是會使用 Babel 做編譯，使用 TSC 做類型檢查。

Babel for transpiling, TSC for types ：

(https://www.typescriptlang.org/docs/handbook/babel-with-typescript.html#handbook-content)

SWC

一款基于 Rust 語言開發的編譯工具，它相對于 Babel 的優勢就是編譯速度非?？?/strong>，在它的官網上，寫著如下一句話。

SWC is 20x faster thanBabelon a single thread and 70x fasteron four cores.

SWC 的成功得益于 Rust 語言，這是一門高效、性能更好且內存安全的語言。隨著 SWC 的崛起，很快它就被 Next.js 采用，進而取代 Babel 作為 JS 編譯工具。

優缺點：

SWC 最大的優勢就是編譯速度快，另外在可擴展性、WASM 支持、社區和生態系統方面也是做的非常不錯的。

但是，如果從 Babel 切換到 SWC，也有一些問題需要考量：

相對于Babel，SWC的編譯支持上有一些區別，參考 官方列表 (https://swc.rs/docs/migrating-from-babel) 可能會導致代碼的瀏覽器支持度降低SWC 也有插件系統，但仍是實驗性的，且開發插件要學習 Rust 和 WebAssembly，上手門檻明顯很高

SWC并不滿足只是一個編譯工具，未來或將支持如下能力：

編譯工具，替代 Babel打包器，替代 Webpack，目前正在建設中：swcpack (https://swc.rs/docs/usage/bundling)類型檢查器，替代 TSC壓縮器，替代 Terser

esbuild

esbuild 更多是作為打包工具被大眾熟知，我們在打包工具章節也做了介紹。

其實 esbuild 也是支持編譯能力的，且速度要比 Babel 快很多，但是它不兼容低版本瀏覽器，產物無法降級到 ES6 以下。esbuild 也原生支持編譯 TS 語言，同樣不支持類型檢查，遺憾的是官方也沒有計劃去做這件事。

優化技術

1、LightHouse

通過LightHouse獲取頁面FCP (First Contentful Paint)和Speed Index指標，首屏加載FCP要盡量減少白頁，Speed Index越快越好（最多4s內）2、Frame Rate

通過Frame Rate 工具檢測頁面FPS，遇到輪播圖動畫等頁面交互時應該盡量保證fps流暢，防止用戶觀看時出現卡頓閃爍等視覺體驗3、NetWork

通過瀑布圖NetWork，直觀的看到接口的響應速度，盡量縮短響應的速度，同時也能看到一個頁面的接口請求數，減少同時并發的請求，把不重要的請求往后排序，來提升性能4、Performance

通過Performance監聽主線程性能，盡量減少DOM加載時間

參考：https://blog.csdn.net/m0_68324632/article/details/127487822

5、Tree Shaking

搖樹優化Tree Shaking是Webpack里非常重要的優化措施，它的優化效果在Webpack 5中又得到了進一步的提升。Tree Shaking可以幫我們檢測模塊中沒有使用到的代碼塊，并在Webpack打包時將沒有用到的代碼塊移除掉，減小打包后的資源體積大小。它的名字也非常形象，通過搖晃樹把樹上干枯無用的葉子搖掉。

參考：https://zhuanlan.zhihu.com/p/467104092

關鍵詞：