“歷史不是過去，歷史正在上演。隨著 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 來說，也做了很多不錯東西：
1、相對自然的依賴聲明風格
2、小而美的內部實現
3、貼心的外圍功能設計
4、更好的中文社區支持
如果有可能，我希望看到 SeaJS 也支持 AMD，與前端社區大環境保持一致最終幸福的是廣大開發者。