var v1 = "dep1"
function dep1(){
    return v1+"-"+dep2()
}

文件dep2.js

var v2 = "dep2"
function dep2(){
    return v2
}

當使用瀏覽器加載index.html文件時，如我所愿，它會隨后加載dep2,dep1,并調用函數dep1，后者調用dep2，然后在控制臺輸出：

dep1+dep2

功能是有效的，依賴關系是是對的，輸出也是如期望的。但是它也帶來了額外的問題：

全局變量污染。在本案例中，可以在console內驗證，發現變量v1，v2，函數dep1，dep2都是全局變量。但是由于script的加載機制，以及當前采用的Javascript函數和變量的定義不是局部化的，導致了這樣的問題。

依賴關系并不嚴密。事實上，dep2內的引入變量和函數，只有dep1看得到即可，無需導入到全局變量內。

加載和執行效率難以細顆粒度的調優。本例內，dep1依賴dep2，它們被并行轉入，但是執行必須是串行的，首先執行dep2，然后執行dep1，在此案例中，這樣做是合適的，但是有不少代碼模塊之間并不存在依賴關系，它們完全可能并發裝入并發執行，但是使用script裝入是不能如此的，它會按照標簽的次序一個個的執行。如果有比較好的指定依賴關系的方法就好了。

討論到此，我感覺我在重復先輩們的話，實際上1960年代，第一屆軟件工程會議，就提出了模塊化編程的概念，并且在之后多年一直努力的批評全局變量和Goto語句了。有時候，你會發現，這樣看起來非常不濟的語言，卻可以在現實的項目中如魚得水，發展的非常的好。而軟件工程思想指導下的一些名流語言卻早早夭折。這是另外一個有趣的話題了，或許以后有機會談到。

后端Nodejs干凈利索的解決了此問題。做法就是對每一個裝入的模塊都注入一個require函數和一個exports對象。其中require函數可以被模塊用來引入其他模塊，而exports對象則被用來引出當前模塊的功能接口。還是以前文提到的作為案例，做法就是：

文件index.js

// index.js
var d = require("./dep1")
console.log(d.dep1())

文件dep1.js

var d = require("./dep2")
var v1 = "dep1"
function dep1(){
    return v1+"-"+d.dep2()
}
exports.dep1 = dep1

文件dep2.js

var v2 = "dep2"
function dep2(){
    return v2
}
exports.dep2 = dep2

執行命令：

$ node index.js 
dep1-dep2

這里有一點變化，就是在nodejs內使用index.js代替了index.html。可以看到：

Nodejs提供了很好的局部化定義變量和函數的能力，如果使用exports聲明引出，其他模塊看不到本模塊的定義。比如v2變量沒有聲明引出，當然實際上在本案例內本來也不必引出，那么在dep1內并不會看到v2變量。類似的v1也不會出現在index.js內。

Nodejs提供了更加細粒度的依賴關系。index.js依賴dep1，但是并不依賴于dep2，那么index.js就只要引入dep1，而不必同時引入dep2。這樣的依賴關系，更加符合實際工程代碼的需求，而不是一股腦的、不分層次的引入全部需要用到的代碼。

在傳統的服務器開發的諸多語言中，模塊都是最基礎也是最必備的，像是JavaScript連個內置模塊支持都沒有的是不常見的（或者說根本沒有？）。使用諸如的require和exports，就在后端干凈利索的解決了困惱前端的模塊問題，這不免讓前端覺得應該效仿之。當然，Nodejs加載模塊是同步的，這個是不能在前端效仿的。因為后端從磁盤加載代碼，速度根本不是問題，而前端加載的都是從網絡上進行的， 如果同步的話，加上Javas本身的單線程限定，整個UI就會因為加載代碼而被卡死的。對比下兩者的速度差異，你就明白了：

硬盤 I/O        
-----------------
HDD:    100 MB/s    
SSD:    600 MB/s    
SATA-III:    6000 Mb/s    
-----------------
網速 I/O
ADSL:    4 Mb/s
4G:    100 Mb/s
Fiber:    100 Mb/s

