# 現狀
伴隨著移動互聯的大潮，當今越來越多的網站已經從網頁模式進化到了 Webapp 模式。它們運行在現代的高級瀏覽器里，使用 HTML5、 CSS3、 ES6 等更新的技術來開發豐富的功能，網頁已經不僅僅是完成瀏覽的基本需求，并且webapp通常是一個單頁面應用，每一個視圖通過異步的方式加載，這導致頁面初始化和使用過程中會加載越來越多的 JavaScript 代碼，這給前端開發的流程和資源組織帶來了巨大的挑戰。
前端開發和其他開發工作的主要區別，首先是前端是基于多語言、多層次的編碼和組織工作，其次前端產品的交付是基于瀏覽器，這些資源是通過增量加載的方式運行到瀏覽器端，如何在開發環境組織好這些碎片化的代碼和資源，并且保證他們在瀏覽器端快速、優雅的加載和更新，就需要一個模塊化系統，這個理想中的模塊化系統是前端工程師多年來一直探索的難題。
# 模塊系統的演進
模塊系統主要解決模塊的定義、依賴和導出，先來看看已經存在的模塊系統。
### <script>標簽
```js
<script src="module1.js"></script>
<script src="module2.js"></script>
<script src="libraryA.js"></script>
<script src="module3.js"></script>
```
這是最原始的 JavaScript 文件加載方式，如果把每一個文件看做是一個模塊，那么他們的接口通常是暴露在全局作用域下，也就是定義在 `window` 對象中，不同模塊的接口調用都是一個作用域中，一些復雜的框架，會使用命名空間的概念來組織這些模塊的接口，典型的例子如 [YUI](http://yuilibrary.com) 庫。
這種原始的加載方式暴露了一些顯而易見的弊端：
- 全局作用域下容易造成變量沖突
- 文件只能按照 `<script>` 的書寫順序進行加載
- 開發人員必須主觀解決模塊和代碼庫的依賴關系
- 在大型項目中各種資源難以管理，長期積累的問題導致代碼庫混亂不堪
### CommonJS
服務器端的 Node.js 遵循 [CommonJS規范](http://wiki.commonjs.org/wiki/CommonJS)，該規范的核心思想是允許模塊通過 `require` 方法來同步加載所要依賴的其他模塊，然后通過 `exports` 或 `module.exports` 來導出需要暴露的接口。
```js
require("module");
require("../file.js");
exports.doStuff = function() {};
module.exports = someValue;
```
優點：
- 服務器端模塊便于重用
- [NPM](https://www.npmjs.com) 中已經有將近20萬個可以使用模塊包
- 簡單并容易使用
缺點：
- 同步的模塊加載方式不適合在瀏覽器環境中，同步意味著阻塞加載，瀏覽器資源是異步加載的
- 不能非阻塞的并行加載多個模塊
實現：
- 服務器端的 [Node.js](http://www.nodejs.org)
- [Browserify](http://browserify.org)，瀏覽器端的 CommonJS 實現，可以使用 NPM 的模塊，但是編譯打包后的文件體積可能很大
- [modules-webmake](https://github.com/medikoo/modules-webmake)，類似Browserify，還不如 Browserify 靈活
- [wreq](https://github.com/substack/wreq)，Browserify 的前身
### AMD
[Asynchronous Module Definition](https://github.com/amdjs/amdjs-api) 規范其實只有一個主要接口 `define(id?, dependencies?, factory)`，它要在聲明模塊的時候指定所有的依賴 `dependencies`，并且還要當做形參傳到 `factory` 中，對于依賴的模塊提前執行，依賴前置。
```js
define("module", ["dep1", "dep2"], function(d1, d2) {
return someExportedValue;
});
require(["module", "../file"], function(module, file) { /* ... */ });
```
優點：
- 適合在瀏覽器環境中異步加載模塊
- 可以并行加載多個模塊
缺點：
- 提高了開發成本，代碼的閱讀和書寫比較困難，模塊定義方式的語義不順暢
- 不符合通用的模塊化思維方式，是一種妥協的實現
實現：
- [RequireJS](http://requirejs.org)
- [curl](https://github.com/cujojs/curl)
### CMD
[Common Module Definition](https://github.com/cmdjs/specification/blob/master/draft/module.md) 規范和 AMD 很相似，盡量保持簡單，并與 CommonJS 和 Node.js 的 Modules 規范保持了很大的兼容性。
```js
define(function(require, exports, module) {
var $ = require('jquery');
var Spinning = require('./spinning');
exports.doSomething = ...
module.exports = ...
})
```
優點：
- 依賴就近，延遲執行
- 可以很容易在 Node.js 中運行
缺點：
- 依賴 SPM 打包，模塊的加載邏輯偏重
實現：
- [Sea.js](http://seajs.org/)
- [coolie](https://github.com/cloudcome/coolie)
### UMD
[Universal Module Definition](https://github.com/umdjs/umd) 規范類似于兼容 CommonJS 和 AMD 的語法糖，是模塊定義的跨平臺解決方案。
### ES6 模塊
EcmaScript6 標準增加了 JavaScript 語言層面的模塊體系定義。[ES6 模塊](http://es6.ruanyifeng.com/#docs/module)的設計思想，是盡量的靜態化，使得編譯時就能確定模塊的依賴關系，以及輸入和輸出的變量。CommonJS 和 AMD 模塊，都只能在運行時確定這些東西。
```js
import "jquery";
export function doStuff() {}
module "localModule" {}
```
優點：
- 容易進行靜態分析
- 面向未來的 EcmaScript 標準
缺點：
- 原生瀏覽器端還沒有實現該標準
- 全新的命令字，新版的 Node.js才支持
實現：
- [Babel](https://babeljs.io/)
### 期望的模塊系統
可以兼容多種模塊風格，盡量可以利用已有的代碼，不僅僅只是 JavaScript 模塊化，還有 CSS、圖片、字體等資源也需要模塊化。
# 前端模塊加載
前端模塊要在客戶端中執行，所以他們需要增量加載到瀏覽器中。
模塊的加載和傳輸，我們首先能想到兩種極端的方式，一種是每個模塊文件都單獨請求，另一種是把所有模塊打包成一個文件然后只請求一次。顯而易見，每個模塊都發起單獨的請求造成了請求次數過多，導致應用啟動速度慢；一次請求加載所有模塊導致流量浪費、初始化過程慢。這兩種方式都不是好的解決方案，它們過于簡單粗暴。
__分塊傳輸__，按需進行懶加載，在實際用到某些模塊的時候再增量更新，才是較為合理的模塊加載方案。
要實現模塊的按需加載，就需要一個對整個代碼庫中的模塊進行靜態分析、編譯打包的過程。
# 所有資源都是模塊
在上面的分析過程中，我們提到的模塊僅僅是指JavaScript模塊文件。然而，在前端開發過程中還涉及到樣式、圖片、字體、HTML 模板等等眾多的資源。這些資源還會以各種方言的形式存在，比如 coffeescript、 less、 sass、眾多的模板庫、多語言系統（i18n）等等。
如果他們都可以視作模塊，并且都可以通過`require`的方式來加載，將帶來優雅的開發體驗，比如：
```js
require("./style.css");
require("./style.less");
require("./template.jade");
require("./image.png");
```
那么如何做到讓 `require` 能加載各種資源呢？
# 靜態分析
在編譯的時候，要對整個代碼進行靜態分析，分析出各個模塊的類型和它們依賴關系，然后將不同類型的模塊提交給適配的加載器來處理。比如一個用 LESS 寫的樣式模塊，可以先用 LESS 加載器將它轉成一個CSS 模塊，在通過 CSS 模塊把他插入到頁面的 `<style>` 標簽中執行。Webpack 就是在這樣的需求中應運而生。
同時，為了能利用已經存在的各種框架、庫和已經寫好的文件，我們還需要一個模塊加載的兼容策略，來避免重寫所有的模塊。
那么接下來，讓我們開始 Webpack 的神奇之旅吧。
