[譯]爲何要 Webpack

啃先生(MrKenniu) | 文

網站進化成 Web app 呈現如下特色

• 使用更多 JavaScript

• 更多的用戶界面經過現代瀏覽器提供服務

• 頁面在提供服務的過程當中，儘量少地刷新整個頁面

因此如今的網站有很是多代碼在客戶端運行！龐大的代碼庫須要被有序地管理起來，而模塊系統「Module system」提供一種能力，將代碼庫切分紅一個個模塊「Module」

模塊系統的派別們

定義模塊及模塊依賴的方法有好幾種標準

• <script>標籤「沒有使用模塊系統」

• CommonJS

• AMD

• ES6 模塊系統

• 還有其餘的...

script 標籤
這種方式並無使用任何模塊系統

各個模塊向全局對象「例如，window 對象」導出一個接口。其餘模塊經過全局對象訪問這個接口。

缺點：

• 容易引發衝突

• 須要很注意模塊加載的順序

• 模塊使用者須要分解模塊的依賴

• 在大項目裏，須要管理的模塊很是多，管理難度很高

CommonJS：同步的 require 方法
這種方式使用同步的 require 方法加載一個依賴的模塊，而且返回一個接口。給導出對象「exports」添加屬性 或者給 module.exports 賦值，均可以定義模塊的導出對象。

這種方式一般被使用服務器端 NodeJS

優勢

• 能夠利用服務器度的代碼

• npm 已經有許多使用這種風格的模塊

• 很是方便易用

缺點

• 阻塞的加載方式不適用於網絡環境，網絡請求是異步的

• 加載多個模塊時，沒有平行加載

AMD： 異步的 require方法
其餘應用於瀏覽器環境模塊系統，不支持同步的 require ，但提供了異步 require 方法：

優勢

• 符合網絡環境下的異步請求方式

• 多個模塊能夠平行加載

缺點

• 額外的編碼開銷。可讀性比較差

• 有點像一種臨時方案

實現：RequireJS

ES6 模塊系統
ECMAScript 2015「第6版本」，爲 JavaScript 提供了一些語言結構，造成另外一種模塊系統

優勢

• 便於靜態分析

• 面向將來的 ES 標準

缺點

• 瀏覽器支持此特性，還須要一些時間

• 如今還比較少模塊是基於這種方式編寫的

客觀的解決方案
讓開發人員選擇模塊系統，容許現有的代碼庫運行「即便它們使用了其餘的模塊系統」。

傳輸

模塊須要從服務器傳輸到客戶端，才能被客戶端執行。有兩種比較極端的傳輸方式，這兩種方式都被普遍應用，但都不是最佳的

• 一個模塊一次請求

• 全部的模塊都在一次請求

一個模塊一次請求

優勢：只有須要的模塊纔會被傳輸
缺點：過多的請求開銷
缺點：請求延遲較大，致使程序開始比較慢

一次請求全部模塊

優勢：請求開銷比較少，延遲較少
缺點：還未使用到的模塊，還被下載到客戶端了

分片傳輸
多數場景下，須要一種更靈活的傳輸方式，它介於以上兩種極端狀況之間：
當編譯全部模塊時，將一系列模塊分解成一組小的分片「chunk」

• 相對一次請求全部模塊，分片的方式使網絡請求變成多個更小，更快的請求。程序啓動時，不須要用到的分片，將會在須要時才被加載。

• 相對於一次請求一個模塊，這加快程序的初始化，但仍然可讓你在實際使用時獲取更多的代碼「減小網絡請求開銷」。

怎麼分片，在哪裏分片是由開發者決定的。大代碼庫經過這種方式能夠組織得很合理。

結語

針對以上兩大主題，Webpack 支持多種模塊系統風格，支持靈活的 chunk 傳輸「Code Split」。

Webpack 是一個 JS 模塊打包工具，能夠用它打包 Web 網站的 JS 代碼庫，也能夠用來打包第三方代碼庫。不像 RequireJs 只支持 AMD，NodeJS 是 CommonJS， SeaJS 只支持 CMD，現在還有 ES6 Module ... Webpack 像是集大成於一身，開發者在此之上靈活根據本身喜愛編碼。

下一篇文章，總結 Code Split 的用法。