模块化规范出现前，js是如何实现模块化的呢？

由于一开始js被设计出来时只是用于简单的表单验证或者实现一些页面效果，所以实现模块化编程压根不是js设计者需要考虑的事情，而是怎么简单怎么来

但随着浏览器的不断发展，js不再仅仅用于上述的简单场景之中了，而是需要构建一个复杂的web应用程序，这时候js的架构设计就完全不够用了，因为没有模块化的规范，导致js中所有定义的东西都是全局的，这样就会造成 全局环境 的污染同时产生 变量名冲突 的问题，这样的话想用js去构建大型应用根本就是天方夜谭，那该如何是好呢？

在各种模块化规范出来之前，前辈们利用当时js的特性模拟出了私有作用域，从而 部分 解决了无模块化带来的问题，那是如何解决的呢？其实原理很简单：利用函数作用域作为私有作用域，再结合IIFE(自执行函数)和闭包的技术，实现变量私有化，具体实现如下

var a = (function(){
    var name = 'yy'
    return {
        name: name
    } 
})()

这样确实能解决全局污染的问题，但是面对模块之间互相依赖时，这样的方式就会带来 维护性 的问题

假设上述模块需要依赖jquery，那么代码就会变成这样

var a = (function(jquery){
    var name = jquery('#name').text()
    return {
        name: name
    } 
})(jquery)

其实就是将所需要的依赖的模块当成 参数 传递进这个IIFE中，但这样做的方式前提是jquery已经 导入并可用，那么在脚本引入的顺序上，jquery脚本就要 先于 IIFE所在脚本引入，假设IIFE在IIFE.js脚本中，那么引入的顺序形如

...
<script> src='jquery.js'</script>
<script> src='IIFE.js'</script>
...

这个例子中也许你不会感觉到有太大的问题，但是如果脚本数量多起来，各个脚本顺序的维护是十分头疼的事情，并且一旦引入顺序出现一点问题，就会造成程序的报错崩溃

结语

这种IIFE的方案根本上的缺点是脚本的依赖关系需要我们自己来维护，从而会大大增加程序出错的概率，因此各种模块化的规范就出现了，它们对于脚本之间的依赖关系的处理都是 自动 进行的，无需我们来操心，从而可以大大提高程序的可维护性和可扩展性

那它们是具体如何实现的呢，欲知后事如何，请听下回分解~