CommonJS、AMD、CMD的差別

最近在研究cmd和amd，在網上看到一篇不錯的文章，整理下看看。

在JavaScript發展初期就是為了實作簡單的頁面互動邏輯，寥寥數語即可；如今CPU、浏覽器性能得到了極大的提升，很多頁面邏輯遷移到了用戶端（表單驗證等），随着web2.0時代的到來，Ajax技術得到廣泛應用，jQuery等前端庫層出不窮，前端代碼日益膨脹

這時候JavaScript作為嵌入式的腳本語言的定位動搖了，JavaScript卻沒有為組織代碼提供任何明顯幫助，甚至沒有類的概念，更不用說子產品（module）了，JavaScript極其簡單的代碼組織規範不足以駕馭如此龐大規模的代碼

子產品

既然JavaScript不能handle如此大規模的代碼，我們可以借鑒一下其它語言是怎麼處理大規模程式設計的，在Java中有一個重要帶概念——package，邏輯上相關的代碼組織到同一個包内，包内是一個相對獨立的王國，不用擔心命名沖突什麼的，那麼外部如果使用呢？直接import對應的package即可

import java.util.ArrayList;

遺憾的是JavaScript在設計時定位原因，沒有提供類似的功能，開發者需要模拟出類似的功能，來隔離、組織複雜的JavaScript代碼，我們稱為子產品化。

一個子產品就是實作特定功能的檔案，有了子產品，我們就可以更友善地使用别人的代碼，想要什麼功能，就加載什麼子產品。子產品開發需要遵循一定的規範，各行其是就都亂套了

規範形成的過程是痛苦的，前端的先驅在刀耕火種、茹毛飲血的階段開始，發展到現在初具規模，簡單了解一下這段不凡的曆程

函數封裝

我們在講函數的時候提到，函數一個功能就是實作特定邏輯的一組語句打包，而且JavaScript的作用域就是基于函數的，是以把函數作為子產品化的第一步是很自然的事情，在一個檔案裡面編寫幾個相關函數就是最開始的子產品了

function fn1(){
    statement
}

function fn2(){
    statement
}           

• 1
• 2
• 3
• 4
• 5
• 6
• 7

這樣在需要的以後夾在函數所在檔案，調用函數就可以了

這種做法的缺點很明顯：污染了全局變量，無法保證不與其他子產品發生變量名沖突，而且子產品成員之間沒什麼關系。

對象

為了解決上面問題，對象的寫法應運而生，可以把所有的子產品成員封裝在一個對象中

var myModule = {
    var1: ,

    var2: ,

    fn1: function(){

    },

    fn2: function(){

    }
}           

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13

這樣我們在希望調用子產品的時候引用對應檔案，然後

myModule.fn2();

這樣避免了變量污染，隻要保證子產品名唯一即可，同時同一子產品内的成員也有了關系

看似不錯的解決方案，但是也有缺陷，外部可以随意修改内部成員

myModel.var1 = 100;

這樣就會産生意外的安全問題

立即執行函數

可以通過立即執行函數，來達到隐藏細節的目的

var myModule = (function(){
    var var1 = ;
    var var2 = ;

    function fn1(){

    }

    function fn2(){

    }

    return {
        fn1: fn1,
        fn2: fn2
    };
})();           

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17

這樣在子產品外部無法修改我們沒有暴露出來的變量、函數

上述做法就是我們子產品化的基礎，目前，通行的JavaScript子產品規範主要有兩種：CommonJS和AMD

CommonJS

我們先從CommonJS談起，因為在網頁端沒有子產品化程式設計隻是頁面JavaScript邏輯複雜，但也可以工作下去，在伺服器端卻一定要有子產品，是以雖然JavaScript在web端發展這麼多年，第一個流行的子產品化規範卻由伺服器端的JavaScript應用帶來，CommonJS規範是由NodeJS發揚光大，這标志着JavaScript子產品化程式設計正式登上舞台。

1、定義子產品

根據CommonJS規範，一個單獨的檔案就是一個子產品。每一個子產品都是一個單獨的作用域，也就是說，在該子產品内部定義的變量，無法被其他子產品讀取，除非定義為global對象的屬性

2、子產品輸出：

子產品隻有一個出口，module.exports對象，我們需要把子產品希望輸出的内容放入該對象

3、加載子產品：

加載子產品使用require方法，該方法讀取一個檔案并執行，傳回檔案内部的module.exports對象

看個例子

//子產品定義 myModel.js

var name = 'Byron';

function printName(){
    console.log(name);
}

function printFullName(firstName){
    console.log(firstName + name);
}

module.exports = {
    printName: printName,
    printFullName: printFullName
}

//加載子產品

var nameModule = require('./myModel.js');

nameModule.printName();           

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22

不同的實作對require時的路徑有不同要求，一般情況可以省略js拓展名，可以使用相對路徑，也可以使用絕對路徑，甚至可以省略路徑直接使用子產品名（前提是該子產品是系統内置子產品）

尴尬的浏覽器

仔細看上面的代碼，會發現require是同步的。子產品系統需要同步讀取子產品檔案内容，并編譯執行以得到子產品接口。

這在伺服器端實作很簡單，也很自然，然而， 想在浏覽器端實作問題卻很多。

浏覽器端，加載JavaScript最佳、最容易的方式是在document中插入script 标簽。但腳本标簽天生異步，傳統CommonJS子產品在浏覽器環境中無法正常加載。

