js子產品化程式設計之CommonJS和AMD/CMD

一、CommonJS

1.CommonJS API定義很多普通應用程式（主要指非浏覽器的應用）使用的API，進而填補了這個空白。它的終極目标是提供一個類似Python，Ruby和Java标準庫。這樣的話，開發者可以使用CommonJS API編寫應用程式，然後這些應用可以運作在不同的JavaScript解釋器和不同的主機環境中。

在相容CommonJS的系統中，你可以使用JavaScript開發以下程式：

(1).伺服器端JavaScript應用程式

(2).指令行工具

(3).圖形界面應用程式

(4).混合應用程式（如，Titanium或Adobe AIR）

2009年，美國程式員Ryan Dahl創造了node.js項目，将javascript語言用于伺服器端程式設計。這标志"Javascript子產品化程式設計"正式誕生。因為老實說，在浏覽器環境下，沒有子產品也不是特别大的問題，畢竟網頁程式的複雜性有限；但是在伺服器端，一定要有子產品，與作業系統和其他應用程式互動，否則根本沒法程式設計。NodeJS是CommonJS規範的實作，webpack 也是以CommonJS的形式來書寫。

node.js的子產品系統，就是參照CommonJS規範實作的。在CommonJS中，有一個全局性方法require()，用于加載子產品。假定有一個數學子產品math.js，就可以像下面這樣加載。

var math = require('math');

然後，就可以調用子產品提供的方法：

　　var math = require('math');       math.add(2,3); // 5

CommonJS定義的子產品分為:{子產品引用(require)} {子產品定義(exports)} {子產品辨別(module)}

require()用來引入外部子產品；exports對象用于導出目前子產品的方法或變量，唯一的導出口；module對象就代表子產品本身。

雖說Node遵循CommonJS的規範，但是相比也是做了一些取舍，填了一些新東西的。

不過，說了CommonJS也說了Node，那麼我覺得也得先了解下NPM了。NPM作為Node的包管理器，不是為了幫助Node解決依賴包的安裝問題嘛，那它肯定也要遵循CommonJS規範啦，它遵循包規範（還是理論）的。CommonJS WIKI講了它的曆史，還介紹了modules和packages等。

下面講講commonJS的原理以及簡易實作：

浏覽器不相容CommonJS的根本原因，在于缺少四個Node.js環境的變量。

module exports require global

隻要能夠提供這四個變量，浏覽器就能加載 CommonJS 子產品。

下面是一個簡單的示例。

上面代碼向一個立即執行函數提供 module 和 exports 兩個外部變量，子產品就放在這個立即執行函數裡面。子產品的輸出值放在 module.exports 之中，這樣就實作了子產品的加載。

知道了原理，就能做出工具了。Browserify 是目前最常用的 CommonJS 格式轉換的工具。

請看一個例子，main.js 子產品加載 foo.js 子產品。

使用下面的指令，就能将main.js轉為浏覽器可用的格式。

Browserify到底做了什麼？安裝一下browser-unpack，就能看清楚了。

然後，将前面生成的compile.js解包。

可以看到，browerify 将所有子產品放入一個數組，id 屬性是子產品的編号，source 屬性是子產品的源碼，deps 屬性是子產品的依賴。

因為 main.js 裡面加載了 foo.js，是以 deps 屬性就指定 ./foo 對應1号子產品。執行的時候，浏覽器遇到 require('./foo') 語句，就自動執行1号子產品的 source 屬性，并将執行後的 module.exports 屬性值輸出。

雖然 Browserify 很強大，但不能在浏覽器裡操作，有時就很不友善。

我根據 mocha 的内部實作，做了一個純浏覽器的 CommonJS 子產品加載器 tiny-browser-require 。完全不需要指令行，直接放進浏覽器即可，所有代碼隻有30多行。

它的邏輯非常簡單，就是把子產品讀入數組，加載路徑就是子產品的id。

使用的時候，先将上面的代碼放入頁面。然後，将子產品放在如下的立即執行函數裡面，就可以調用了。

