前端模塊化的發展史

原文參考 玉伯 大神些的,我整理了一下。前端

 

我們今天主題說下前端模塊化發展的歷史,主要就是針對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。

 

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做者 詢問,對方給了兩點挺讓我尊重的理由,大意是:

  1. 我並不是前端出身,RequireJS 的做者 James Burke 比我更懂瀏覽器。
  2. 咱們應該協同起來推進一個社區的發展,即使它不是你喜歡的。

 

這兩句話對玉伯影響很大。也是那以後,開始仔細研究 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的一些知識,對於前端模塊化發展歷史就說到這裏,對於初學前端的人瞭解歷史發展仍是頗有必要的。其實這原文是玉伯寫的,我只是更改了下變成了我本身的化,方便你們理解,你們也能夠去搜下關於前端模塊化歷史那點事,這裏沒有說爲何須要模塊化 你們也能夠先了解下,帶着問題去學習纔會學的更快。

 

好,今天就到這裏,哪裏說的不對請指正,有問題能夠留言,謝謝,下次見!

相關文章
相關標籤/搜索