快捷導(dǎo)航

SeaJS 與 RequireJS 的差異對比

更新時間：2014年12月08日 10:35:10 投稿：junjie

這篇文章主要介紹了SeaJS 與 RequireJS 的差異對比,本文主要對CMD規(guī)范和AMD規(guī)范的弊端做了對比,并做出了一個總結(jié),需要的朋友可以參考下

“歷史不是過去，歷史正在上演。隨著 W3C 等規(guī)范、以及瀏覽器的飛速發(fā)展，前端的模塊化開發(fā)會逐步成為基礎(chǔ)設(shè)施。一切終究都會成為歷史，未來會更好。”——引用玉伯原文最后一段話，我個人也非常贊同。既然談到了“未來”，我個人認(rèn)為：前端 js 模塊如果繼續(xù)發(fā)展，其模塊格式很可能會成為未來 WEB 一種標(biāo)準(zhǔn)規(guī)范，產(chǎn)生多種實(shí)現(xiàn)方式。就好比 JSON 格式一樣，最終成為標(biāo)準(zhǔn)、被瀏覽器原生實(shí)現(xiàn)。

誰更有能成為未來的異步模塊標(biāo)準(zhǔn)？SeaJS 遵循 CMD 規(guī)范，RequireJS 遵循 AMD 規(guī)范，先從這兩種不同的格式說起。

CMD

CMD 模塊依賴聲明方式：

復(fù)制代碼代碼如下:

define(function (require) {

    var a = require('./a');

    var b = require('./b');

    // more code ..

})

CMD 依賴是就近聲明，通過內(nèi)部require方法進(jìn)行聲明。但是因?yàn)槭钱惒侥K，加載器需要提前加載這些模塊，所以模塊真正使用前需要提取模塊里面所有的依賴。無論是加載器即時提取，還是通過自動化工具預(yù)先提取，CMD 的這種依賴聲明格式只能通過靜態(tài)分析方式實(shí)現(xiàn)，這也正是 CMD 的弊端所在。

CMD 規(guī)范的弊端

不能直接壓縮：require是局部變量，意味著不能直接的通過壓縮工具進(jìn)行壓縮，若require這個變量被替換，加載器與自動化工具將無法獲取模塊的依賴。
模塊書寫有額外約定：路徑參數(shù)不能進(jìn)行字符串運(yùn)算，不能使用變量代替，否則加載器與自動化工具無法正確提取路徑。
規(guī)范之外的約定意味著更多的文檔說明，除非它們也是規(guī)范中的一部分。

注：SeaJS 靜態(tài)分析實(shí)現(xiàn)是把模塊包toString()后使用正則提取require部分得到依賴的模塊路徑。

AMD

AMD 模塊依賴聲明方式：

復(fù)制代碼代碼如下:

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

    // more code ..

})

AMD 的依賴是提前聲明。這種優(yōu)勢的好處就是依賴無需通過靜態(tài)分析，無論是加載器還是自動化工具都可以很直接的獲取到依賴，規(guī)范的定義可以更簡單，意味著可能產(chǎn)生更強(qiáng)大的實(shí)現(xiàn)，這對加載器與自動化分析工具都是有利的。

AMD 規(guī)范的弊端

依賴提前聲明在代碼書寫上不是那么友好。
模塊內(nèi)部與 NodeJS 的 Modules 有一定的差異。
關(guān)于第二點(diǎn)的問題需要特別說明下。其實(shí)無論是 CMD 還是 AMD 的異步模塊，都無法與同步模塊規(guī)范保持一致（NodeJS 的 Modules），只有誰比誰更像同步模塊而已。AMD 要轉(zhuǎn)換為同步模塊，除了去掉define函數(shù)的包裹外，需要在頭部使用require把依賴聲明好，而 CMD 只需要去掉define函數(shù)的包裹即可。

總結(jié)