文章出處

這是一篇關于js模塊化歷程的長長的流水賬，記錄js模塊化思想的誕生與變遷，展望ES6模塊化標準的未來。經歷過這段歷史的人或許會感到滄桑，沒經歷過的人也應該知道這段歷史。

 

無模塊時代

在ajax還未提出之前，js還只是一種“玩具語言”，由Brendan Eich花了不到十天時間發明，用來在網頁上進行表單校驗、實現簡單的動畫效果等等，你可以回想一下那個網頁上到處有公告塊飄來飄去的時代。
這個時候并沒有前端工程師，服務端工程師只需在頁面上隨便寫寫js就能搞定需求。那個時候的前端代碼大概像這樣：
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，標簽的書寫順序必須是
<script type="text/javascript" src="a.js"></script>
<script type="text/javascript" src="b.js"></script>
順序不能錯，也不能漏寫某個。在多人開發的時候很難協調。
 
萌芽時代的解決方案：
1. 用自執行函數來包裝代碼
modA = function(){
     var a,b; //變量a、b外部不可見
     return {
          add : function(c){
               a + b + c;
          },
          format: function(){
               //......
          }
     }
}()
這樣function內部的變量就對全局隱藏了，達到是封裝的目的。但是這樣還是有缺陷的，modA這個變量還是暴漏到全局了，隨著模塊的增多，全局變量還是會越來越多。
 2. java風格的命名空間
為了避免全局變量造成的沖突，人們想到或許可以用多級命名空間來進行管理，于是，代碼就變成了這個風格：
app.util.modA = xxx;
app.tools.modA = xxx;
app.tools.modA.format = xxx;
Yahoo的YUI早期就是這么做的，調用的時候不得不這么寫：
app.tools.modA.format();
這樣調用函數，寫寫都會覺得惡心，所以這種方式并沒有被很多人采用，YUI后來也不用這種方式了。
 3. jQuery風格的匿名自執行函數
