RequireJS和SeaJS区别?AMD 和 CMD 的区别有哪些?CommonJS Modules

分类:Javascript| 发布:佚名| 查看: | 发表时间:2014/5/9
模块化开发已经是大势所趋,看到玉伯在介绍seajs和requirejs时,说“RequireJS 遵循的是 AMD(异步模块定义)规范,SeaJS 遵循的是 CMD (通用模块定义)规范”。
AMD 规范在这里:github.com/amdjs/amdjs-
CMD 规范在这里:github.com/seajs/seajs/

AMD 是 RequireJS 在推广过程中对模块定义的规范化产出。
CMD 是 SeaJS 在推广过程中对模块定义的规范化产出。
类似的还有 CommonJS Modules/2.0 规范,是 BravoJS 在推广过程中对模块定义的规范化产出。
还有不少⋯⋯

这些规范的目的都是为了 JavaScript 的模块化开发,特别是在浏览器端的。
目前这些规范的实现都能达成浏览器端模块化开发的目的

区别:

1. 对于依赖的模块,AMD 是提前执行,CMD 是延迟执行。不过 RequireJS 从 2.0 开始,也改成可以延迟执行(根据写法不同,处理方式不同)。CMD 推崇 as lazy as possible.

2. CMD 推崇依赖就近,AMD 推崇依赖前置。看代码:

// CMD
define(function(require, exports, module) {
var a = require('./a')
a.doSomething()
// 此处略去 100 行
var b = require('./b') // 依赖可以就近书写
b.doSomething()
// ... 
})

// AMD 默认推荐的是
define(['./a', './b'], function(a, b) { // 依赖必须一开始就写好
a.doSomething()
// 此处略去 100 行
b.doSomething()
...
}) 

虽然 AMD 也支持 CMD 的写法,同时还支持将 require 作为依赖项传递,但 RequireJS 的作者默认是最喜欢上面的写法,也是官方文档里默认的模块定义写法。


3. AMD 的 API 默认是一个当多个用,CMD 的 API 严格区分,推崇职责单一。比如 AMD 里,require 分全局 require 和局部 require,都叫 require。CMD 里,没有全局 require,而是根据模块系统的完备性,提供 seajs.use 来实现模块系统的加载启动。CMD 里,每个 API 都简单纯粹


4. 还有一些细节差异,具体看这个规范的定义就好,就不多说了。

相同之处

RequireJS 和 Sea.js 都是模块加载器,倡导模块化开发理念,核心价值是让 JavaScript 的模块化开发变得简单自然。

不同之处

两者的主要区别如下:

  1. 定位有差异。RequireJS 想成为浏览器端的模块加载器,同时也想成为 Rhino / Node 等环境的模块加载器。Sea.js 则专注于 Web 浏览器端,同时通过 Node 扩展的方式可以很方便跑在 Node 环境中。

  2. 遵循的规范不同。RequireJS 遵循 AMD(异步模块定义)规范,Sea.js 遵循 CMD (通用模块定义)规范。规范的不同,导致了两者 API 不同。Sea.js 更贴近 CommonJS Modules/1.1 和 Node Modules 规范。

  3. 推广理念有差异。RequireJS 在尝试让第三方类库修改自身来支持 RequireJS,目前只有少数社区采纳。Sea.js 不强推,采用自主封装的方式来“海纳百川”,目前已有较成熟的封装策略。

  4. 对开发调试的支持有差异。Sea.js 非常关注代码的开发调试,有 nocache、debug 等用于调试的插件。RequireJS 无这方面的明显支持。

  5. 插件机制不同。RequireJS 采取的是在源码中预留接口的形式,插件类型比较单一。Sea.js 采取的是通用事件机制,插件类型更丰富。

还有不少差异,涉及具体使用方式和源码实现,欢迎有兴趣者研究并发表看法。

总之,如果说 RequireJS 是 Prototype 类库的话,则 Sea.js 致力于成为 jQuery 类库。

最重要的

最后,向 RequireJS 致敬!RequireJS 和 Sea.js 是好兄弟,一起努力推广模块化开发思想,这才是最重要的。

--------------------------------------------------------------------------------------------------------------------------

相同点是:要解决的问题相同,都是浏览器端的模块化开发,目标一致。

不同点有不少:

1. 遵循的规范不同

RequireJS 遵循的是 Modules/AMD 规范。

SeaJS 遵循的是 Mdoules/Wrappings 规范的 define 形式。

AMD 规范在 CommonJS 社区争议很大,规范里太多 RequireJS 的影子。社区里不少人反感 RequireJS 打着 CommonJS 的口号,甚至建议 AMD 自立门户,比如最近的这篇讨论:Split off AMD?

从这两个规范本身来说,Modules/Wrappings 规范更简洁优雅,不信的话,你读读它们各自的描述就清楚。

2. factory 的执行时机不同

在 RequireJS 里,模块有多种书写格式,推荐的是:

define(["./a", "./b"], function(a, b) {
    a.doSomething();
    b.doSomething();
});

在 SeaJS 里,模块只有一种书写格式:

define(function(require, exports, module) {
     require("./a").doSomething();
     require("./b").doSomething();
});

