原文參考 玉伯 大神些的，我整理了一下。 咱們今天主題說下前端模塊化發展的歷史，主要就是針對AMD CMD 的發展，這兩個東西是一種規範，他們實際產物是 AMD是RequireJS，CMD的產物是seajs，他們的出現都是在COMMONjs基礎上發展而來的，那咱們得先說說COMMONjs。 COMM ...
原文參考 玉伯 大神些的，我整理了一下。
咱們今天主題說下前端模塊化發展的歷史，主要就是針對AMD CMD 的發展，這兩個東西是一種規範，他們實際產物是 AMD是RequireJS，CMD的產物是seajs，他們的出現都是在COMMONjs基礎上發展而來的，那咱們得先說說COMMONjs。
COMMONJS
大概 09 年 – 10 年期間，CommonJS 社區大牛雲集。CommonJS 原來叫 ServerJS，推出 Modules/1.0 規範後，在Node.js 環境下取得了很不錯的實踐。09年下半年這幫牛逼愛折騰的大神們想把 ServerJS 的成功經驗進一步推廣到瀏覽器端，於是將社區改名叫 CommonJS，同時激烈爭論 Modules 的下一版規範。分歧和衝突由此誕生，逐步形成了三大流派：Modules/1.x （完全基於1.0的功能，只是增加一個轉換功能），Modules/Async ，Modules/2.0 。
Modules/1.x 流派：這個觀點覺得 1.x 規範已經夠用，只要移植到瀏覽器端就好。要做的是新增 Modules/Transport 規範，即在瀏覽器上運行前，先通過轉換工具將模塊轉換為符合 Transport 規範的代碼。現在值得關註的有兩個實現：component 和es6 module。
Modules/Async 流派：這個觀點覺得瀏覽器有自身的特征，不應該直接用 Modules/1.x 規範。這個觀點下的典型代表是 AMD 規範及其實現 RequireJS。這個稍後再細說。
Modules/2.0 流派：這個觀點覺得瀏覽器有自身的特征，不應該直接用 Modules/1.x 規範，但應該儘可能與 Modules/1.x 規範保持一致。這個觀點下的典型代表是 BravoJS 和 FlyScript 的作者。BravoJS 作者對 CommonJS 的社區的貢獻很大。FlyScript 的作者提出了 Modules/Wrappings 規範，這規範是 CMD 規範的前身。可惜的是 BravoJS 太學院派，FlyScript 後來做了自我閹割，將整個網站（flyscript.org）下線了。這個故事有點悲壯，就不細講了。
上面是產生的三大流派，也就是說Modules/2.0開始的產物都無疾而終了 ，而當時Modules/1.x 規範的 ES6還不成熟，在後來就是以Modules/Async 為規範的 RequireJS 發展的很火熱。
但是AMD 的RequireJS 的 執行時機有異議，模塊書寫風格有爭議，一直沒有被CommonJS社區認同，咱們詳細的說下這兩個點：
AMD 里提前下載 a.js 是瀏覽器的限制，沒辦法做到同步下載，這個社區都認可，但執行，AMD 里是 提前執行，二在基礎Modules/1.0 規範里是第一次 require的時候才執行。這個差異很多人不能接受，包括持有Modules/2.0 觀點的人也不能接受AMD的這個觀點，這個差異，也導致實質上 Node 的模塊與 AMD 模塊是無法共用的，存在潛在衝突；
另外一個就是：模塊書寫風格有爭議
AMD 風格下，通過參數傳入依賴模塊，破壞了 就近聲明 原則，就近原則就是在用的時候才會用，而不需要提前聲明模塊。最後，AMD 從 CommonJS 社區獨立了出去，單獨成為了 AMD 社區，後來你們就知道了 RequireJS 特別火!
其實這個時候 脫離了 CommonJS 社區的 AMD 規範，實質上演化成了 RequireJS 的附屬品，後來RequireJS 社區有很多人反饋想用 require 的方式，最後 RequireJS 作者妥協，才有了這個半殘的支持。（註意這個是偽支持，背後依舊是 AMD 的運行邏輯，比如提前執行）AMD 的流行，很大程度上取決於 RequireJS 作者的推廣，AMD 規範的演進，離不開 RequireJS。
Modules/2.0
BravoJS 的作者 Wes Garland 有很深厚的程式功底，在 CommonJS 社區也非常受人尊敬。但 BravoJS 本身非常學院派，是為了論證 Modules/2.0-draft 規範而寫的一個項目。學院派在實用派的 RequireJS 面前不堪一擊，現在基本上只留存了一些美好的回憶。
這時，Modules/2.0 陣營也有一個實戰派：FlyScript，提出了非常簡潔的Modules/Wrappings 規範：這個簡潔的規範考慮了瀏覽器的特殊性，同時也儘可能相容了 Modules/1.0 規範。悲催的是，FlyScript 在推出正式版和官網之後，RequireJS 當時正直紅火。期間 FlyScript 作者 和 RequireJS 作者 James Burke 有過一些爭論。再後來，FlyScript 作者做了自我閹割，將 GitHub 上的項目和官網都清空了，官網上當時留了一句話，模糊中記得是：我會回來的，帶著更好的東西。
這中間究竟發生了什麼，不得而知。後來玉伯發郵件給 FlyScript作者 詢問，對方給了兩點挺讓我尊重的理由，大意是：
- 我並非前端出身，RequireJS 的作者 James Burke 比我更懂瀏覽器。
- 我們應該協同起來推動一個社區的發展，即便它不是你喜歡的。
這兩句話對玉伯影響很大。也是那之後，開始仔細研究 RequireJS，並通過郵件等方式給 RequireJS 提出過不少建議。再後來，在實際使用 RequireJS 的過程中，遇到了很多坑。那時 RequireJS 雖然很火，但真不夠完善。期間也在尋思著 FlyScript 離開時的那句話：“我會回來的，帶著更好的東西”
玉伯說我沒 FlyScript 的作者那麼偉大，在不斷給 RequireJS 提建議，但不斷不被採納後，開始萌生了自己寫一個 loader 的念頭。
這就是 SeaJS。SeaJS 借鑒了 RequireJS 的不少東西，比如將 FlyScript 中的 module.declare 改名為 define 等。SeaJS 更多地來自 Modules/2.0 的觀點，但儘可能去掉了學院派的東西，加入了不少實戰派的理念。這個就是CMD的間接產物，SeaJs。
好了基本的歷史都說完了，不知道我說的能不能讓大家聽明白，大概的總結下就是 最先有的COMMONJS，因為COMMONJS用於是服務端的，不能直接用於瀏覽器，對於怎樣將這個規範用在瀏覽器，新生事物必然有爭論，也的就產生了不同的觀念和論點，所以也就出現了適用於瀏覽器的AMD規範，CMD規範，AMD的存在的一些問題不被COMMONJS社區認同，最後獨立運作，當然RequireJS也確實也大火了一段時間，後來CMD的產物seajs被玉伯開發出來。
到現在來看這兩個產物估計是已經過時了，當然還有在用的，畢竟後來的webpack es6的發展勢不可擋，webpakc對三種規範完全支持，後面的時間還會給大家分享下webpack的一些知識，對於前端模塊化發展歷史就說到這裡，對於初學前端的人瞭解歷史發展還是很有必要的。其實這原文是玉伯寫的，我只是更改了下變成了我自己的化，方便大家理解，大家也可以去搜下關於前端模塊化歷史那點事，這裡沒有說為什麼需要模塊化 大家也可以先瞭解下，帶著問題去學習才會學的更快。
好，今天就到這裡，哪裡說的不對請指正，有問題可以留言，謝謝，下次見！
