关于 CommonJS AMD CMD UMD 规范的差异总结

根据CommonJS规范，一个单独的文件就是一个模块。每一个模块都是一个单独的作用域，也就是说，在一个文件定义的变量（还包括函数和类），都是私有的，对其他文件是不可见的。

// foo.js
var request = require('request').default({ timeout: 4000
});module.exports = function(){ this.re = '';this.req = function(url){ request(url,function(error,status,res){ this.re = res;});}
};
//---------------------------------------------
// main.jsvar Foo = require('./foo');
var foo = new Foo();
foo.req('http://www.baidu.com');
//这么个异步法  foo.re应该是空的吧..
console.log(foo.re);

CommonJS 加载模块是同步的.所以只有加载完成才能执行后面的操作。

像Node.js主要用于服务器的编程，加载的模块文件一般都已经存在本地硬盘，所以加载起来比较快，不用考虑异步加载的方式，所以CommonJS规范比较适用。

但如果是浏览器环境，要从服务器加载模块，这是就必须采用异步模式。所以就有了 AMD CMD 等解决方案。

二、AMD (Asynchromous Module Definition)

AMD 是 RequireJS 在推广过程中对模块定义的规范化产出

AMD异步加载模块。它的模块支持对象函数构造器字符串 JSON等各种类型的模块。

适用AMD规范适用define方法定义模块。

示例如-->

AMD 运行时核心思想是「Early Executing」，也就是提前执行依赖

三、CMD (Common Module Definition)

CMD是SeaJS 在推广过程中对模块定义的规范化产出

示例如-->

CMD和AMD的区别有以下几点：

1.对于依赖的模块AMD是提前执行，CMD是延迟执行。

2.CMD推崇依赖就近，按需加载；AMD推崇依赖前置。

那seajs和requirejs的差别呢？

“

定位有差异。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 类库。

”

四、UMD

umd是AMD和CommonJS的糅合

AMD 浏览器第一的原则发展异步加载模块。

CommonJS 模块以服务器第一原则发展，选择同步加载，它的模块无需包装(unwrapped modules)。

这迫使人们又想出另一个更通用的模式UMD （Universal Module Definition）。希望解决跨平台的解决方案。

UMD先判断是否支持Node.js的模块（exports）是否存在，存在则使用Node.js模块模式。

在判断是否支持AMD（define是否存在），存在则使用AMD方式加载模块。

如代码：

(function (window, factory) {if (typeof exports === 'object') {module.exports = factory();} else if (typeof define === 'function' && define.amd) {define(factory);} else {window.eventUtil = factory();}
})(this, function () {//module ...
});

转载于:https://www.cnblogs.com/rainheader/p/4667036.html

关于 CommonJS AMD CMD UMD 规范的差异总结相关推荐

commonjs是什么_JavaScript模块化标准CommonJS/AMD/CMD/UMD/ES6Module的区别
JS-模块化进程随着js技术的不断发展,途中会遇到各种问题,比如模块化. 那什么是模块化呢,他们的目的是什么? 定义:如何把一段代码封装成一个有用的单元,以及如何注册此模块的能力.输出的值依赖引用: ...
模块格式：CommonJS AMD CMD UMD ES6
皆为前端工程化中定义模块(module)的规则,如:模块标识,模块依赖,模块实现,模块对外接口,模块加载: 实现时有:异步,同步,依赖前置,依赖就近,预执行,懒执行,软依赖,硬依赖,模块对象支持类型等 ...
CommonJS/AMD/CMD/UMD
为什么会有这几种模式? 起源:Javascript模块化模块化就是把复杂问题分解成不同模块,这样可维护性高,从而达到高复用,低耦合. 1.Commonjs CommonJS是服务器端模块的规范,No ...
CommonJS,AMD,CMD,ES6,require 和 import 详解
CommonJS,AMD,CMD,ES6 commonJS用同步的方式加载模块.在服务端,模块文件都存在本地磁盘,读取非常快,所以这样做不会有问题.但是在浏览器端,限于网络原因,更合理的方案是使用异步 ...
JS JavaScript模块化（ES Module/CommonJS/AMD/CMD）
前言前端开发中,起初只要在script标签中嵌入几十上百行代码就能实现一些基本的交互效果,后来js得到重视,应用也广泛起来了, jQuery,Ajax,Node.Js,MVC,MVVM等的助力也使得 ...
关于JavaScript的模块（CommonJS, AMD, CMD, ES6模块）的理解
Javascript模块化就是解决将代码进行分隔,作用域隔离,模块之间的依赖管理等多个方面问题. 这样的优点不言而喻:1.可维护性2.命名空间私有化,可以避免污染全局环境3.代码重用,通过模块可以方便 ...
js UMD规范——AMD和CommonJS的糅合（一）
文章目录文章参考问题描述问题分析模块化的规范依赖引入的形式服务器端规范(nodejs)-- CommonJS `require()` 语句为什么浏览器不能使用同步加载,服务端可以? Co ...
AMD, CMD, CommonJS和UMD
AMD, CMD, CommonJS和UMD 今天由于项目中引入的echarts的文件太大,requirejs经常加载超时,不得不分开来加载echarts的各个图表.但是使用echarts自带的在线构 ...
CommonJs、AMD、CMD模块化规范
/*** CommonJS 模块化规范* CommonJS规范加载模块是同步的,也就是说,只有加载完成,才能执行后面的操作*//*-------Node.js遵循Commonjs规范--------- ...

关于 CommonJS AMD CMD UMD 规范的差异总结

关于 CommonJS AMD CMD UMD 规范的差异总结相关推荐

最新文章

热门文章