還是以前面的 main.js 加載 foo.js 為例。

注意，這個庫隻模拟了 require 、module 、exports 三個變量，如果子產品還用到了 global 或者其他 Node 專有變量（比如 process），就通過立即執行函數提供即可。

二、AMD

基于commonJS規範的nodeJS出來以後，服務端的子產品概念已經形成，很自然地，大家就想要用戶端子產品。而且最好兩者能夠相容，一個子產品不用修改，在伺服器和浏覽器都可以運作。但是，由于一個重大的局限，使得CommonJS規範不适用于浏覽器環境。還是上面的代碼，如果在浏覽器中運作，會有一個很大的問題，你能看出來嗎？

　　math.add(2, 3);

第二行math.add(2, 3)，在第一行require('math')之後運作，是以必須等math.js加載完成。也就是說，如果加載時間很長，整個應用就會停在那裡等。您會注意到 <code>require</code> 是同步的。

這對伺服器端不是一個問題，因為所有的子產品都存放在本地硬碟，可以同步加載完成，等待時間就是硬碟的讀取時間。但是，對于浏覽器，這卻是一個大問題，因為子產品都放在伺服器端，等待時間取決于網速的快慢，可能要等很長時間，浏覽器處于"假死"狀态。

是以，浏覽器端的子產品，不能采用"同步加載"（synchronous），隻能采用"異步加載"（asynchronous）。這就是AMD規範誕生的背景。

CommonJS是主要為了JS在後端的表現制定的，他是不适合前端的，AMD(異步子產品定義)出現了，它就主要為前端JS的表現制定規範。

AMD是"Asynchronous Module Definition"的縮寫，意思就是"異步子產品定義"。它采用異步方式加載子產品，子產品的加載不影響它後面語句的運作。所有依賴這個子產品的語句，都定義在一個回調函數中，等到加載完成之後，這個回調函數才會運作。

AMD也采用require()語句加載子產品，但是不同于CommonJS，它要求兩個參數：

　　require([module], callback);

第一個參數[module]，是一個數組，裡面的成員就是要加載的子產品；第二個參數callback，則是加載成功之後的回調函數。如果将前面的代碼改寫成AMD形式，就是下面這樣：

　　require(['math'], function (math) { 　　　　math.add(2, 3); 　　});

math.add()與math子產品加載不是同步的，浏覽器不會發生假死。是以很顯然，AMD比較适合浏覽器環境。目前，主要有兩個Javascript庫實作了AMD規範：require.js和curl.js。

RequireJS就是實作了AMD規範的呢。

詳細概括：下面以RequireJS為例說明AMD規範

一、為什麼要用require.js？

最早的時候，所有Javascript代碼都寫在一個檔案裡面，隻要加載這一個檔案就夠了。後來，代碼越來越多，一個檔案不夠了，必須分成多個檔案，依次加載。下面的網頁代碼，相信很多人都見過。

　　&lt;script src="1.js"&gt;&lt;/script&gt; 　　&lt;script src="2.js"&gt;&lt;/script&gt; 　　&lt;script src="3.js"&gt;&lt;/script&gt; 　　&lt;script src="4.js"&gt;&lt;/script&gt; 　　&lt;script src="5.js"&gt;&lt;/script&gt; 　　&lt;script src="6.js"&gt;&lt;/script&gt;

這段代碼依次加載多個js檔案。

這樣的寫法有很大的缺點。首先，加載的時候，浏覽器會停止網頁渲染，加載檔案越多，網頁失去響應的時間就會越長；其次，由于js檔案之間存在依賴關系，是以必須嚴格保證加載順序（比如上例的1.js要在2.js的前面），依賴性最大的子產品一定要放到最後加載，當依賴關系很複雜的時候，代碼的編寫和維護都會變得困難。

require.js的誕生，就是為了解決這兩個問題：

　　（1）實作js檔案的異步加載，避免網頁失去響應； 　　（2）管理子產品之間的依賴性，便于代碼的編寫和維護。

二、require.js的加載

