打包

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

Webpack

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

(資料圖片僅供參考)

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

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

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

Esbuild

Esbuild 是一個用 Go 編寫的模塊打包工具。因為它大量利用了 Go 中并行的特性，所以 Esbuild 非?？?。

Esbuild 內(nèi)部的算法經(jīng)過精心設(shè)計，在可能的情況下它將飽和使用所有可用的 CPU 內(nèi)核Esbuild 中的所有功能在開始編寫時就充分考慮了性能

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

Rollup

Rollup 是一個 JavaScript 模塊打包工具，可以將多個小的代碼片段編譯為完整的庫和應用。與傳統(tǒng)的 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 可以緩存程序中任何函數(shù)的結(jié)果。當程序被執(zhí)行多次時，函數(shù)不會重新運行，除非它們的輸入發(fā)生變化。

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

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

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

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

Nobundle：Vitejs

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

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

對于生產(chǎn)環(huán)境，Vitejs 使用 Rollup 進行打包。

文檔：https://vitejs.cn/

編譯工具

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

將 TS 轉(zhuǎn)換為 JS；將新版本 JS 語法轉(zhuǎn)換為低版本瀏覽器支持的語法；

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

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

Babel

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

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

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

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

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

TSC

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

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

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

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

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

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

Babel for transpiling, TSC for types ：

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

SWC

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

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

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

優(yōu)缺點：

SWC 最大的優(yōu)勢就是編譯速度快，另外在可擴展性、WASM 支持、社區(qū)和生態(tài)系統(tǒng)方面也是做的非常不錯的。

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

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

SWC并不滿足只是一個編譯工具，未來或?qū)⒅С秩缦履芰?/strong>：

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

esbuild

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

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

優(yōu)化技術(shù)

1、LightHouse

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

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

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

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

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

5、Tree Shaking

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

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

關(guān)鍵詞：