更好的工作机会
在100offer，提交一份个人资料，一周内即会有5-10家Top互联网公司主动向你发出邀请。100offer确保你的隐私万无一失，同时Consultant将为你全程提供专业服务。
最具价值web全栈课程
只做前端开发培训的好学校，专注于多方向全栈工程师培养。前端名师邵山欢亲自授课，课程涵盖HTML5、CSS3、Node.js、Angular、React诸多课程，免费视频广受学生好评。
跟牛人学前端
跟牛人学前端
妙味大前端自学宝典
妙味课堂2016年JavaScript课程大纲震撼升级、全栈来袭！
前端最新干货
前端最新干货
web在线直播课
潭州教育是中国较早的在线教育平台,教学内容涵盖网络营销,java,javascript,jquery,android,ios,mysql,围棋,刺绣,养殖,农业,手艺,网页设计,平面设计,影视后期,CAD建筑机械,网络营销,商战智慧,办公软件,三维设计,工业设计,淘宝摄影,英语,音乐,大学代理,Photoshop教程,
Max教程,Maya教程,CAD教程,会声会影教程,AI教程,淘宝开店,摄影教程,免费教程,素材下载等众多在线学习精品课程。经过10年的发展,潭州教育已经发展为中国规模较大的在线教育平台。
JavaScript 代码片段
精心挑选的有用的 JavaScript 代码片段，你可以在30秒或更短的时间内理解。
Parcel 中文文档
快速，零配置的 Web 应用程序打包器
您的位置： » 分类:
» 文章: 兼容多种模块规范(AMD,CMD,Node)的代码
您可能感兴趣的文章
近期最热文章
- 2,635 - 2,461
关注WEB前端开发公众号AMD 和 CMD 的区别有哪些_百度知道
AMD 和 CMD 的区别有哪些
我有更好的答案
AMD是显卡，CPU硬件制造商。CMD是微软系统中的命令行程序。两个完全不同的东西，无法比较。
采纳率：77%
为您推荐：
其他类似问题
您可能关注的内容
cmd的相关知识
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。在 SegmentFault，学习技能、解决问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。
问题对人有帮助，内容完整，我也想知道答案
问题没有实际价值，缺少关键内容，没有改进余地
最近网上查阅有关AMD和CMD模块化加载的相关信息，关于ADM就按照我目前的理解就是require.js在遵循common.js的规范，而CMD就是sea.js，我是个菜鸟，跪求大神能给我解释一下，让我搞明白！
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
AMD 和 CMD著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。作者：玉伯链接：来源：知乎
AMD 规范在这里：CMD 规范在这里：
AMD 是 RequireJS 在推广过程中对模块定义的规范化产出。CMD 是 SeaJS 在推广过程中对模块定义的规范化产出。类似的还有 CommonJS Modules/2.0 规范，是 BravoJS 在推广过程中对模块定义的规范化产出。还有不少??
这些规范的目的都是为了 JavaScript 的模块化开发，特别是在浏览器端的。目前这些规范的实现都能达成浏览器端模块化开发的目的。
对于依赖的模块，AMD 是提前执行，CMD 是延迟执行。不过 RequireJS 从 2.0 开始，也改成可以延迟执行（根据写法不同，处理方式不同）。CMD 推崇 as lazy as possible.
CMD 推崇依赖就近，AMD 推崇依赖前置。看代码：
// CMDdefine(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 的作者默认是最喜欢上面的写法，也是官方文档里默认的模块定义写法。
AMD 的 API 默认是一个当多个用，CMD 的 API 严格区分，推崇职责单一。比如 AMD 里，require 分全局 require 和局部 require，都叫 require。CMD 里，没有全局 require，而是根据模块系统的完备性，提供 seajs.use 来实现模块系统的加载启动。CMD 里，每个 API 都简单纯粹。
Sea.JS 和 Require.JS
RequireJS 和 Sea.js 都是模块加载器，倡导模块化开发理念，核心价值是让 JavaScript 的模块化开发变得简单自然。
两者的主要区别如下：
定位有差异。RequireJS 想成为浏览器端的模块加载器，同时也想成为 Rhino / Node 等环境的模块加载器。Sea.js 则专注于 Web 浏览器端，同时通过 Node 扩展的方式可以很方便跑在 Node 环境中。
遵循的规范不同。RequireJS 遵循 AMD（异步模块定义）规范，Sea.js 遵循 CMD （通用模块定义）规范。规范的不同，导致了两者 API 不同。Sea.js 更贴近 CommonJS Modules/1.1 和 Node Modules 规范。
推广理念有差异。RequireJS 在尝试让第三方类库修改自身来支持 RequireJS，目前只有少数社区采纳。Sea.js 不强推，采用自主封装的方式来“海纳百川”，目前已有较成熟的封装策略。
对开发调试的支持有差异。Sea.js 非常关注代码的开发调试，有 nocache、debug 等用于调试的插件。RequireJS 无这方面的明显支持。
插件机制不同。RequireJS 采取的是在源码中预留接口的形式，插件类型比较单一。Sea.js 采取的是通用事件机制，插件类型更丰富。
还有不少差异，涉及具体使用方式和源码实现，欢迎有兴趣者研究并发表看法。
总之，如果说 RequireJS 是 Prototype 类库的话，则 Sea.js 致力于成为 jQuery 类库。
最后，向 RequireJS 致敬！RequireJS 和 Sea.js 是好兄弟，一起努力推广模块化开发思想，这才是最重要的。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
用commonjs
同步到新浪微博
分享到微博？
关闭理由：
删除理由：
忽略理由：
推广（招聘、广告、SEO 等）方面的内容
与已有问题重复（请编辑该提问指向已有相同问题）
答非所问，不符合答题要求
宜作评论而非答案
带有人身攻击、辱骂、仇恨等违反条款的内容
无法获得确切结果的问题
非开发直接相关的问题
非技术提问的讨论型问题
其他原因（请补充说明）
我要该，理由是：
在 SegmentFault，学习技能、解决问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。263被浏览41,265分享邀请回答&script src="path/to/my/hello/1.0/hello.js"&&/script&
&script src="path/to/my/hello/2.0/hello.js"&&/script&
这样，除非我们将它们各自的 API 放在不同的命名空间下，否则就会导致命名冲突（当然，你也可以在 2.0 版本的 hello.js 的 API 设计上做一些兼容性设计）。YUI.hello.older.sayHello();
YUI.hello.newer.sayHello();
所以，YUI3来了，它解决了模块依赖的问题，并一定程度上解决了多版本共存问题。之间我有说过它使用了 Sandbox + namespace 的方式。关于 Sandbox ，我们先举个栗子：// path/to/my/hello/1.0/hello.js
YUI.add('hello', function(Y) {
Y.sayHello = function(msg) {
Y.DOM.set(el, 'innerHTML', 'Hello!');
}, '1.0', {
requires: ['dom']
// index.html
&div id="entry"&&/div&
YUI().use('hello', function(Y) {
Y.sayHello('entry');
// &div id="entry"&Hello!&/div&
我们用到了两个接口，其中 YUI.add 看起来和 AMD 的 define 相似，而 YUI().use 和 require() 有个很大的不同，就是我们只有一个参数 Y ，那 Y 是什么呢？Y是一个独立的构造函数实例，它存在于运行时，它包括了所有依赖的模块的 API。YUI().use 的执行分成两个步骤，首先是加载依赖模块，然后是将它们 attach 到 Y 上。看下面的栗子：YUI.add('moduleA', function(Y) {
Y.moduleA = function() {}
YUI.add('moduleA', function(Y) {
Y.moduleB = {
run: function() {}
jump: function() {}
YUI.add('moduleC', function(Y) {
Y.play = function() {
YUI().use(['moduleA', 'moduleB', 'moduleC'], function(Y) {
console.log(Y.moduleA);
Y.moduleB.run();
Y.moduleB.jump();
是不是有点像 $.extend(my, base) 呢？通过 Sandbox ，我们可以支持多版本共存，我们回到之前的 hello 例子，现在我们需要一个新的版本。// path/to/my/hello/2.0/hello.js
YUI.add('hello', function(Y) {
Y.sayHello = function(id) {
var el = Y.DOM.byId(id);
Y.DOM.set(el, 'innerHTML', 'Hello too!');
}, '2.0', {
requires: ['dom']
// index.html
&div id="entry"&&/div&
YUI().use('hello1.0', function(Y) {
Y.sayHello('entry');
// &div id="entry"&Hello!&/div&
YUI().use('hello2.0', function(Y) {
Y.sayHello('entry');
// &div id="entry"&Hello too!&/div&
两个版本的 hello.js 都存在于他们各自的 Sandbox 中，互不打扰。但是呢， YUI3 并没有真正地实现多版本共存，请看下面的使用情况：// index.html
&div id="entry"&&/div&
YUI().use(['hello1.0', 'hello2.0'], function(Y) {
Y.sayHello('entry');
// &div id="entry"&Hello too!&/div&
我们又只能回到 YUI2 时代解决多版本共存的问题。而且，YUI3 将所有的需要的模块 attach 到了同一个运行时构造实例，为了防止模块之间的命名冲突，所以我们仍然需要 namespace 这个函数，比如：YUI.add('moduleA', function(Y) {
// Y.run = function() {};
Y.namespace('moduleA').run = function() {};
YUI.add('moduleA', function(Y) {
// Y.run = function() {};
Y.namespace('moduleB').run = function() {}
YUI.use(['moduleA', 'moduleB'], function(Y) {
// Y.run = function() {};
Y.moduleA.run();
Y.moduleB.run();
而 AMD/CMD 就没有这个问题：define('moduleA', function() {
run: function() {}
define('moduleB', function() {
run: function() {}
require(['moduleA', 'moduleB'], function(moduleA, moduleB) {
moduleA.run();
moduleB.run();
使用 AMD/CMD ，我们可以完全不使用命名空间这个概念，这样在大型的系统中，完全可以避免有深度的命名空间，以减少组织方式上的困难以及查找上的性能消耗。通过自己的比较，感觉 AMD/CMD 比 YUI Module 要好很多，不知道 YUI Module 的优势是什么？224 条评论分享收藏感谢收起define(function(require, exports, module) {
var a = require('./a')
a.doSomething()
var b = require('./b')
b.doSomething()
代码在运行时，首先是不知道依赖的，需要遍历所有的require关键字，找出后面的依赖。具体做法是将function toString后，用正则匹配出require关键字后面的依赖。显然，这是一种牺牲性能来换取更多开发便利的方法。而AMD是依赖前置的，换句话说，在解析和执行当前模块之前，模块作者必须指明当前模块所依赖的模块，表现在require函数的调用结构上为：define(['./a','./b'],function(a,b){
a.doSomething()
b.doSomething()
代码在一旦运行到此处，能立即知晓依赖。而无需遍历整个函数体找到它的依赖，因此性能有所提升，缺点就是开发者必须显式得指明依赖——这会使得开发工作量变大，比如：当你写到函数体内部几百上千行的时候，忽然发现需要增加一个依赖，你不得不回到函数顶端来将这个依赖添加进数组。细心的读者可能发现，到目前位置我讨论的AMD和CMD的思想的关于依赖的部分，都只讨论的“硬依赖”，也就是执行前肯定需要的依赖，但是这不是全部的情况。有的时候情况是这样的：// 函数体内：
if(status){
a.doSomething()
在这个函数体内，可能依赖a，也可能不依赖a，我把这种可能的依赖成为“软依赖”。对于软依赖当然可以直接当硬依赖处理，但是这样不经济，因为依赖是不一定的，有可能加载了此处的依赖而实际上没有用上。对于软依赖的处理，我推荐依赖前置+回调函数的实现形式。上面的例子简单表述如下：// 函数体内：
if(status){
async(['a'],function(a){
a.doSomething()
至此可以对由commonJS衍生出来的方案做出总结了。在浏览器端来设计模块加载机制，需要考虑依赖的问题。我们先把依赖分为两种，“强依赖” —— 肯定需要 和“弱依赖” —— 可能需要。对于强依赖，如果要性能优先，则考虑参照依赖前置的思想设计你的模块加载器，我个人也更推崇这个方案一些；如果考虑开发成本优先，则考虑按照依赖就近的思想设计你的模块加载器。对于弱依赖，只需要将弱依赖的部分改写到回调函数内即可。如果现在我要实现一个模块加载器，我会将强依赖前置，弱依赖采用异步回调函数的形式，其它的方法我认为都只是语法糖而已，仅此就够了。扩展阅读：847 条评论分享收藏感谢收起JavaSript模块规范 - AMD规范与CMD规范介绍_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
JavaSript模块规范 - AMD规范与CMD规范介绍
&&JavaSript模块规范 - AMD规范与CMD规范介绍
阅读已结束，下载本文需要
想免费下载更多文档？
定制HR最喜欢的简历
下载文档到电脑，方便使用
还剩13页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