使用require.js的第一步，是先去官方網站下載下傳最新版本。

下載下傳後，假定把它放在js子目錄下面，就可以加載了。

　　&lt;script src="js/require.js"&gt;&lt;/script&gt;

有人可能會想到，加載這個檔案，也可能造成網頁失去響應。解決辦法有兩個，一個是把它放在網頁底部加載，另一個是寫成下面這樣：

　　&lt;script src="js/require.js" defer async="true" &gt;&lt;/script&gt;

async屬性表明這個檔案需要異步加載，避免網頁失去響應。IE不支援這個屬性，隻支援defer，是以把defer也寫上。

加載require.js以後，下一步就要加載我們自己的代碼了。假定我們自己的代碼檔案是main.js，也放在js目錄下面。那麼，隻需要寫成下面這樣就行了：

　　&lt;script src="js/require.js" data-main="js/main"&gt;&lt;/script&gt;

data-main屬性的作用是，指定網頁程式的主子產品。在上例中，就是js目錄下面的main.js，這個檔案會第一個被require.js加載。由于require.js預設的檔案字尾名是js，是以可以把main.js簡寫成main。

三、主子產品的寫法

上一節的main.js，我把它稱為"主子產品"，意思是整個網頁的入口代碼。它有點像C語言的main()函數，所有代碼都從這兒開始運作。

下面就來看，怎麼寫main.js。

如果我們的代碼不依賴任何其他子產品，那麼可以直接寫入javascript代碼。

　　// main.js 　　alert("加載成功！");

但這樣的話，就沒必要使用require.js了。真正常見的情況是，主子產品依賴于其他子產品，這時就要使用AMD規範定義的的require()函數。