解決思路之一是，開發一個伺服器端元件，對子產品代碼作靜态分析，将子產品與它的依賴清單一起傳回給浏覽器端。 這很好使，但需要伺服器安裝額外的元件，并是以要調整一系列底層架構。

另一種解決思路是，用一套标準模闆來封裝子產品定義，但是對于子產品應該怎麼定義和怎麼加載，又産生的分歧：

AMD

AMD 即Asynchronous Module Definition，中文名是異步子產品定義的意思。它是一個在浏覽器端子產品化開發的規範

由于不是JavaScript原生支援，使用AMD規範進行頁面開發需要用到對應的庫函數，也就是大名鼎鼎RequireJS，實際上AMD 是 RequireJS 在推廣過程中對子產品定義的規範化的産出

requireJS主要解決兩個問題

1、多個js檔案可能有依賴關系，被依賴的檔案需要早于依賴它的檔案加載到浏覽器

2、js加載的時候浏覽器會停止頁面渲染，加載檔案越多，頁面失去響應時間越長

看一個使用requireJS的例子

// 定義子產品 myModule.js
define(['dependency'], function(){
    var name = 'Byron';
    function printName(){
        console.log(name);
    }

    return {
        printName: printName
    };
});

// 加載子產品
require(['myModule'], function (my){
　 my.printName();
});           

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16

文法

requireJS定義了一個函數 define，它是全局變量，用來定義子產品

define(id?, dependencies?, factory);

1. id：可選參數，用來定義子產品的辨別，如果沒有提供該參數，腳本檔案名（去掉拓展名）
2. dependencies：是一個目前子產品依賴的子產品名稱數組

3. factory：工廠方法，子產品初始化要執行的函數或對象。如果為函數，它應該隻被執行一次。如果是對象，此對象應該為子產品的輸出值

   在頁面上使用require函數加載子產品

require([dependencies], function(){});

require()函數接受兩個參數

1. 第一個參數是一個數組，表示所依賴的子產品
2. 第二個參數是一個回調函數，目前面指定的子產品都加載成功後，它将被調用。加載的子產品會以參數形式傳入該函數，進而在回調函數内部就可以使用這些子產品

require()函數在加載依賴的函數的時候是異步加載的，這樣浏覽器不會失去響應，它指定的回調函數，隻有前面的子產品都加載成功後，才會運作，解決了依賴性的問題。

CMD

CMD 即Common Module Definition通用子產品定義，CMD規範是國内發展出來的，就像AMD有個requireJS，CMD有個浏覽器的實作SeaJS，SeaJS要解決的問題和requireJS一樣，隻不過在子產品定義方式和子產品加載（可以說運作、解析）時機上有所不同

文法

Sea.js 推崇一個子產品一個檔案，遵循統一的寫法

define(id?, deps?, factory)

因為CMD推崇

1. 一個檔案一個子產品，是以經常就用檔案名作為子產品id
2. CMD推崇依賴就近，是以一般不在define的參數中寫依賴，在factory中寫

factory是一個函數，有三個參數，function(require, exports, module)

1. require 是一個方法，接受 子產品辨別 作為唯一參數，用來擷取其他子產品提供的接口：require(id)
2. exports 是一個對象，用來向外提供子產品接口
3. module 是一個對象，上面存儲了與目前子產品相關聯的一些屬性和方法

看個例子：

// 定義子產品  myModule.js
define(function(require, exports, module) {
  var $ = require('jquery.js')
  $('div').addClass('active');
});

// 加載子產品
seajs.use(['myModule.js'], function(my){

});           

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10

AMD與CMD差別

關于這兩個的差別網上可以搜出一堆文章，簡單總結一下

最明顯的差別就是在子產品定義時對依賴的處理不同

1、AMD推崇依賴前置，在定義子產品的時候就要聲明其依賴的子產品

2、CMD推崇就近依賴，隻有在用到某個子產品的時候再去require

這種差別各有優劣，隻是文法上的差距，而且requireJS和SeaJS都支援對方的寫法

AMD和CMD最大的差別是對依賴子產品的執行時機處理不同，注意不是加載的時機或者方式不同

很多人說requireJS是異步加載子產品，SeaJS是同步加載子產品，這麼了解實際上是不準确的，其實加載子產品都是異步的，隻不過AMD依賴前置，js可以友善知道依賴子產品是誰，立即加載，而CMD就近依賴，需要使用把子產品變為字元串解析一遍才知道依賴了那些子產品，這也是很多人诟病CMD的一點，犧牲性能來帶來開發的便利性，實際上解析子產品用的時間短到可以忽略

為什麼我們說兩個的差別是依賴子產品執行時機不同，為什麼很多人認為ADM是異步的，CMD是同步的（除了名字的原因。。。）

同樣都是異步加載子產品，AMD在加載子產品完成後就會執行改子產品，所有子產品都加載執行完後會進入require的回調函數，執行主邏輯，這樣的效果就是依賴子產品的執行順序和書寫順序不一定一緻，看網絡速度，哪個先下載下傳下來，哪個先執行，但是主邏輯一定在所有依賴加載完成後才執行

CMD加載完某個依賴子產品後并不執行，隻是下載下傳而已，在所有依賴子產品加載完成後進入主邏輯，遇到require語句的時候才執行對應的子產品，這樣子產品的執行順序和書寫順序是完全一緻的

這也是很多人說AMD使用者體驗好，因為沒有延遲，依賴子產品提前執行了，CMD性能好，因為隻有使用者需要的時候才執行的原因