思路倒也簡單，只要自己編寫一個庫，有它來異步加載其他模塊，并在加載時注入需要的require和exports即可。這方面的庫有幾個，比如requirejs，sea.js等。因為我們只是為了講清楚概念和思路，因此會那概念上最清晰，和Nodejs最為一致的庫來說明問題,并不會因為那個更加主流而去選擇它。從這個標準看，sea.js是說明概念問題的最佳模塊裝入庫。

sea.js 是一個模塊加載器，模塊加載器需要實現兩個基本功能：

實現模塊定義規范

加載運行符合規范的模塊

核心落腳點，就在規范二字上。sea.js要求模塊編寫必須在真正的代碼之外套上一層規定的代碼包裝，樣子看起來是這樣的：

define(function(require, exports, module) {
    // 模塊代碼
});

通過傳遞一個簽名為function(require, exports, module)的回調函數給define函數，就可以把需要注入的變量和函數注入到模塊代碼內。之前的實例代碼，在這里寫成：

文件index.js

// index.js
define(function(require, exports, module) {
    var d = require("./dep1")
    console.log(d.dep1())
});

文件dep1.js

define(function(require, exports, module) {
    var d = require("./dep2")
    var v1 = "dep1"
    function dep1(){
        return v1+"-"+d.dep2()
    }
    exports.dep1 = dep1
});

文件dep2.js

define(function(require, exports, module) {
    var v2 = "dep2"
    function dep2(){
        return v2
    }
    exports.dep2 = dep2
});

除了加上一層有點看起來莫名其妙的外套代碼，其他的模塊代碼，你該怎么寫就怎么寫。倘若不是那么潔癖，這樣的代碼確實解決了之前使用script標簽加載代碼帶來的全局變量污染等問題，并且還是可以異步加載的，那些看起來不錯的依賴關系，也如Nodejs一樣。以上代碼，可以直接把nodejs對應的代碼拷貝過來，加上外套即可運行。

我們不妨加入seajs文件，來看看實際的使用效果:

//index.html

這里為了偷懶，我使用了seajs的CDN文件。如果有遇到什么問題，你不妨自己下載一個seajs文件，然后改成你的URL即可。

加載此HTML文件，可以在控制臺看到輸出：

dep1+dep2

說明seajs執行效果不錯！

seajs通過use方法來加載入口模塊，可選接收一個回調函數，當模塊加載完成會調用此回調函數，并傳入對應的模塊作為參數

來獲取到模塊后，等待模塊（包括模塊依賴的模塊）加載完成會調用回調函數。

分析模塊的依賴，按依賴關系遞歸執行document.createElement(‘script’)，這些標簽的創建會導致瀏覽器加載對應的腳本

對模塊的價值，都是異步加載，瀏覽器不會失去響應，它指定的回調函數，只有前面的模塊都加載成功后，才會運行，解決了依賴性的問題。

可以在控制臺輸入：

seajs.data.fetchedList

查看文件加載清單。

因為不是語言自帶，而是社區通過現有的語言特性，硬造出來的一個模塊系統，因為看起來代碼不免累贅。但是在沒有原生模塊的情況下，這樣做確實是管用的。要知道真正的原生模塊，在ES6標準之后才出現，這都是2015年的事兒了。在一些有名的應用如Gmail、Google Map的推動下，Web從簡單的展示到App的變化，迫切需要這樣類似的模塊技術，大家等不了那么久，先弄一個能用的是很重要的。

為什么要套這層外殼呢？就是為了解決全局變量污染問題。在JavaScript語言內，唯一提供本地作用域的就是函數和閉包，通過閉包function(require, exports, module),模塊加載器給模塊注入了必要的函數和變量。看起來在模塊之內的任何地方都可以使用require和exports，但是他沒都不是全局變量，而是閉包內變量。這些變量都是局部化的，絕對不會污染全局空間。

使用require函數，可以就近指定對其他模塊的依賴，函數本身是由sea.js這樣的模塊加載器提供，它會內部構造依賴關系圖譜，并根據依賴關系，設置加入script標簽的次序。

更加詳細的理解這層外殼，可以閱讀seajs源代碼，代碼量并不大，值得一讀?；蛘呖纯创藛柎?/p>

