原文參考 玉伯 大神些的,我整理了一下。前端
我們今天主題說下前端模塊化發展的歷史,主要就是針對AMD CMD 的發展,這兩個東西是一種規範,他們實際產物是 AMD是RequireJS,CMD的產物是seajs,他們的出現都是在COMMONjs基礎上發展而來的,那我們得先說說COMMONjs。webpack
COMMONJSgit
大概 09 年 – 10 年期間,CommonJS 社區大牛雲集。CommonJS 原來叫 ServerJS,推出 Modules/1.0 規範後,在Node.js 環境下取得了很不錯的實踐。09年下半年這幫牛逼愛折騰的大神們想把 ServerJS 的成功經驗進一步推廣到瀏覽器端,因而將社區更名叫 CommonJS,同時激烈爭論 Modules 的下一版規範。分歧和衝突由此誕生,逐步造成了三大流派:Modules/1.x (徹底基於1.0的功能,只是增長一個轉換功能),Modules/Async ,Modules/2.0 。es6
Modules/1.x 流派:這個觀點以爲 1.x 規範已經夠用,只要移植到瀏覽器端就好。要作的是新增 Modules/Transport 規範,即在瀏覽器上運行前,先經過轉換工具將模塊轉換爲符合 Transport 規範的代碼。如今值得關注的有兩個實現:component 和es6 module。github
Modules/Async 流派:這個觀點以爲瀏覽器有自身的特徵,不該該直接用 Modules/1.x 規範。這個觀點下的典型表明是 AMD 規範及其實現 RequireJS。這個稍後再細說。web
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 發展的很火熱。app
可是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。
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,並經過郵件等方式給 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的一些知識,對於前端模塊化發展歷史就說到這裏,對於初學前端的人瞭解歷史發展仍是頗有必要的。其實這原文是玉伯寫的,我只是更改了下變成了我本身的化,方便你們理解,你們也能夠去搜下關於前端模塊化歷史那點事,這裏沒有說爲何須要模塊化 你們也能夠先了解下,帶着問題去學習纔會學的更快。
好,今天就到這裏,哪裏說的不對請指正,有問題能夠留言,謝謝,下次見!