　　require(['moduleA', 'moduleB', 'moduleC'], function (moduleA, moduleB, moduleC){ 　　　　// some code here

require()函數接受兩個參數。第一個參數是一個數組，表示所依賴的子產品，上例就是['moduleA', 'moduleB', 'moduleC']，即主子產品依賴這三個子產品；第二個參數是一個回調函數，目前面指定的子產品都加載成功後，它将被調用。加載的子產品會以參數形式傳入該函數，進而在回調函數内部就可以使用這些子產品。

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

下面，我們看一個實際的例子。

假定主子產品依賴jquery、underscore和backbone這三個子產品，main.js就可以這樣寫：

　　require(['jquery', 'underscore', 'backbone'], function ($, _, Backbone){

require.js會先加載jQuery、underscore和backbone，然後再運作回調函數。主子產品的代碼就寫在回調函數中。

四、子產品的加載

上一節最後的示例中，主子產品的依賴子產品是['jquery', 'underscore', 'backbone']。預設情況下，require.js假定這三個子產品與main.js在同一個目錄，檔案名分别為jquery.js，underscore.js和backbone.js，然後自動加載。

使用require.config()方法，我們可以對子產品的加載行為進行自定義。require.config()就寫在主子產品（main.js）的頭部。參數就是一個對象，這個對象的paths屬性指定各個子產品的加載路徑。

　　require.config({ 　　　　paths: { 　　　　　　"jquery": "jquery.min", 　　　　　　"underscore": "underscore.min", 　　　　　　"backbone": "backbone.min" 　　　　}

上面的代碼給出了三個子產品的檔案名，路徑預設與main.js在同一個目錄（js子目錄）。如果這些子產品在其他目錄，比如js/lib目錄，則有兩種寫法。一種是逐一指定路徑。

　　　　　　"jquery": "lib/jquery.min", 　　　　　　"underscore": "lib/underscore.min", 　　　　　　"backbone": "lib/backbone.min"

另一種則是直接改變基目錄（baseUrl）。

　　　　baseUrl: "js/lib",

如果某個子產品在另一台主機上，也可以直接指定它的網址，比如：

　　　　　　"jquery": "https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min"

require.js要求，每個子產品是一個單獨的js檔案。這樣的話，如果加載多個子產品，就會發出多次HTTP請求，會影響網頁的加載速度。是以，require.js提供了一個優化工具，當子產品部署完畢以後，可以用這個工具将多個子產品合并在一個檔案中，減少HTTP請求數。

五、AMD子產品的寫法

require.js加載的子產品，采用AMD規範。也就是說，子產品必須按照AMD的規定來寫。

具體來說，就是子產品必須采用特定的define()函數來定義。如果一個子產品不依賴其他子產品，那麼可以直接定義在define()函數之中。

假定現在有一個math.js檔案，它定義了一個math子產品。那麼，math.js就要這樣寫：

　　// math.js 　　define(function (){ 　　　　var add = function (x,y){ 　　　　　　return x+y; 　　　　}; 　　　　return { 　　　　　　add: add

加載方法如下：

　　require(['math'], function (math){ 　　　　alert(math.add(1,1));

如果這個子產品還依賴其他子產品，那麼define()函數的第一個參數，必須是一個數組，指明該子產品的依賴性。

　　define(['myLib'], function(myLib){ 　　　　function foo(){ 　　　　　　myLib.doSomething(); 　　　　　　foo : foo

當require()函數加載上面這個子產品的時候，就會先加載myLib.js檔案。

六、加載非規範的子產品

理論上，require.js加載的子產品，必須是按照AMD規範、用define()函數定義的子產品。但是實際上，雖然已經有一部分流行的函數庫（比如jQuery）符合AMD規範，更多的庫并不符合。那麼，require.js是否能夠加載非規範的子產品呢？

回答是可以的。

這樣的子產品在用require()加載之前，要先用require.config()方法，定義它們的一些特征。

舉例來說，underscore和backbone這兩個庫，都沒有采用AMD規範編寫。如果要加載它們的話，必須先定義它們的特征。

　　　　shim: { 　　　　　　'underscore':{ 　　　　　　　　exports: '_' 　　　　　　}, 　　　　　　'backbone': { 　　　　　　　　deps: ['underscore', 'jquery'], 　　　　　　　　exports: 'Backbone' 　　　　　　}

require.config()接受一個配置對象，這個對象除了有前面說過的paths屬性之外，還有一個shim屬性，專門用來配置不相容的子產品。具體來說，每個子產品要定義（1）exports值（輸出的變量名），表明這個子產品外部調用時的名稱；（2）deps數組，表明該子產品的依賴性。

比如，jQuery的插件可以這樣定義：

　　shim: { 　　　　'jquery.scroll': { 　　　　　　deps: ['jquery'], 　　　　　　exports: 'jQuery.fn.scroll' 　　}

七、require.js插件

require.js還提供一系列插件，實作一些特定的功能。

domready插件，可以讓回調函數在頁面DOM結構加載完成後再運作。

　　require(['domready!'], function (doc){ 　　　　// called once the DOM is ready

text和image插件，則是允許require.js加載文本和圖檔檔案。

　　define([ 　　　　'text!review.txt', 　　　　'image!cat.jpg' 　　　　], 　　　　function(review,cat){ 　　　　　　console.log(review); 　　　　　　document.body.appendChild(cat); 　　);

類似的插件還有json和mdown，用于加載json檔案和markdown檔案。（完）

另一個人的概括(有點簡單)：

AMD就隻有一個接口：define(id?,dependencies?,factory);

它要在聲明子產品的時候制定所有的依賴(dep)，并且還要當做形參傳到factory中，像這樣：

要是沒什麼依賴，就定義簡單的子產品，下面這樣就可以啦：

咦，這裡有define，把東西包裝起來啦，那Node實作中怎麼沒看到有define關鍵字呢，它也要把東西包裝起來呀，其實吧，隻是Node隐式包裝了而已.....

這有AMD的WIKI中文版，講了很多蠻詳細的東西，用到的時候可以檢視：AMD的WIKI中文版

三、CMD

大名遠揚的玉伯寫了seajs，就是遵循他提出的CMD規範，與AMD蠻相近的，不過用起來感覺更加友善些，最重要的是中文版，應有盡有：seajs官方doc