We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JS发展初期就是为了实现简单的页面交互逻辑,如今CPU、浏览器性能得到了极大的提升,很多页面逻辑迁移到了客户端(表单验证等),随着web2.0时代的到来,Ajax技术得到广泛应用,jQuery等前端库层出不穷,前端代码日益膨胀。
这时候JavaScript作为嵌入式的脚本语言的定位动摇了,JavaScript却没有为组织代码提供任何明显帮助,甚至没有类的概念,更不用说模块(module)了,JavaScript极其简单的代码组织规范不足以驾驭如此庞大规模的代码。
既然JavaScript不能handle如此大规模的代码,我们可以借鉴一下其它语言是怎么处理大规模程序设计的,在Java中有一个重要的概念——package,逻辑上相关的代码组织到同一个包内,包内是一个相对独立的王国,不用担心命名冲突什么的,那么外部如果使用呢?直接import对应的package即可
package
import
import java.util.ArrayList;
遗憾的是JavaScript在设计时定位原因,没有提供类似的功能,开发者需要模拟出类似的功能,来隔离、组织复杂的JavaScript代码,我们称为模块化。
一个模块就是实现特定功能的文件,有了模块,我们就可以更方便地使用别人的代码,想要什么功能,就加载什么模块。模块开发需要遵循一定的规范,各行其是就都乱套了
规范形成的过程总是痛苦的,前端的先驱在刀耕火种、茹毛饮血的阶段开始,发展到现在初具规模,我们来简单了解一下这段不凡的历程
我们都知道函数的一个功能就是对一组实现特定逻辑的语句进行打包,而且JS的作用域是基于函数的,所以我们首先想到的是把函数作为模块化的第一步
function fn1(){ //statement } function fn2(){ //statement }
这样之后我们在使用函数里面的功能的时候只要调用函数即可
但是因为函数的定义是在全局的,可能会发生命名冲突,污染全局变量,而且模块之间也没有关联
为了解决函数封装的缺点,对象的写法应用而生,如下,我们可以把所有模块成员封装在一个对象中
var moduleA = { a: 1, b: 2, fn1:function() { }, fn2: function() { } }
调用的时候只要引用文件,然后
moduleA.fn1()
这样避免了变量污染,只要保证模块名唯一即可,同时同一模块内的成员也有了关系
看似不错的解决方案,但是也有缺陷,外部可以随意修改内部成员
moduleA.b = 50;
可能导致意想不到的安全问题
可以通过立即执行函数,来达到隐藏细节的目的
var myModule = (function(){ var a = 1; var b = 2; function fn1(){ } function fn2(){ } return { fn1: fn1, fn2: fn2 }; })();
这样在模块外部无法修改我们没有暴露出来的变量、函数
上述做法就是我们目前实现模块化的基础,目前,通行的JavaScript模块规范主要有两种:CommonJS和AMD
CommonJS
AMD
主要目的
其他价值
参考--前端模块化开发的价值
首先,CommonJS是服务器端模块的规范,Node.js就是基于这个规范。Node.JS首先实现了JS模块化的概念。
根据CommonJS 规范,CommonJS的基本使用主要由以下三个步骤
global
举个例子:
//定义模块 myModule.js var name = 'tail' function printName(){ console.log(name) } function printFullName(firstName){ console.log(firstName + name); } //输出模块 module.exports = { printName: printName, printFullName: printFullName } //加载模块 var nameModule = require('./myModule.js') //不同的实现对require时的路径有不同要求,一般情况可以省略js拓展名,可以使用相对路径,也可以使用绝对路径,甚至可以省略路径直接使用模块名(前提是该模块是系统内置模块) //使用模块 nameModule.printName();
AMD 即Asynchronous Module Definition,中文名是异步模块定义的意思。它是一个在浏览器端模块化开发的规范
Asynchronous Module Definition
由于不是JavaScript原生支持,使用AMD规范进行页面开发需要用到对应的库函数,也就是大名鼎鼎RequireJS,实际上AMD 是RequireJS 在推广过程中对模块定义的规范化的产出
RequireJS
RequireJS 主要解决两个问题
//定义模块myModule.js define(['依赖1,依赖2,依赖3'],function(依赖1,依赖2,依赖3){ var name = 'tail'; function printName(){ console.log(name); } return { printName: printName }; }) //加载模块 require(['myModule'],function(my){ my.printName(); }); })
requireJS定义了一个函数 define,它是全局变量,用来定义模块
define(id?, dependencies?, factory);
在页面上使用require函数加载模块
require([dependencies], function(dependencies){});
require()函数接受两个参数
require()函数在加载依赖的函数的时候是异步加载的,这样浏览器不会失去响应,它指定的回调函数,只有前面的模块都加载成功后,才会运行,解决了依赖性的问题。
CMD 即Common Module Definition通用模块定义,CMD规范是国内发展出来的,AMD有个requireJS,CMD有个浏览器的实现SeaJS,SeaJS要解决的问题和requireJS一样,只不过在模块定义方式和模块加载(可以说运行、解析)时机上有所不同
Common Module Definition
Sea.js 推崇一个模块一个文件,遵循统一的写法
define
define(id?, deps?, factory)
因为CMD推崇
function(require, exports, module)
require
require 是 factory 函数的第一个参数
require(id)
require 是一个方法,接受 模块标识 作为唯一参数,用来获取其他模块提供的接口
exports
exports 是一个对象,用来向外提供模块接口
module
module 是一个对象,上面存储了与当前模块相关联的一些属性和方法
//定义模块 define(function(require, exports, module){ var $ = require('jquery.js') $('div').removeClass('active') }) //加载模块 seajs.use(['myModule.js'], function(my){ })
关于这两个的区别网上可以搜出一堆文章,简单总结一下
最明显的区别就是在模块定义时对依赖的处理不同
这种区别各有优劣,只是语法上的差距,而且requireJS和SeaJS都支持对方的写法
AMD和CMD最大的区别是对依赖模块的执行时机处理不同,注意不是加载的时机或者方式不同
很多人说requireJS是异步加载模块,SeaJS是同步加载模块,这么理解实际上是不准确的,其实加载模块都是异步的,只不过AMD依赖前置,js可以方便知道依赖模块是谁,立即加载,而CMD就近依赖,需要使用把模块变为字符串解析一遍才知道依赖了那些模块,这也是很多人诟病CMD的一点,牺牲性能来带来开发的便利性,实际上解析模块用的时间短到可以忽略
为什么我们说两个的区别是依赖模块执行时机不同,为什么很多人认为ADM是异步的,CMD是同步的(除了名字的原因。。。)
同样都是异步加载模块,AMD在加载模块完成后就会执行该模块,所有模块都加载执行完后会进入require的回调函数,执行主逻辑,这样的效果就是依赖模块的执行顺序和书写顺序不一定一致,看网络速度,哪个先下载下来,哪个先执行,但是主逻辑一定在所有依赖加载完成后才执行
CMD加载完某个依赖模块后并不执行,只是下载而已,在所有依赖模块加载完成后进入主逻辑,遇到require语句的时候才执行对应的模块,这样模块的执行顺序和书写顺序是完全一致的
这也是很多人说AMD用户体验好,因为没有延迟,依赖模块提前执行了,CMD性能好,因为只有用户需要的时候才执行的原因
The text was updated successfully, but these errors were encountered:
good
Sorry, something went wrong.
No branches or pull requests
模块化的由来
JS发展初期就是为了实现简单的页面交互逻辑,如今CPU、浏览器性能得到了极大的提升,很多页面逻辑迁移到了客户端(表单验证等),随着web2.0时代的到来,Ajax技术得到广泛应用,jQuery等前端库层出不穷,前端代码日益膨胀。
这时候JavaScript作为嵌入式的脚本语言的定位动摇了,JavaScript却没有为组织代码提供任何明显帮助,甚至没有类的概念,更不用说模块(module)了,JavaScript极其简单的代码组织规范不足以驾驭如此庞大规模的代码。
既然JavaScript不能handle如此大规模的代码,我们可以借鉴一下其它语言是怎么处理大规模程序设计的,在Java中有一个重要的概念——
package
,逻辑上相关的代码组织到同一个包内,包内是一个相对独立的王国,不用担心命名冲突什么的,那么外部如果使用呢?直接import
对应的package即可遗憾的是JavaScript在设计时定位原因,没有提供类似的功能,开发者需要模拟出类似的功能,来隔离、组织复杂的JavaScript代码,我们称为模块化。
一个模块就是实现特定功能的文件,有了模块,我们就可以更方便地使用别人的代码,想要什么功能,就加载什么模块。模块开发需要遵循一定的规范,各行其是就都乱套了
规范形成的过程总是痛苦的,前端的先驱在刀耕火种、茹毛饮血的阶段开始,发展到现在初具规模,我们来简单了解一下这段不凡的历程
函数封装
我们都知道函数的一个功能就是对一组实现特定逻辑的语句进行打包,而且JS的作用域是基于函数的,所以我们首先想到的是把函数作为模块化的第一步
这样之后我们在使用函数里面的功能的时候只要调用函数即可
但是因为函数的定义是在全局的,可能会发生命名冲突,污染全局变量,而且模块之间也没有关联
对象
为了解决函数封装的缺点,对象的写法应用而生,如下,我们可以把所有模块成员封装在一个对象中
调用的时候只要引用文件,然后
这样避免了变量污染,只要保证模块名唯一即可,同时同一模块内的成员也有了关系
看似不错的解决方案,但是也有缺陷,外部可以随意修改内部成员
可能导致意想不到的安全问题
立即执行函数
可以通过立即执行函数,来达到隐藏细节的目的
这样在模块外部无法修改我们没有暴露出来的变量、函数
上述做法就是我们目前实现模块化的基础,目前,通行的JavaScript模块规范主要有两种:
CommonJS
和AMD
为什么要使用模块化?
主要目的
其他价值
参考--前端模块化开发的价值
CommonJS 、CMD、AMD规范分别指什么?有哪些应用
CommonJS
首先,CommonJS是服务器端模块的规范,Node.js就是基于这个规范。Node.JS首先实现了JS模块化的概念。
根据CommonJS 规范,CommonJS的基本使用主要由以下三个步骤
CommonJS
规范,一个单独的文件就是一个模块。每一个模块都是一个单独的作用域,也就是说,在该模块内部定义的变量,无法被其他模块读取,除非定义为global
对象的属性。举个例子:
AMD
AMD 即
Asynchronous Module Definition
,中文名是异步模块定义的意思。它是一个在浏览器端模块化开发的规范由于不是JavaScript原生支持,使用AMD规范进行页面开发需要用到对应的库函数,也就是大名鼎鼎
RequireJS
,实际上AMD 是RequireJS 在推广过程中对模块定义的规范化的产出RequireJS 主要解决两个问题
语法
requireJS定义了一个函数 define,它是全局变量,用来定义模块
在页面上使用require函数加载模块
require()函数接受两个参数
require()函数在加载依赖的函数的时候是异步加载的,这样浏览器不会失去响应,它指定的回调函数,只有前面的模块都加载成功后,才会运行,解决了依赖性的问题。
CMD
CMD 即
Common Module Definition
通用模块定义,CMD规范是国内发展出来的,AMD有个requireJS,CMD有个浏览器的实现SeaJS,SeaJS要解决的问题和requireJS一样,只不过在模块定义方式和模块加载(可以说运行、解析)时机上有所不同语法
Sea.js 推崇一个模块一个文件,遵循统一的写法
define
因为CMD推崇
require
require 是 factory 函数的第一个参数
require 是一个方法,接受 模块标识 作为唯一参数,用来获取其他模块提供的接口
exports
exports 是一个对象,用来向外提供模块接口
module
module 是一个对象,上面存储了与当前模块相关联的一些属性和方法
AMD与CMD区别
关于这两个的区别网上可以搜出一堆文章,简单总结一下
最明显的区别就是在模块定义时对依赖的处理不同
这种区别各有优劣,只是语法上的差距,而且requireJS和SeaJS都支持对方的写法
AMD和CMD最大的区别是对依赖模块的执行时机处理不同,注意不是加载的时机或者方式不同
很多人说requireJS是异步加载模块,SeaJS是同步加载模块,这么理解实际上是不准确的,其实加载模块都是异步的,只不过AMD依赖前置,js可以方便知道依赖模块是谁,立即加载,而CMD就近依赖,需要使用把模块变为字符串解析一遍才知道依赖了那些模块,这也是很多人诟病CMD的一点,牺牲性能来带来开发的便利性,实际上解析模块用的时间短到可以忽略
为什么我们说两个的区别是依赖模块执行时机不同,为什么很多人认为ADM是异步的,CMD是同步的(除了名字的原因。。。)
同样都是异步加载模块,AMD在加载模块完成后就会执行该模块,所有模块都加载执行完后会进入require的回调函数,执行主逻辑,这样的效果就是依赖模块的执行顺序和书写顺序不一定一致,看网络速度,哪个先下载下来,哪个先执行,但是主逻辑一定在所有依赖加载完成后才执行
CMD加载完某个依赖模块后并不执行,只是下载而已,在所有依赖模块加载完成后进入主逻辑,遇到require语句的时候才执行对应的模块,这样模块的执行顺序和书写顺序是完全一致的
这也是很多人说AMD用户体验好,因为没有延迟,依赖模块提前执行了,CMD性能好,因为只有用户需要的时候才执行的原因
The text was updated successfully, but these errors were encountered: