JS本身是一個多才多藝的語言，一個可以用自己編譯自己的自由度極高的語言。正因為這份自由，出現了天花亂墜的規范與框架們，其中最基礎的一塊便是Module。

來來來，baby們，做個小測試： CommonJS·AMD·CMD·UMD·ES6，這些模塊規范，大家熟悉幾個？

注意注意：本文乃筆者主觀寫出的歡快脫線認知，也許和真正的模塊形成的歷史有所區別。

一切的根源

JS是一個自由度極高的語言，即使沒有模塊的概念。也可以通過IIFE，new一個對象來實現類似與模塊的概念。也可以實現可復用，作用域獨立，易維護。這樣散裝的，無法維護各個模塊之間依賴。在一個JS文件中，模塊一多，也許就是修羅場。

Module的誕生

于是JS Module，一個令人又愛又恨的名詞誕生了。JS本身設計上就沒有模塊的概念，之后為了讓JS變成一個功能強大的語言，業界大佬們各顯神通，定了一個名為CommonJS的規范，實現了一個名為模塊的東西。可惜大多瀏覽器并不支持，只能用于nodejs，于是CommonJS開始分裂，變異了一個名為AMD規范的模塊，可以用于瀏覽器端，而由于AMD與CommonJS規范相去甚遠，于是AMD自立門戶，并且推出了requireJS這個框架，用于實現并推廣AMD規范。正因為AMD與CommonJS如此不同，且用于不同的環境，為了能夠兼容兩個平臺，UMD應運而生，不過筆者認為僅僅是一個polyfill，以兼容兩個平臺。此時，CommonJS的擁護者認為，瀏覽端也可以實現CommonJS的規范，于是稍作改動，形成了CMD規范，并且推出了seajs這個框架。正在AMD與CMD打得火熱的時候，ECMAScript6給JS本身定了一個模塊加載的功能，ES6表示“你們也別爭了，JS模塊有原生的語法了”。

真正的規范

對于眾多規范中，只有CommonJS和ES6 import/export是真正的規范，其余的是利用JS現有的支持的方法模擬出的環境，以實現各自的規范。

至于為什么說CommonJS和ES6 import/export是真正的規范呢？因為只有原生支持他們的語法，才能實現他們的規范。

對于CommonJS而言，運行環境中，必須有require和module.exports的支持，才能運行。這就是瀏覽器與CommonJS無緣的主要原因。

至于ES6，失去對import和export關鍵字的支持，便一切都是零。比如，nodejs就不支持import和export，明明nodejs支持其他的ES6語法，怎么就對import和export如此不友好，筆者認為nodejs是為了實現commonJS的規范，因此不能接受ES6的模塊擾亂nodejs的模塊規范。

所以說CommonJS和ES6的模塊才是真正的規范。

關于CommonJS和ES6模塊，筆者曾經寫過一篇關于他們的文章，這里不多做贅述,移步至讀懂CommonJS的模塊加載。

有關瀏覽器實現CommonJS模塊的原理

既然瀏覽器缺少CommonJS的兩個關鍵字導致，模塊不成立，那么就創建一個模塊環境。使用define這個方法，將函數內部模擬成CommonJS的環境，提供require和module.export的方法。無論是seajs還是requirejs都是通過define模擬環境的辦法，實現module的。