前端模块化之旅（一）：因何生它

前端模块化之旅(一)

随着互联网的快速发展，人们不单单只是需要一个网页了，功能更复杂、交互更丰富的 WebAPP 成为开发者需要面对的日常工作内容。随之而来的是更加庞大与更加复杂的 JavaScript 代码，如此而来，仅仅依靠着我们之前面向对象的 JavaScript 进行代码封装已很难满足生产需求，特别是在团队协作的复杂项目中，JavaScript 模块化已成为一个迫切的需求。

原始社会的生产

开始的开始 Music ..♫.♪.♫.♪...我们都是...咳咳，我们都会使用如下的方式写代码，将独立通用的的功能独立成一个个函数：

function bar(){
    //do something
}
function log(){
    //do something
}

这都是最初得美好，那些习以为常的习惯，回忆ing...这是最原始的模块，需要使用调用就好。但是但是，使用过就会知道这样会污染全局变量，并且很容易造成 命名冲突，好吧，它属于最初的美好。

后来，为了解决上面青春期的问题，我们选择了面向对象写法，引入 Namespace (命名空间)，将代码进行简单封装：

var myModule = {
    bar: function(){
        //do something
    },
    log: function(){
        //do something
    }
}

//调用
myMoudle.bar();

这种方式看似还可以，减少了全局变量，能缓解严峻的问题。但是这并不安全，因为实质上是对象，会暴露所有的模块成员，内部状态可以被外部读写。

没办法，出了问题继续解决，我们采用匿名闭包的写法（Immediately-Invoked Function Expression，IIFE）：

var myModule = (function(){
    var _log = "hello world";
    var log = function(){
        console.log(_log);
    };

    return {
        log: log
    }
})();

//引用
myModule.log();//hello world
myModule._log;//undefined

如此，外部就无法读写到内部的成员（_log）。这时候需求又改变了，你的模块不再是简单的一个模块，而是一个功能很大的模块，需要分成几个部分，这些部分存在相互之间的 依赖关系。好吧，我们来引入依赖：

var myModule = (function($){
    var $log = $('.log');
    var log = function(){
        console.log($log);
    };

    return {
        log: log
    }
})(jQuery);

//引用
myModule.log();

这样我们在代码中引入了jQuery，方法间存在依赖关系；

至此，我们用简陋的工具，和无比勤劳的双手为子孙们搭建了发展的架子，为后续社会发展出更先进好用的模块化工具打下了基石，感谢祖辈们的探索！

文明社会的探索

飞速变化的年代里，人们总是不满足于现状。有了前人的封装性还不够，我们引入 JS 文件时是靠不断追加 标签得以实现，每个标签引入顺序是有要求的。
当我们引入的文件增多，除了看起来比较累赘，还会出现比较多的依赖关系，而这种写法是无法突出这种关系的，我们需要 依赖管理，也让 后续维护 基本上变得无法进行。