SeaJS 與 RequireJS 的差別對比

這篇文章主要介紹了SeaJS 與 RequireJS 的差別對比,本文主要對CMD規範和AMD規範的弊端作了對比,並作出了一個總結,須要的朋友能夠參考下

「歷史不是過去，歷史正在上演。隨着 W3C 等規範、以及瀏覽器的飛速發展，前端的模塊化開發會逐步成爲基礎設施。一切終究都會成爲歷史，將來會更好。」——引用玉伯原文最後一段話，我我的也很是贊同。既然談到了「將來」，我我的認爲：前端 js 模塊若是繼續發展，其模塊格式極可能會成爲將來 WEB 一種標準規範，產生多種實現方式。就比如 JSON 格式同樣，最終成爲標準、被瀏覽器原生實現。

誰更有能成爲將來的異步模塊標準？SeaJS 遵循 CMD 規範，RequireJS 遵循 AMD 規範，先從這兩種不一樣的格式提及。

CMD

CMD 模塊依賴聲明方式：

define(function (require) {
    var a = require('./a');
    var b = require('./b');
    // more code ..
})

CMD 依賴是就近聲明，經過內部require方法進行聲明。可是由於是異步模塊，加載器須要提早加載這些模塊，因此模塊真正使用前須要提取模塊裏面全部的依賴。不管是加載器即時提取，仍是經過自動化工具預先提取，CMD 的這種依賴聲明格式只能經過靜態分析方式實現，這也正是 CMD 的弊端所在。

CMD 規範的弊端

不能直接壓縮：require是局部變量，意味着不能直接的經過壓縮工具進行壓縮，若require這個變量被替換，加載器與自動化工具將沒法獲取模塊的依賴。
模塊書寫有額外約定：路徑參數不能進行字符串運算，不能使用變量代替，不然加載器與自動化工具沒法正確提取路徑。
規範以外的約定意味着更多的文檔說明，除非它們也是規範中的一部分。

注：SeaJS 靜態分析實現是把模塊包toString()後使用正則提取require部分獲得依賴的模塊路徑。

AMD

AMD 模塊依賴聲明方式：

define(['./a', './b'], function (a, b) {
    // more code ..
})

AMD 的依賴是提早聲明。這種優點的好處就是依賴無需經過靜態分析，不管是加載器仍是自動化工具均可以很直接的獲取到依賴，規範的定義能夠更簡單，意味着可能產生更強大的實現，這對加載器與自動化分析工具都是有利的。

AMD 規範的弊端

依賴提早聲明在代碼書寫上不是那麼友好。
模塊內部與 NodeJS 的 Modules 有必定的差別。
關於第二點的問題須要特別說明下。其實不管是 CMD 仍是 AMD 的異步模塊，都沒法與同步模塊規範保持一致（NodeJS 的 Modules），只有誰比誰更像同步模塊而已。AMD 要轉換爲同步模塊，除了去掉define函數的包裹外，須要在頭部使用require把依賴聲明好，而 CMD 只須要去掉define函數的包裹便可。

從規範上來講，AMD 更加簡單且嚴謹，適用性更廣，而在 RequireJS 強力的推進下，在國外幾乎成了事實上的異步模塊標準，各大類庫也相繼支持 AMD 規範。

但從 SeaJS 與 CMD 來講，也作了不少不錯東西：

一、相對天然的依賴聲明風格 
二、小而美的內部實現 
三、貼心的外圍功能設計 
四、更好的中文社區支持

若是有可能，我但願看到 SeaJS 也支持 AMD，與前端社區大環境保持一致最終幸福的是廣大開發者。