SeaJS 的模块书写格式,RequireJS 也支持。为了便于讨论,我们称呼 define 方法中的 function 参数为模块的 factory. 无论是在 RequireJS 还是 SeaJS 里,在执行 factory 之前,都会确保依赖的模块已经下载好:

/* a.js */
define(factory);

/* b.js */
define(factory);

/* c.js */
define(['./a', './b'], factory);

每个模块都有自己的 factory. 在 AMD 的书写格式下,上面例子中,模块 c 的 factory 在执行时,会接收 a 和 b 两个参数。这意味着,c 依赖的所有模块,都是在一开始就得执行好,即便有可能不需要执行,比如:

define(function(require) {
     // BEGIN
    if(some_condition) {
        require('./a').doSomething();
    } else {
       require('./b').soSomething();
    }
    // END
});

在 AMD 规范里,在 BEGIN 处,a 和 b 的 factory 都已经执行好。在 Wrappings 规范里,在 BEGIN 处,a 和 b 的 factory 还没未执行,在 END 处时,根据条件,只会执行其中一个。

可以看出,Wrappings 规范更“懒”,更节省 CPU. 更符合 nodejs 等环境下的使用习惯。

AMD 规范只所以采用提前执行,可以参考作者的说明:Standards and proposals for JavaScript Modules and jQuery, 提到了两点理由,但并不被社区认可。我个人觉得这是一种权衡,但是是一种糟糕的权衡,破坏了与 Modules/1.0 规范的和谐性。有兴趣的可以搜索 Google Groups, 有相当多的讨论。

Wrappings 规范则尽可能的保留了 Modules/1.0 规范中的习惯。权衡点在于,对于条件语句中 require:

if(true) {
   require('./a').doSomething();
} else {
   require('./b').soSomething();
}

在 node 等环境中,能直接同步读取文件,可以做到只加载和执行模块 a, 不加载模块 b. 但在浏览器端,要实现这点,很困难(可以通过类似 Jscex 的方式来实现,但复杂度急增)。面对现实,目前基本所有浏览器端的 loader, 都是把依赖的模块都下载下来。从打包部署的角度考虑,这样做并不会对性能造成影响,反而能让不同条件分支,共享同一缓存。Wrappings 规范的提前下载和延迟执行,是一种合理的权衡。

3. 设计理念不同

如果你用过 RequireJS, 会知道:require 方法极其灵活,比如下面这些:

require('a') -- gets exports of module a
require(['a']) -- fetch module a according to module name scheme
require(['a.js']) -- fetch a.js directly relative to current page
require({...}) -- set loader config

稍微有点变化,做的事情就不一样,个人很不喜欢,社区里也有不少人讨厌这种风格。

在 SeaJS 里,API 的设计理念是:

  • 保持简单,职责单一。
  • 遵守规范,但不拘泥。
  • 适度灵活。

SeaJS 的公共 API 只有 8 个:速查手册, 职责很清晰,简单明了。

不拘泥规范,大家可以看到,SeaJS 里并没有采用 Modules/Wrappings 规范里的 module.declare. 这是因为:

module.declare(function(require, exports, module) {
     module.id // 这是参数 module
});

module.declare(function(require, exports) {
     module.id // 这是全局 module
});

显然,module.declare 导致 module 变量和 this 一样,随着环境的变化而变化。对于新手来说,这会带来迷惑。不如直接引入 define 来得简洁明了。随着 RequireJS 的推广,大家对 define 的接受程度也更高,更容易被理解。还有一个好处:使得 SeaJS 的模块,理论上讲,可以直接运行于 RequireJS 上。

适度灵活,举个例子:

seajs.use("./a"); // 加载一个模块
seajs.use(["./a", "./b"]); // 加载多个模块

4. 聚焦点有差异

SeaJS 从一开始,到现在,都是 focus on web, 努力成为浏览器端的模块加载器。sea.js 源码里,只有和浏览器相关的代码,不像 requirejs 一样,牵三挂四,有为了能在 Rhino 和 node 下运行的代码,甚至还有为了与 jQuery 集成的代码。聚焦的好处之一是,能减少文件大小:

SeaJS 目前的大小是:3.2K (gzip)
RequireJS 的大小是:5.4K (gzip)

seajs 的源码,目前是分多个文件开发的,每个文件都很聚焦,有完善的测试用例。requirejs 目前依旧是一个大文件,不利于维护。

5. 最后,还是理念不一样

RequireJS 有一系列插件,功能很强大,但破坏了模块加载器的纯粹性,个人觉得不妥。

SeaJS 则努力保持简单,追求简洁之美。除非必要,勿增实体。在功能上,SeaJS 有个优势是,支持 CSS 模块的加载。RequireJS 因为技术原因,目前版本尚未实现。

最后的最后

根据实际需求选择就好,关键是要养成模块化开发的好习惯。

365据说看到好文章不转的人,服务器容易宕机
原创文章如转载,请注明:转载自郑州网建-前端开发 http://camnpr.com/
本文链接:http://camnpr.com/archives/requirejs-seajs-amd-cmd.html