前端为什么要模块化？模块化的好处?
- javascript这门语言本身被创造出来时，它是基于浏览器的，作为嵌入式的脚本语言。随着web的发展，Ajax技术得到广泛应用，jQuery等前端库层出不穷，前端代码日益膨胀，这时候JavaScript作为嵌入式的脚本语言的定位动摇了。
- 避免变量污染，命名冲突
- 提高代码复用率
- 提高代码维护性
- 依赖（引入库）关系的管理
模块化的发展
一、原始
1、函数封装
函数的一个功能就是实现特定逻辑的一组语句打包。
在一个文件里面编写几个相关函数就是最开始的模块了
function m1(){
//...
}
function m2(){
//...
}
这样做的缺点很明显，污染了全局变量，并且不能保证和其他模块起冲突
2、对象封装
为了解决函数过多污染全局变量的问题，可以将所有模块成员（方法function）封装在一个对象中
var module = new Object({
a:0,
b:'哈哈',
m1:function (){ ``` },
m2:function (){ ``` }
})
这样两个函数就被包在这个对象中，当我们要使用的时候，就是调用这个对象的属性。
但是又一个问题来了，这种写法会暴露全部的模块成员（方法或变量），内部状态可以被外部改变，比如外部代码可直接改变对象中的值
module.b= '啦啦啦';
module.m1=function (){ ``` };
3、立即执行函数（也可以说是闭包）
最后，人们又找到了新的方法——立即执行函数（也可以说是闭包），这样就可以达到不暴露私有成员的目的
var module = (function (){
var _count = 5;
var m1 = function (){ ``` };
var m2 = function (){ ``` };
return{
m1:m1,
m2:m2
}
})()
二、规范
1、commonjs 规范
09年出现了nodejs:，就是将 javascrit 脱离浏览器运行. 但是带来了问题，js 只剩下了语法规范（ECMAScript）, 没有了 DOM 与 BOM。
这个时候需要为脱离浏览器的 js 提供新的 api，就引入了 commonjs 规范，也引入了模块的概念。commonjs 是一个更偏向于服务器端的规范。Node.js采用了CommonJS规范。
Commonjs解决了模块化的问题，并且可以用在浏览器中，但是Commonjs是同步加载模块，在浏览器访问时，js 都是放在服务器中的, 需要加载完才可以用，而加载限制于网速，网速差的时候会阻止浏览器的后续处理，停止后续的解析，用户体验不好。
2、AMD规范
为了解决这个问题，又出现了一个AMD规范，这个规范可以实现模块的异步加载。require.js采用了AMD规范。
AMD基本都是提前说明依赖模块，然后预加载这些模块，实际上这就要求你提前想好这些依赖，提前写好，不然写代码过程中要回到开头继续添加依赖。
3、CMD规范
CMD规范是sea.js在推广过程中的规范化产出，sea.js是另一种前端模块化工具，它的出现缓解了requireJS的几个痛点。
Seajs也是预加载依赖js，跟AMD的规范在预加载这一点上是相同的，明显不同的地方是调用和声明依赖的地方。
CMD标准倾向于在使用过程中提出依赖，就是不管代码写到哪突然发现需要依赖另一个模块，那就在当前代码用require引入就可以了，即按需加载，规范会帮你搞定预加载。
但是AMD标准让你必须提前在头部依赖参数部分写好。这就是最明显的区别。（AMD和CMD都是用difine和require）
网友评论