框架的种子模块

       如果我们想要开发一个前端的框架，那么首先应该考虑的不是这个框架有哪些具体的功能，而是我们的框架从代码的角度来看是什么样的结构。作为一个框架开发之初，我们总是期盼着我们的框架是高效的，可扩展和可维护的。作为一个第一次写框架的新人，可以预见的是1.我们会反复的修改我们的框架、2.我们会有很多小型的代码，它们会作为整体的一部分存在，3.“小型的代码”之间可能会有依赖关系存在。

       到此我们会自然而然的想到，我们的代码要如何组织呢？可以想到的是无论如何开发，我们的代码还是需要一个“基点”的，有了“基点”我们的代码就会有一个“家”来安身，在此先不考虑这个“家”里面如何组织结构，我们先要考虑的是在JavaScript的语言中，什么适合用来实现这个“基点”的概念。

       “家”或者说“基点”的初衷，让我想起了其他语言或者领域中“命名空间”这一感念，我们经常在其他语言中听到，某某代码是基于某命名空间下的，这种说法和我们刚刚提到的“基点”在用途上是相似的，在此我们不妨借鉴一下这个“命名空间”的概念，可是很显然JavaScript是没有内置命名空间这一概念的，那么我们用什么手段去实现它呢？我查找了一下其他框架的资料， 在资料上 命名空间要么是用对象来表示的，要么是用一个function来返回的，function中返回的其实还是一个对象。 仔细来想的话这样做是合理的，毕竟JavaScript是基于对象的语言，既然语言中所有的内容归根结底都是“对象”，那么命名空间又怎么能例外呢？

        在JavaScript中，对象是可以添加属性的，对象的属性可能是各种各样的“小对象”，小对象既可以是方法（function）也可以是其他对象（object） ，这样对象就形成了一个树形结构，我们可以在树中添加任何我们想添加的代码，这样看来我们可以随意的向对象中添加各种功能的“代码片段”作为属性，而这个对象也就是我们想要的“命名空间（家）”。

        我们知道，无论我们的框架写成了什么样子，它都是在浏览器中工作的，准确的说它是等网页加载完毕之后形成的环境中工作的，这个环境自然也是有全局作用域和局部作用域的，在浏览器中全局作用域指的是window对象，那么我们自己书写的“命名空间”放到哪里呢？可以放到window对象上，作为window对象的一个属性来存在。这样来看我们的“命名空间”就成了浏览器环境中的一个全局变量 ，因此它可以被其他代码所访问和使用。

        思考到这里，我们就需要看看市面上存在的框架们是如何实现的，通过参考它们的实现，我们可以初步判断自己的思考方式是否是正确的。参考过后，我们发现，框架主要分为三类：prototype.js为代表的一类，jQuery.js为代表的一类和angular.js、Vue为代表的一类。

第一类：prototype.js类：

       早期的框架如 prototype.js，motools.js 和 Base2.js 等框架它们不止会在全局作用域中申请一个全局变量作为“命名空间”，它们还在代码中入侵了JavaScript 语言的很多基本概念（这里的入侵是指prototype.js等框架扩展了JavaScript的原生对象）。在这里，我们感觉到这些框架在设计思路上表现出一种“很霸道”的态度——“JavaScript 这个语言很差劲，不过没关系，使用我们的框架，我们会弥补语言本身的缺陷”。

         在这里我们简单说一下，prototype.js是当年的一个“最强王者”级别的框架，我们刚刚说过它的设计思路很“霸道”，作为一种语言的框架，妄图概念语言本身，这甚至可以说是一种近乎狂妄的想法，但是它有这种狂妄的资格，事实上prototype.js真的差一点成为了JavaScript这个语言的“标准”，基于prototype.js衍生出了一些列的类库诸如（script.aculo.us,rico,Plotr,ProtoChart,Scripty2）以及一大堆的收费软件。这些插件在质量上和经典上都强于后来市面上水准参差不齐的JQuery插件。

         在这里我们赞美prototype.js，毫无疑问它很优秀，但是正是因为它的这份“优秀”和“霸道”，让它完全没有考虑“兼容其他框架”这一问题，这后来成为了它的一个致命缺陷。让我们来简单的猜想一下prototype.js的思考方式：1.JavaScript 本身很差劲，2.我很“牛”，能够弥补这种“差劲”，3.所以我不需要兼容别人，别人都应该向我靠拢。然而后来，历史用铁一样的事实告诉我们另一种思考方式：1.JavaScript本身有缺陷，2.所以它是会发展壮大的，3.这种发展是靠众人而非个人完成的，4.你不能兼容别人就很难赶上潮流，5.当语言发展到一个新的高度时，曾经的“王者”就会被人捧上神台“供起来”，作为经典“收藏起来”，却不会再在工作中使用它了。

第二类：jQuery.js类

        这一类框架是以jQuery、YUI、EXT为代表的一批框架，它们就像之前我们想的那样，在全局空间中存在一个全局变量作为框架的命名空间，然后在这个命名空间中像叠罗汉一样添加出一个树型结构的框架体系来。

        值得一提的是jQuery，它是用function来作为命名空间的，作为一个function，它将接收用户们传入的css 选择器 作为 “输入参数” ，然后在function中返回一个jQuery类的实例（对象）来工作。这种风格成为了jQuery风靡全球的重要优点——jQuery支持css的选择器来实现DOM节点的集体操作，我们经常这样写

        $("#div1").attr("name","div1").css("width",200);

        这句代码一方面反映了jQuery能接收“css选择器”作为输入参数（它的命名空间是个function），也反映了jQuery和prototype.js一样用"$"符号作为命名空间的简称。

        之前我们提到过，在早期的开发过程中，prototype.js是一个“王者”级别的框架很受大家的欢迎，那么在其风头正盛的时候，jQuery是无法与prototype正面抗衡的，然而二者都使用$符号作为框架命名空间的简称，所以如果想要同时使用二者而不发生兼容性错误，二者中就必须有人“做出让步”。毫无疑问，让步的是jQuery，它提供了一种被称为“多库共存”的机制，来实现这一让步

// 多库共存机制，源于jQuery 1.2var _jQuery = window.jQuery,      _$ = window.$;     //把可能冲突的变量名先保存一个_开头的备份。 jQuery.extend({     noConflict : function(deep){           window.$ = _$;

           if(deep){

               window.jQuery = _jQuery;

           }

           return jQuery;    } });