js模块化历程.docxVIP

js 模块化历程这是一篇关于js模块化历程的长长的流水账，记录js模块化思想的诞生与变迁，展望ES6模块化标准的未来。经历过这段历史的人或许会感到沧桑，没经历过的人也应该知道这段历史。无模块时代在ajax还未提出之前，js还只是一种“玩具语言”，由Brendan Eich花了不到十天时间发明，用来在网页上进行表单校验、实现简单的动画效果等等，你可以回想一下那个网页上到处有公告块飘来飘去的时代。这个时候并没有前端工程师，服务端工程师只需在页面上随便写写js就能搞定需求。那个时候的前端代码大概像这样：if(xx){//.......}else{//xxxxxxxxxxx}for(var i=0; i10; i++){//........}element.onclick = function(){//.......}代码简单的堆在一起，只要能从上往下依次执行就可以了。模块萌芽时代2006年，ajax的概念被提出，前端拥有了主动向服务端发送请求并操作返回数据的能力，随着Google将此概念的发扬光大，传统的网页慢慢的向“富客户端”发展。前端的业务逻辑越来越多，代码也越来越多，于是一些问题就暴漏了出来：全局变量的灾难小明定义了 i=1小刚在后续的代码里：i=0小明在接下来的代码里：if(i==1){…} //悲剧2. 函数命名冲突项目中通常会把一些通用的函数封装成一个文件，常见的名字有utils.js、common.js…小明定义了一个函数：function formatData(){ }小刚想实现类似功能，于是这么写：function formatData2(){ }小光又有一个类似功能，于是：function formatData3(){ }……避免命名冲突就只能这样靠丑陋的方式人肉进行。3. 依赖关系不好管理b.js依赖a.js，标签的书写顺序必须是script type=text/javascript src=a.js/scriptscript type=text/javascript src=b.js/script顺序不能错，也不能漏写某个。在多人开发的时候很难协调。萌芽时代的解决方案：用自执行函数来包装代码modA = function(){var a,b; //变量a、b外部不可见return {add : function(c){a + b + c;},format: function(){//......}}}()这样function内部的变量就对全局隐藏了，达到是封装的目的。但是这样还是有缺陷的，modA这个变量还是暴漏到全局了，随着模块的增多，全局变量还是会越来越多。2. java风格的命名空间为了避免全局变量造成的冲突，人们想到或许可以用多级命名空间来进行管理，于是，代码就变成了这个风格：app.util.modA = xxx;app.tools.modA = xxx;app.tools.modA.format = xxx;Yahoo的YUI早期就是这么做的，调用的时候不得不这么写：app.tools.modA.format();这样调用函数，写写都会觉得恶心，所以这种方式并没有被很多人采用，YUI后来也不用这种方式了。3. jQuery风格的匿名自执行函数(function(window){//代码window.jQuery = window.$ = jQuery;//通过给window添加属性而暴漏到全局})(window);jQuery的封装风格曾经被很多框架模仿，通过匿名函数包装代码，所依赖的外部变量传给这个函数，在函数内部可以使用这些依赖，然后在函数的最后把模块自身暴漏给window。如果需要添加扩展，则可以作为jQuery的插件，把它挂载到$上。这种风格虽然灵活了些，但并未解决根本问题：所需依赖还是得外部提前提供、还是增加了全局变量。模块化面临什么问题从以上的尝试中，可以归纳出js模块化需要解决那些问题：1. 如何安全的包装一个模块的代码？（不污染模块外的任何代码）2. 如何唯一标识一个模块？3. 如何优雅的把模块的API暴漏出去？（不能增加全局变量）4. 如何方便的使用所依赖的模块？围绕着这些问题，js模块化开始了一段艰苦而曲折的征途。源自nodejs的规范CommonJs2009年，nodejs横空出世，开创了一个新纪元，人们可以用js来编写服务端的代码了。如果说浏览器端的js即便没有模块化也可以忍的话，那服务端是万万不能的。大牛云集的CommonJs社区发力，制定了Modules/1.0（/wiki/Modules/1.0）规范，首次定义了一个模块应该长啥样。具体来说，Modules/1.0规范包含以下内容：1. 模块的标识应遵循的规则（书写规范）2. 定义全局函数require，通过传入模块标