當然Seajs也引入了自己的規范，叫做CMD規范。它的前身是Modules/Wrappings規范。SeaJS更多地來自 Modules/2.0 的觀點，同時借鑒了 RequireJS 的不少東西，比如將Modules/Wrappings規范里的 module.declare改為define等。
說是規范，卻不像是一般的規范那么冗長，可能打印出來也就一兩頁的紙張而已，這也是JavaScript社區的一個特點吧。Modules/Wrappings

seajs的作者在一篇文章中提到了業界在開發前端模塊加載器時的場景：

大概 09 年 - 10 年期間，CommonJS 社區大牛云集。CommonJS 原來叫 ServerJS，推出 Modules/1.0 規范后，在 Node.js 等環境下取得了很不錯的實踐。09年下半年這幫充滿干勁的小伙子們想把 ServerJS 的成功經驗進一步推廣到瀏覽器端，于是將社區改名叫 CommonJS，同時激烈爭論 Modules 的下一版規范。分歧和沖突由此誕生，逐步形成了三大流派：

Modules/1.x 流派。這個觀點覺得 1.x 規范已經夠用，只要移植到瀏覽器端就好。要做的是新增 Modules/Transport 規范，即在瀏覽器上運行前，先通過轉換工具將模塊轉換為符合 Transport 規范的代碼。主流代表是服務端的開發人員?，F在值得關注的有兩個實現：越來越火的 component 和走在前沿的 es6 module transpiler。

Modules/Async 流派。這個觀點覺得瀏覽器有自身的特征，不應該直接用 Modules/1.x 規范。這個觀點下的典型代表是 AMD 規范及其實現 RequireJS。

Modules/2.0 流派。這個觀點覺得瀏覽器有自身的特征，不應該直接用 Modules/1.x 規范，但應該盡可能與 Modules/1.x 規范保持一致。這個觀點下的典型代表是 BravoJS 和 FlyScript 的作者。BravoJS 作者對 CommonJS 的社區的貢獻很大，這份 Modules/2.0-draft 規范花了很多心思。FlyScript 的作者提出了 Modules/Wrappings 規范，這規范是 CMD 規范的前身。可惜的是 BravoJS 太學院派，FlyScript 后來做了自我閹割，將整個網站（flyscript.org）下線了。這個故事有點悲壯，下文細說。

這個模塊加載器是更加主流的。之所以不是首先提到它，是因為概念上來說seajs更加簡明。和seajs相比，requirejs是更加主流的框架。它的差異主要是一些零零散散的不同，比如模塊代碼的外套是不太一樣的：

require(["moduleA", "moduleB", "moduleC"], function (moduleA, moduleB, moduleC){

　　　　// some code here

});

導出模塊變量和函數的方式，也是不同的。requirejs的引出方式是直接返回：

return {foo:foo}

一樣的案例，使用requirejs的話，代碼是這樣的：

index.html文件

index.js文件：

require(["./dep1"], function (d){
    console.log(d.dep1())        
});

dep1.js文件：

define(["./dep2"], function (d){
    var v1 = "dep1"
    function dep1(){
        return v1+"-"+d.dep2()
    }
    return {dep1:dep1}
});

dep2.js文件：

define(function() {
    var v2 = "dep2"
    function dep2(){
        return v2
    }
    return {dep2:dep2}
});

瀏覽器打開文件index.html，可以看到控制臺輸出一樣的結果。

稍加對比require.js和sea.js。使用Require.js，默認推薦的模塊格式是：

define(["a","b"], function(a, b) {
  // do sth
})

使用seajs的時候，類似的功能，代碼這樣寫：

define(function(require, exports, module) {
  var a = require("a")
  var b = require("b")
  // do sth
  ...
})

Seajs的做法是更加現代的。我需要用的時候，我才去引用它，而不是實現什么都引用好，然后用的時候直接用就好。

