我们知道在刚开始，JavaScript语言是没有模块化的概念，但是随着前端能干的事情越来越多，事情越来越复杂，模块化就显得不可或缺，当然，这还要得益于node.js和commonjs走入了人们的视线。
关于commonjs
我们先来看一下，它在维基百科的定义
CommonJS 是一个项目，其目标是为 JavaScript 在网页浏览器之外创建模块约定。创建这个项目的主要原因是当时缺乏普遍可接受形式的 JavaScript 脚本模块单元，模块在与运行JavaScript 脚本的常规网页浏览器所提供的不同的环境下可以重复使用。
由此可见commonjs主要是服务于服务器端的，并不是前端，但载体确是javascript，所以对推动前端模块化，具有深远影响。
关于为什么要使用前端模块化
当然，如果业务场景简单，是没有必要使用。但是随着逻辑的复杂，我们遇到了各种各样的问题。可以想一想，你是否在开发中也遇到了下面的问题。
随着代码的增多，我们会让html和js代码解耦，也就是说，我们会把js代码放在一个单独的文件中，使用script引入。但是随着更多开发者的加入，我们会引入许多js文件，如下：
<script src="./a.js"></script>
<script src="./b.js"></script>
//a.js
var name='123';
//b.js
var name ='456';
其实这个时候问题就已经来了，因为没有封闭作用域的概念，声明的变量存在在全局中，造成全局污染，而开发者本身又很难保证自己维护的js文件不和其他的js文件发生冲突，于是代码开发和维护简直成了噩梦。
为了解决全局污染，命名冲突的问题，聪明的开发者想到，那我们就使用命名空间就好了嘛，其实这里已经有一点模块化的意思了。如下
<script src="./a.js"></script>
<script src="./b.js"></script>
//a.js
app.moduleA = {
}
app.moduleA.name = 'lilei'
//b.js
app.moduleB = {
}
app.moduleB.name = 'hanmeimei'
这种方式解决了命名冲突，但是还有一个问题，就是我们在b模块中可以获取moduleA的name，同时在moduleA毫无感知的情况下去修改它。
为了解决这个问题，聪明的开发者利用了javascript的函数作用域，闭包的特性去解决这一问题。如下
<script src="./a.js"></script>
<script src="./b.js"></script>
//a.js
app.moduleA = (function(){
var name='lilei';
return function getName(){
return name};
})()
//b.js
app.moduleB = (function(){
var name='hanmeimei';
return function getName(){
return name};
})()
这样我们就保护了我们的数据。但是还是有不足的地方，者两个文件的加载有先后顺序，如果加载的两个文件之间有依赖，维护这种依赖关系就变得很复杂。
