# 模块化
之前有提到过模块化是仅从`js`层面来分析和解决问题的。
## 无模块时代
在ajax还未提出之前，js还只是一种“玩具语言”，由[`Brendan Eich`](https://baike.baidu.com/item/Brendan%20Eich)花了不到十天时间发明，用来在网页上进行表单校验、实现简单的动画效果等等，你可以回想一下那个网页上到处有公告块飘来飘去的时代。
这个时候并没有前端工程师，服务端工程师只需在页面上随便写写js就能搞定需求。那个时候的前端代码大概像这样，代码简单的堆在一起，只要能从上往下依次执行就可以了。
```
var a = 1;
if(xx){
//.......
}
else{
//xxxxxxxxxxx
}
for(var i=0; i<10; i++){
//........
}
element.onclick = function(){
//.......
}
```
## 模块萌芽时代（了解）
2006年，ajax的概念被提出，前端拥有了主动向服务端发送请求并操作返回数据的能力，随着Google将此概念的发扬光大，传统的网页慢慢的向“富客户端”发展。前端的业务逻辑越来越多，代码也越来越多，于是一些问题就暴漏了出来：
### 全局变量的灾难
1. 小明定义了 i=1
2. 小刚在后续的代码里：i=0
3. 小明在接下来的代码里：if(i==1){...} //悲剧
### 函数命名冲突
>[success] 项目中通常会把一些通用的函数封装成一个文件，常见的名字有utils.js、common.js...
1. 小明定义了一个函数：function formatData(){ }
2. 小刚想实现类似功能，于是这么写：function formatData2(){ }
3. 小光又有一个类似功能，于是：function formatData3(){ }
### 依赖关系不好管理
>[success] b.js依赖a.js，标签的书写顺序必须是
```
<script type="text/javascript" src="a.js"></script>
<script type="text/javascript" src="b.js"></script>
```
顺序不能错，也不能漏写某个。在多人开发的时候很难协调。
## 模块化需要解决的问题
从以上的尝试中，可以归纳出js模块化需要解决那些问题：
1\. 如何安全的包装一个模块的代码？（不污染模块外的任何代码）
2\. 如何唯一标识一个模块？
3\. 如何优雅的把模块的API暴漏出去？（不能增加全局变量）
4\. 如何方便的使用所依赖的模块？
围绕着这些问题，js模块化开始了一段艰苦而曲折的征途。