以require.js為代表的Modules/Async流派，尊重了瀏覽器的特殊性，代價是不管寫什么模塊，都得自己給自己穿上一層外套，對于有代碼潔癖的人來說，這樣的情況是看不下去的。最好是開發人員編寫干干凈凈的模塊代碼，框架開發者做一個工具，這個工具自動的把這些代碼轉義成客戶端認可的異步代碼。即在瀏覽器上運行前，先通過轉換工具將模塊轉換為符合規范的代碼。這就是Modules/1.x 流派的做法。需要注意的是1.x和2.0還有Async流派不能簡單的認為版本號大的就更好。倒是理解成各自不同的解決方案為好。

以我們自己的案例來說，就是可以直接把nodejs代碼那里，使用一個工具做一個轉換，即可得到符合前端需要的代碼，這些代碼是異步加載的、是可以保證模塊變量局部化的、是可以由良好的依賴關系定義的。工具browerfy就是做這個的。我們來試試具體是怎么玩的。

首先安裝此工具：

npm install --global browserify

到你的nodejs代碼內，然后轉換此代碼，生成一個新的js文件，一般命名為bundle.js：

browserify index.js -o bundle.js

然后創建index.html并引入bundle.js:

使用瀏覽器打開此HTML文件，可以在控制臺看到熟悉的輸出,這說明轉換是有效的：

dep1+dep2

本身nodejs的代碼，是不能在瀏覽器執行的，瀏覽器內也沒有什么require函數，但是轉換后就可以執行了。那么，轉換的過程，到底玩了什么魔術？

像是browserify這樣的工具，就是找到全面被引入的代碼，解析它的依賴關系，并且自動的加入我們在requirejs里面需要的外套代碼。盡管bundle.js文件并不是為了閱讀優化的，但是可以取出其中的代碼片段來證實我們的觀點：

{"./dep2":2}],2:[function(require,module,exports){
        var v2 = "dep2"
        function dep2(){
            return v2
        }
        exports.dep2 = dep2
},{}],3:[function(require,module,exports){
        var d = require("./dep1")
        console.log(d.dep1())
},{"./dep1":1}]},{},[3]);

我們可以看到本來的nodejs代碼，以及它們對應的外套。還是比較簡單，就不進一步解釋了。browserify不但完成了加外套代碼的工作，還同時把若干小文件打成一個大的文件，對于當前使用的HTTP主流版本1.1來說，這樣做會讓加載效率更高。但是對于HTTP/2.0來說，它已經支持了多個文件在一個連接內交錯傳遞，因此再做打包的意義就不大了。只是...HTTP/2.0的普及還需要時日。

browerify完成的工作簡明而單一。另外一個主流的同類工具叫做webpack，不但可以轉換js代碼，還可以打包css文件、圖片文件，并且可以做一些工程化的管理，代價就是webpack學起來也困難的多。實際上像是Vuejs這樣的UI開發框架，內部就是使用了webpack做工程化管理和代碼轉譯的。但是在模塊化方面，兩者是差不多的。就不另外介紹了。

時間到了May 9, 2018，我看到了阮一峰發布了這樣的微博：

今天 Firefox 60發布，默認打開了ES6 模塊支持，至此所有瀏覽器都默認支持ES6模塊。前端開發模式可能因此大變?，F在的方案是所有模塊發到npm，本地寫好入口文件，再用webpack打包成一個腳本。但是如果瀏覽器原生支持，為什么還要打包呢？至少簡單的應用可以直接加載入口文件，瀏覽器自己去抓取依賴。 ????

這里所有瀏覽器指的是Edge、Firefox、Chrome、Safari。當然，再一次沒有IE。如果想要支持IE或者比較老的版本的話，還是需要使用打包器來完成代碼的轉譯。另外很多人表示會繼續使用Webpack，原因很簡單，Webpack不僅僅是完成模塊打包工作，還有壓縮、混淆等，并且很多框架還需要依賴它。所以遷移并非一朝一夕之功。而無需考慮老版本瀏覽器的兼容的代碼，是完全可以大量的使用它了。了不起在把Webpack加起來轉換ES Module到加外套的代碼就是了。

ES6 Module不是requirejs那樣加外套的樣子，也不是Nodejs使用require函數的樣子，而是另外一套有官方提出的模塊模式。它使用的是import、export關鍵字。官方的就是不一樣，社區是加不了關鍵字的。同樣的案例，使用ES6 Module就是這樣的了。

index.html文件：

dep1.js文件

    import {dep2} from "./dep2.js"
    var v1 = "dep1"
    export function dep1(){
        return v1+"-"+dep2()
    }
    

dep2.js文件：

    var v2 = "dep2"
    export function dep2(){
        return v2
    }

ES6 Module要求必須有后臺的HTTP服務器，而不能直接在文件系統上完成Demo的測試。所幸使用Nodejs搭建一個服務器也非常簡單直接：

npm i http-server -g
http-server

在瀏覽器內訪問此HTML文件的URL，可以看到控制臺輸出:dep1+dep2。這個輸出，已經是你的老朋友了。

Nodejs在10.9才支持實驗版本的ES6 Module，是落后了點，但是對于Nodejs來說，新的模塊技術本來也就并不迫切。

綜合以上的內容，我認為，在不必考慮古老的瀏覽器兼容的情況下，最好的實踐是這樣的：

直接使用ES6 Module編寫模塊代碼

使用Rollup清除沒有調用的代碼，降低代碼的大小

使用Ugly工具壓縮和混淆代碼

使用HTTP/2做網絡傳遞協議

這樣的實踐，會隨著HTTP/2的逐步普及和ES6被更多的開發者采用，而成為更好的選擇。

使用ES6 Module的壞處是無法像require那樣動態的加載。但是好處是可以精確指明對于一個庫，我們使用的是那些，這就給工具提供了優化的可能，就是說如果我引入了一個庫，但是這個庫內有些我不會用的，那么這些不會被用到的代碼也不會加載到前端了。這個功能對于后端來說意義不大，但是對于前端來說，就是非常令人喜歡的功能了。實際上，這樣的工具已經有了，比較知名的就是rollup，它屬于了一種被稱為tree-shaking的技術優化使用代碼。

而以往做模塊打包，很多的原因是HTTP/1.1傳遞大量小文件的時候開銷比較大，而打包成單一的問題，就可以更好的利用HTTP/1.1的傳輸特性。但是HTTP/2.0的一個大的特色就是可以在單一的連接內，并發和交錯的傳遞多個流，因為在一個連接內交錯的傳遞多個文件，就可以不再有HTTP/1.1的連接開銷了。因此，在HTTP/2.0被采納的網絡里面，打包單一文件的價值幾乎沒有了。直接使用小文件默認情況下就可以得到比較好的優化傳輸。

按照現在的技術發展的勢頭，要不了幾年，打包器將不再那么必要，使用原生代碼編寫模塊將會成為主流的。

參考文章不少,其中模塊歷史和選型如下：

前端模塊化開發那點歷史

梳理的還是比較清晰

有點黑客精神的小伙伴，玩的很廣譜

介紹Bower

npm for Beginners: A Guide for Front-end Developers

Es6module 出來了，是否應該重新考慮打包的方案？

這篇文章預計想要編寫的YUI方法，YUI Combo方法，想了想還是算了，因為這樣的恐龍代碼，已經在日常的代碼實踐中逐步消失，作為一個曾經比較重要，現在則退居二線的代碼庫，對它最好的贊許就是讓它退休，也不必給讀者增加額外的閱讀負擔了。畢竟require.js、browerify、webpack都工作的不錯，在此基礎上發展的Vuejs、React.js也的得到了更多的認可。

本文講到的模塊規范和實踐工具，為編寫一個廣為社區認可的模塊起到了最基礎的規范作用。但是，JavaScript社區最為令人稱道的就是代碼庫倉庫。包括NPM倉庫，Bower倉庫。在這些倉庫內，有模塊依賴管理工具，還有工程化工具。這些內容，它們當然是重要的，不在本文的范圍內。

作為前端開發者，有人采用Bower管理組件依賴，也有人使用Npm做類似的工作。有很多時候，這樣的實踐是令人困惑的。還有這里npm and the front end,NPM官方也對npm在前端的使用，提出了自己的看法。

這些未盡的內容，或許在未來的文章中表達之。