這是一篇關於js模組化歷程的長長的流水賬，記錄js模組化思想的誕生與變遷，展望ES6模組化標準的未來。經歷過這段歷史的人或許會感到滄桑，沒經歷過的人也應該知道這段歷史。
無模組時代
在ajax還未提出之前，js還只是一種“玩具語言”，由Brendan Eich花了不到十天時間發明，用來在網頁上進行表單校驗、實現簡單的動畫效果等等，你可以回想一下那個網頁上到處有公告塊飄來飄去的時代。
這個時候並沒有前端工程師，服務端工程師只需在頁面上隨便寫寫js就能搞定需求。那個時候的前端程式碼大概像這樣：
|
1 2 3 4 5 6 7 8 9 10 11 12 |
if(xx){ //....... } else{ //xxxxxxxxxxx } for(var i=0; i<10; i++){ //........ } element.onclick = function(){ //....... } |
程式碼簡單的堆在一起，只要能從上往下依次執行就可以了。
模組萌芽時代
2006年，ajax的概念被提出，前端擁有了主動向服務端傳送請求並操作返回資料的能力，隨著Google將此概念的發揚光大，傳統的網頁慢慢的向“富客戶端”發展。前端的業務邏輯越來越多，程式碼也越來越多，於是一些問題就暴漏了出來：
1. 全域性變數的災難
小明定義了 i=1
小剛在後續的程式碼裡：i=0
小明在接下來的程式碼裡：if(i==1){…} //悲劇
2. 函式命名衝突
專案中通常會把一些通用的函式封裝成一個檔案，常見的名字有utils.js、common.js…
小明定義了一個函式：function formatData(){ }
小剛想實現類似功能，於是這麼寫：function formatData2(){ }
小光又有一個類似功能，於是：function formatData3(){ }
……
避免命名衝突就只能這樣靠醜陋的方式人肉進行。
3. 依賴關係不好管理
b.js依賴a.js，標籤的書寫順序必須是
|
1 2 |
<script type="text/javascript" src="a.js"></script> <script type="text/javascript" src="b.js"></script> |
順序不能錯，也不能漏寫某個。在多人開發的時候很難協調。
萌芽時代的解決方案：
1. 用自執行函式來包裝程式碼
|
1 2 3 4 5 6 7 8 9 10 11 |
modA = function(){ var a,b; //變數a、b外部不可見 return { add : function(c){ a + b + c; }, format: function(){ //...... } } }() |
這樣function內部的變數就對全域性隱藏了，達到是封裝的目的。但是這樣還是有缺陷的，modA這個變數還是暴漏到全域性了，隨著模組的增多，全域性變數還是會越來越多。
2. java風格的名稱空間
為了避免全域性變數造成的衝突，人們想到或許可以用多級名稱空間來進行管理，於是，程式碼就變成了這個風格：
|
1 2 3 |
app.util.modA = xxx; app.tools.modA = xxx; app.tools.modA.format = xxx; |
Yahoo的YUI早期就是這麼做的，呼叫的時候不得不這麼寫：
|
1 |
app.tools.modA.format(); |
這樣呼叫函式，寫寫都會覺得噁心，所以這種方式並沒有被很多人採用，YUI後來也不用這種方式了。
3. jQuery風格的匿名自執行函式
|
1 2 3 4 5 |
(function(window){ //程式碼 window.jQuery = window.$ = jQuery;//通過給window新增屬性而暴漏到全域性 })(window); |
jQuery的封裝風格曾經被很多框架模仿，通過匿名函式包裝程式碼，所依賴的外部變數傳給這個函式，在函式內部可以使用這些依賴，然後在函式的最後把模組自身暴漏給window。
如果需要新增擴充套件，則可以作為jQuery的外掛，把它掛載到$上。
這種風格雖然靈活了些，但並未解決根本問題：所需依賴還是得外部提前提供、還是增加了全域性變數。
模組化面臨什麼問題
從以上的嘗試中，可以歸納出js模組化需要解決那些問題：
1. 如何安全的包裝一個模組的程式碼？（不汙染模組外的任何程式碼）
2. 如何唯一標識一個模組？
3. 如何優雅的把模組的API暴漏出去？（不能增加全域性變數）
4. 如何方便的使用所依賴的模組？
圍繞著這些問題，js模組化開始了一段艱苦而曲折的征途。
源自nodejs的規範CommonJs
2009年，nodejs橫空出世，開創了一個新紀元，人們可以用js來編寫服務端的程式碼了。如果說瀏覽器端的js即便沒有模組化也可以忍的話，那服務端是萬萬不能的。
大牛雲集的CommonJs社群發力，制定了Modules/1.0（http://wiki.commonjs.org/wiki/Modules/1.0）規範，首次定義了一個模組應該長啥樣。具體來說，Modules/1.0規範包含以下內容：
1. 模組的標識應遵循的規則（書寫規範）2. 定義全域性函式require，通過傳入模組標識來引入其他模組，執行的結果即為別的模組暴漏出來的API3. 如果被require函式引入的模組中也包含依賴，那麼依次載入這些依賴4. 如果引入模組失敗，那麼require函式應該報一個異常5. 模組通過變數exports來嚮往暴漏API，exports只能是一個物件，暴漏的API須作為此物件的屬性。
此規範一出，立刻產生了良好的效果，由於其簡單而直接，在nodejs中，這種模組化方案立刻被推廣開了。
遵循commonjs規範的程式碼看起來是這樣的：（來自官方的例子）
|
1 2 3 4 5 6 7 8 |
//math.js exports.add = function() { var sum = 0, i = 0, args = arguments, l = args.length; while (i < l) { sum += args[i++]; } return sum; }; |
|
1 2 3 4 5 |
//increment.js var add = require('math').add; exports.increment = function(val) { return add(val, 1); }; |
|
1 2 3 4 |
//program.js var inc = require('increment').increment; var a = 1; inc(a); // 2 |
服務端向前端進軍
Modules/1.0規範源於服務端，無法直接用於瀏覽器端，原因表現為：
1. 外層沒有function包裹，變數全暴漏在全域性。如上面例子中increment.js中的add。
2. 資源的載入方式與服務端完全不同。服務端require一個模組，直接就從硬碟或者記憶體中讀取了，消耗的時間可以忽略。而瀏覽器則不同，需要從服務端來下載這個檔案，然後執行裡面的程式碼才能得到API，需要花費一個http請求，也就是說，require後面的一行程式碼，需要資源請求完成才能執行。由於瀏覽器端是以插入<script>標籤的形式來載入資源的（ajax方式不行，有跨域問題），沒辦法讓程式碼同步執行，所以像commonjs那樣的寫法會直接報錯。
所以，社群意識到，要想在瀏覽器環境中也能模組化，需要對規範進行升級。順便說一句，CommonJs原來是叫ServerJs，從名字可以看出是專攻服務端的，為了統一前後端而改名CommonJs。（論起名的重要性~）
而就在社群討論制定下一版規範的時候，內部發生了比較大的分歧，分裂出了三個主張，漸漸的形成三個不同的派別：
1.Modules/1.x派
這一波人認為，在現有基礎上進行改進即可滿足瀏覽器端的需要，既然瀏覽器端需要function包裝，需要非同步載入，那麼新增一個方案，能把現有模組轉化為適合瀏覽器端的就行了，有點像“保皇派”。基於這個主張，制定了Modules/Transport（http://wiki.commonjs.org/wiki/Modules/Transport）規範，提出了先通過工具把現有模組轉化為複合瀏覽器上使用的模組，然後再使用的方案。
browserify就是這樣一個工具，可以把nodejs的模組編譯成瀏覽器可用的模組。（Modules/Transport規範晦澀難懂，我也不確定browserify跟它是何關聯，有知道的朋友可以講一下）
目前的最新版是Modules/1.1.1（http://wiki.commonjs.org/wiki/Modules/1.1.1），增加了一些require的屬性，以及模組內增加module變數來描述模組資訊，變動不大。
2. Modules/Async派
這一波人有點像“革新派”，他們認為瀏覽器與伺服器環境差別太大，不能沿用舊的模組標準。既然瀏覽器必須非同步載入程式碼，那麼模組在定義的時候就必須指明所依賴的模組，然後把本模組的程式碼寫在回撥函式裡。模組的載入也是通過下載-回撥這樣的過程來進行，這個思想就是AMD的基礎，由於“革新派”與“保皇派”的思想無法達成一致，最終從CommonJs中分裂了出去，獨立制定了瀏覽器端的js模組化規範AMD（Asynchronous Module Definition）（https://github.com/amdjs/amdjs-api/wiki/AMD）
本文後續會繼續討論AMD規範的內容。
3. Modules/2.0派
這一波人有點像“中間派”，既不想丟掉舊的規範，也不想像AMD那樣推到重來。他們認為，Modules/1.0固然不適合瀏覽器，但它裡面的一些理念還是很好的，（如通過require來宣告依賴），新的規範應該相容這些，AMD規範也有它好的地方（例如模組的預先載入以及通過return可以暴漏任意型別的資料，而不是像commonjs那樣exports只能為object），也應採納。最終他們制定了一個Modules/Wrappings（http://wiki.commonjs.org/wiki/Modules/Wrappings）規範，此規範指出了一個模組應該如何“包裝”，包含以下內容：
1. 全域性有一個module變數，用來定義模組2. 通過module.declare方法來定義一個模組3. module.declare方法只接收一個引數，那就是模組的factory，次factory可以是函式也可以是物件，如果是物件，那麼模組輸出就是此物件。4. 模組的factory函式傳入三個引數：require,exports,module，用來引入其他依賴和匯出本模組API5. 如果factory函式最後明確寫有return資料（js函式中不寫return預設返回undefined），那麼return的內容即為模組的輸出。
使用該規範的例子看起來像這樣：
|
1 2 3 4 5 |
//可以使用exprots來對外暴漏API module.declare(function(require, exports, module) { exports.foo = "bar"; }); |
|
1 2 3 4 5 |
//也可以直接return來對外暴漏資料 module.declare(function(require) { return { foo: "bar" }; }); |
AMD/RequireJs的崛起與妥協
AMD的思想正如其名，非同步載入所需的模組，然後在回撥函式中執行主邏輯。這正是我們在瀏覽器端開發所習慣了的方式，其作者親自實現了符合AMD規範的requirejs，AMD/RequireJs迅速被廣大開發者所接受。
AMD規範包含以下內容：
1. 用全域性函式define來定義模組，用法為：define(id?, dependencies?, factory);2. id為模組標識，遵從CommonJS Module Identifiers規範3. dependencies為依賴的模組陣列，在factory中需傳入形參與之一一對應4. 如果dependencies的值中有”require”、”exports”或”module”，則與commonjs中的實現保持一致5. 如果dependencies省略不寫，則預設為[“require”, “exports”, “module”]，factory中也會預設傳入require,exports,module6. 如果factory為函式，模組對外暴漏API的方法有三種：return任意型別的資料、exports.xxx=xxx、module.exports=xxx7. 如果factory為物件，則該物件即為模組的返回值
基於以上幾點基本規範，我們便可以用這樣的方式來進行模組化組織程式碼了：
|
1 2 3 4 5 6 7 8 9 |
//a.js define(function(){ console.log('a.js執行'); return { hello: function(){ console.log('hello, a.js'); } } }); |
|
1 2 3 4 5 6 7 8 9 |
//b.js define(function(){ console.log('b.js執行'); return { hello: function(){ console.log('hello, b.js'); } } }); |
|
1 2 3 4 5 6 7 8 |
//main.js require(['a', 'b'], function(a, b){ console.log('main.js執行'); a.hello(); $('#b').click(function(){ b.hello(); }); }) |
上面的main.js被執行的時候，會有如下的輸出：
a.js執行
b.js執行
main.js執行
hello, a.js
b.js執行
main.js執行
hello, a.js
在點選按鈕後，會輸出：
|
1 |
hello, b.js |
這結局，如你所願嗎？大體來看，是沒什麼問題的，因為你要的兩個hello方法都正確的執行了。
但是如果細細來看，b.js被預先載入並且預先執行了，（第二行輸出），b.hello這個方法是在點選了按鈕之後才會執行，如果使用者壓根就沒點，那麼b.js中的程式碼應不應該執行呢？
這其實也是AMD/RequireJs被吐槽的一點，預先下載沒什麼爭議，由於瀏覽器的環境特點，被依賴的模組肯定要預先下載的。問題在於，是否需要預先執行？如果一個模組依賴了十個其他模組，那麼在本模組的程式碼執行之前，要先把其他十個模組的程式碼都執行一遍，不管這些模組是不是馬上會被用到。這個效能消耗是不容忽視的。
另一點被吐槽的是，在定義模組的時候，要把所有依賴模組都羅列一遍，而且還要在factory中作為形參傳進去，要寫兩遍很大一串模組名稱，像這樣：
|
1 |
define(['a', 'b', 'c', 'd', 'e', 'f', 'g'], function(a, b, c, d, e, f, g){ ..... }) |
編碼過程略有不爽。
好的一點是，AMD保留了commonjs中的require、exprots、module這三個功能（上面提到的第4條）。你也可以不把依賴羅列在dependencies陣列中。而是在程式碼中用require來引入，如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
define(function(){ console.log('main2.js執行'); require(['a'], function(a){ a.hello(); }); $('#b').click(function(){ require(['b'], function(b){ b.hello(); }); }); }); |
我們在define的引數中未寫明依賴，那麼main2.js在執行的時候，就不會預先載入a.js和b.js，只是執行到require語句的時候才會去載入，上述程式碼的輸出如下：
main2.js執行
a.js執行
hello, a.js
a.js執行
hello, a.js
可以看到b.js並未執行，從網路請求中看，b.js也並未被下載。只有在按鈕被點選的時候b.js才會被下載執行，並且在回撥函式中執行模組中的方法。這就是名副其實的“懶載入”了。
這樣的懶載入無疑會大大減輕初始化時的損耗（下載和執行都被省去了），但是弊端也是顯而易見的，在後續執行a.hello和b.hello時，必須得實時下載程式碼然後在回撥中才能執行，這樣的使用者體驗是不好的，使用者的操作會有明顯的延遲卡頓。
但這樣的現實並非是無法接受的，畢竟是瀏覽器環境，我們已經習慣了操作網頁時伴隨的各種loading。。。
但是話說過來，有沒有更好的方法來處理問題呢？資源的下載階段還是預先進行，資源執行階段後置，等到需要的時候再執行。這樣一種折衷的方式，能夠融合前面兩種方式的優點，而又迴避了缺點。
這就是Modules/Wrappings規範，還記得前面提到的“中間派”嗎？
在AMD的陣營中，也有一部分人提出這樣的觀點，程式碼裡寫一堆回撥實在是太噁心了，他們更喜歡這樣來使用模組：
|
1 2 3 4 5 6 7 |
var a = require('a'); a.hello(); $('#b').click(function(){ var b = require('b'); b.hello(); }); |
於是，AMD也終於決定作妥協，相容Modules/Wrappings的寫法，但只是部分相容，例如並沒有使用module.declare來定義模組，而還是用define，模組的執行時機也沒有改變，依舊是預先執行。因此，AMD將此相容稱為Simplified CommonJS wrapping，即並不是完整的實現Modules/Wrappings。
作了此相容後，使用requirejs就可以這麼寫程式碼了：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
//d.js define(function(require, exports, module){ console.log('d.js執行'); return { helloA: function(){ var a = require('a'); a.hello(); }, run: function(){ $('#b').click(function(){ var b = require('b'); b.hello(); }); } } }); |
注意定義模組時候的輕微差異，dependencies陣列為空，但是factory函式的形參必須手工寫上require,exports,module，（這不同於之前的dependencies和factory形參全不寫），這樣寫即可使用Simplified CommonJS wrapping風格，與commonjs的格式一致了。
雖然使用上看起來簡單，然而在理解上卻給後人埋下了一個大坑。因為AMD只是支援了這樣的語法，而並沒有真正實現模組的延後執行。什麼意思呢？上面的程式碼，正常來講應該是預先下載a.js和b.js，然後在執行模組的helloA方法的時候開始執行a.js裡面的程式碼，在點選按鈕的時候開始執行b.js中的方法。實際卻不是這樣，只要此模組被別的模組引入，a.js和b.js中的程式碼還是被預先執行了。
我們把上面的程式碼命名為d.js，在別的地方使用它：
|
1 2 3 |
require(['d'], function(d){ }); |
上面的程式碼會輸出
a.js執行
b.js執行
d.js執行
b.js執行
d.js執行
可以看出，儘管還未呼叫d模組的API，裡面所依賴的a.js和b.js中的程式碼已經執行了。AMD的這種只實現語法卻未真正實現功能的做法容易給人造成理解上的困難，被強烈吐槽。
（在requirejs2.0中，作者宣告已經處理了此問題（https://github.com/jrburke/requirejs/wiki/Upgrading-to-RequireJS-2.0#delayed），但是我用2.1.20版測試的時候還是會預先執行，我有點不太明白原因，如果有懂的高手請指教）
相容幷包的CMD/seajs
既然requirejs有上述種種不甚優雅的地方，所以必然會有新東西來完善它，這就是後起之秀seajs，seajs的作者是國內大牛淘寶前端步道者玉伯。seajs全面擁抱Modules/Wrappings規範，不用requirejs那樣回撥的方式來編寫模組。而它也不是完全按照Modules/Wrappings規範，seajs並沒有使用declare來定義模組，而是使用和requirejs一樣的define，或許作者本人更喜歡這個名字吧。（然而這或多或少又會給人們造成理解上的混淆），用seajs定義模組的寫法如下：
|
1 2 3 4 5 6 7 8 9 |
//a.js define(function(require, exports, module){ console.log('a.js執行'); return { hello: function(){ console.log('hello, a.js'); } } }); |
|
1 2 3 4 5 6 7 8 9 |
//b.js define(function(require, exports, module){ console.log('b.js執行'); return { hello: function(){ console.log('hello, b.js'); } } }); |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
//main.js define(function(require, exports, module){ console.log('main.js執行'); var a = require('a'); a.hello(); $('#b').click(function(){ var b = require('b'); b.hello(); }); }); |
定義模組時無需羅列依賴陣列，在factory函式中需傳入形參require,exports,module，然後它會呼叫factory函式的toString方法，對函式的內容進行正則匹配，通過匹配到的require語句來分析依賴，這樣就真正實現了commonjs風格的程式碼。
上面的main.js執行會輸出如下：
main.js執行
a.js執行
hello, a.js
a.js執行
hello, a.js
a.js和b.js都會預先下載，但是b.js中的程式碼卻沒有執行，因為還沒有點選按鈕。當點選按鈕的時候，會輸出如下：
b.js執行
hello, b.js
hello, b.js
可以看到b.js中的程式碼此時才執行。這樣就真正實現了“就近書寫，延遲執行“，不可謂不優雅。
如果你一定要挑出一點不爽的話，那就是b.js的預先下載了。你可能不太想一開始就下載好所有的資源，希望像requirejs那樣，等點選按鈕的時候再開始下載b.js。本著相容幷包的思想，seajs也實現了這一功能，提供require.async API，在點選按鈕的時候，只需這樣寫：
|
1 2 |
var b = require.async('b'); b.hello(); |
b.js就不會在一開始的時候就載入了。這個API可以說是簡單漂亮。
關於模組對外暴漏API的方式，seajs也是融合了各家之長，支援commonjs的exports.xxx = xxx和module.exports = xxx的寫法，也支援AMD的return寫法，暴露的API可以是任意型別。
你可能會覺得seajs無非就是一個抄，把別人家的優點都抄過來組合了一下。其實不然，seajs是commonjs規範在瀏覽器端的踐行者，對於requirejs的優點也加以吸收。看人家的名字，就是海納百川之意。（再論起名的重要性~），既然它的思想是海納百川，討論是不是抄就沒意義了。
鑑於seajs融合了太多的東西，已經無法說它遵循哪個規範了，所以玉伯乾脆就自立門戶，起名曰CMD（Common Module Definition）規範，有了綱領，就不會再存在非議了。
面向未來的ES6模組標準
既然模組化開發的呼聲這麼高，作為官方的ECMA必然要有所行動，js模組很早就列入草案，終於在2015年6月份釋出了ES6正式版。然而，可能由於所涉及的技術還未成熟，ES6移除了關於模組如何載入/執行的內容，只保留了定義、引入模組的語法。所以說現在的ES6 Module還只是個雛形，半成品都算不上。但是這並不妨礙我們先窺探一下ES6模組標準。
定義一個模組不需要專門的工作，因為一個模組的作用就是對外提供API，所以只需用exoprt匯出就可以了：
|
1 2 3 4 |
//方式一, a.js export var a = 1; export var obj = {name: 'abc', age: 20}; export function run(){....} |
|
1 2 3 4 5 |
//方式二, b.js var a = 1; var obj = {name: 'abc', age: 20}; function run(){....} export {a, obj, run} |
使用模組的時候用import關鍵字，如：
|
1 2 |
import {run as go} from 'a' run() |
如果想要使用模組中的全部API，也可以不必把每個都列一遍，使用module關鍵字可以全部引入，用法：
|
1 2 3 |
module foo from 'a' console.log(foo.obj); a.run(); |
在花括號中指明需使用的API，並且可以用as指定別名。
ES6 Module的基本用法就是這樣，可以看到確實是有些薄弱，而且目前還沒有瀏覽器能支援，只能說它是面向未來了。
目前我們可以使用一些第三方模組來對ES6進行編譯，轉化為可以使用的ES5程式碼，或者是符合AMD規範的模組，例如ES6 module transpiler。另外有一個專案也提供了載入ES6模組的方法，es6-module-loader(https://github.com/ModuleLoader/es6-module-loader)，不過這都是一些臨時的方案，或許明年ES7一發布，模組的載入有了標準，瀏覽器給與了實現，這些工具也就沒有用武之地了。
未來還是很值得期待的，從語言的標準上支援模組化，js就可以更加自信的走進大規模企業級開發。
=======================
參考資料：