(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，通過傳入模塊標識來引入其他模塊，執行的結果即為別的模塊暴漏出來的API
3. 如果被require函數引入的模塊中也包含依賴，那么依次加載這些依賴
4. 如果引入模塊失敗，那么require函數應該報一個異常
5. 模塊通過變量exports來向往暴漏API，exports只能是一個對象，暴漏的API須作為此對象的屬性。
此規范一出，立刻產生了良好的效果，由于其簡單而直接，在nodejs中，這種模塊化方案立刻被推廣開了。
遵循commonjs規范的代碼看起來是這樣的：（來自官方的例子）
//math.js
exports.add = function() {
    var sum = 0, i = 0, args = arguments, l = args.length;
    while (i < l) {
        sum += args[i++];
    }
    return sum;
};
//increment.js
var add = require('math').add;
exports.increment = function(val) {
    return add(val, 1);
};
//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，用來引入其他依賴和導出本模塊API
5. 如果factory函數最后明確寫有return數據（js函數中不寫return默認返回undefined），那么return的內容即為模塊的輸出。
使用該規范的例子看起來像這樣：
//可以使用exprots來對外暴漏API
module.declare(function(require, exports, module)
{
    exports.foo = "bar";
});
//也可以直接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,module
6. 如果factory為函數，模塊對外暴漏API的方法有三種：return任意類型的數據、exports.xxx=xxx、module.exports=xxx
7. 如果factory為對象，則該對象即為模塊的返回值
基于以上幾點基本規范，我們便可以用這樣的方式來進行模塊化組織代碼了：
//a.js
define(function(){
     console.log('a.js執行');
     return {
          hello: function(){
               console.log('hello, a.js');
          }
     }
});
//b.js
define(function(){
     console.log('b.js執行');
     return {
          hello: function(){
               console.log('hello, b.js');
          }
     }
});
//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
在點擊按鈕后，會輸出：
hello, b.js
這結局，如你所愿嗎？大體來看，是沒什么問題的，因為你要的兩個hello方法都正確的執行了。
但是如果細細來看，b.js被預先加載并且預先執行了，（第二行輸出），b.hello這個方法是在點擊了按鈕之后才會執行，如果用戶壓根就沒點，那么b.js中的代碼應不應該執行呢？
這其實也是AMD/RequireJs被吐槽的一點，預先下載沒什么爭議，由于瀏覽器的環境特點，被依賴的模塊肯定要預先下載的。問題在于，是否需要預先執行？如果一個模塊依賴了十個其他模塊，那么在本模塊的代碼執行之前，要先把其他十個模塊的代碼都執行一遍，不管這些模塊是不是馬上會被用到。這個性能消耗是不容忽視的。
另一點被吐槽的是，在定義模塊的時候，要把所有依賴模塊都羅列一遍，而且還要在factory中作為形參傳進去，要寫兩遍很大一串模塊名稱，像這樣：
define(['a', 'b', 'c', 'd', 'e', 'f', 'g'], function(a, b, c, d, e, f, g){  ..... })
編碼過程略有不爽。
好的一點是，AMD保留了commonjs中的require、exprots、module這三個功能（上面提到的第4條）。你也可以不把依賴羅列在dependencies數組中。而是在代碼中用require來引入，如下：
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
可以看到b.js并未執行，從網絡請求中看，b.js也并未被下載。只有在按鈕被點擊的時候b.js才會被下載執行，并且在回調函數中執行模塊中的方法。這就是名副其實的“懶加載”了。
 
這樣的懶加載無疑會大大減輕初始化時的損耗（下載和執行都被省去了），但是弊端也是顯而易見的，在后續執行a.hello和b.hello時，必須得實時下載代碼然后在回調中才能執行，這樣的用戶體驗是不好的，用戶的操作會有明顯的延遲卡頓。
但這樣的現實并非是無法接受的，畢竟是瀏覽器環境，我們已經習慣了操作網頁時伴隨的各種loading。。。
 
但是話說過來，有沒有更好的方法來處理問題呢？資源的下載階段還是預先進行，資源執行階段后置，等到需要的時候再執行。這樣一種折衷的方式，能夠融合前面兩種方式的優點，而又回避了缺點。
這就是Modules/Wrappings規范，還記得前面提到的“中間派”嗎？
在AMD的陣營中，也有一部分人提出這樣的觀點，代碼里寫一堆回調實在是太惡心了，他們更喜歡這樣來使用模塊：
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就可以這么寫代碼了：
//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，在別的地方使用它：
require(['d'], function(d){
   
});
上面的代碼會輸出
a.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定義模塊的寫法如下：
//a.js
define(function(require, exports, module){
     console.log('a.js執行');
     return {
          hello: function(){
               console.log('hello, a.js');
          }
     }
});
//b.js
define(function(require, exports, module){
     console.log('b.js執行');
     return {
          hello: function(){
               console.log('hello, b.js');
          }
     }
});
//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和b.js都會預先下載，但是b.js中的代碼卻沒有執行，因為還沒有點擊按鈕。當點擊按鈕的時候，會輸出如下：
b.js執行
hello, b.js
可以看到b.js中的代碼此時才執行。這樣就真正實現了“就近書寫，延遲執行“，不可謂不優雅。
 
如果你一定要挑出一點不爽的話，那就是b.js的預先下載了。你可能不太想一開始就下載好所有的資源，希望像requirejs那樣，等點擊按鈕的時候再開始下載b.js。本著兼容并包的思想，seajs也實現了這一功能，提供require.async API，在點擊按鈕的時候，只需這樣寫：
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導出就可以了：
//方式一, a.js
export var a = 1;
export var obj = {name: 'abc', age: 20};
export function run(){....}
//方式二, b.js
var a = 1;
var obj = {name: 'abc', age: 20};
function run(){....}
export {a, obj, run}
使用模塊的時候用import關鍵字，如：
import {run as go} from  'a'
run()
如果想要使用模塊中的全部API，也可以不必把每個都列一遍，使用module關鍵字可以全部引入，用法：
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就可以更加自信的走進大規模企業級開發。
=======================
 

文章列表


不含病毒。www.avast.com
arrow
arrow
    全站熱搜
    創作者介紹
    創作者 大師兄 的頭像
    大師兄

    IT工程師數位筆記本

    大師兄 發表在 痞客邦 留言(0) 人氣()