JavaScript模块化开发的演进历程

写在前面的话

js模块化历程记录了js模块化思想的诞生与变迁
历史不是过去，历史正在上演，一切终究都会成为历史
拥抱变化，面向未来

什么是模块化

模块是系统中职责单一且可替换的部分，有了模块，我们就可以更方便地使用别人的代码，想要什么功能，就加载什么模块
模块化是一种规范，一种约束，这种约束会大大提升开发效率。将每个js文件看作是一个模块，每个模块通过固定的方式引入，向外暴露指定的内容的方式
按照js模块化的设想，一个个模块按照其依赖关系组合，最终插入到主程序中。

为什么需要模块化

js作为脚本语言，一开始只是用来在网页上进行表单校验、点击事件、实现简单的动画效果等,1999年的时候，绝大部分工程师做JS开发的时候就直接将变量定义在全局，做的好一些的或许会做一些文件目录规划，将资源归类整理，这种方式被称为直接定义依赖
前端工程师在页面上写写js就能搞定需求，代码简单的堆在一起，只要能从上往下依次执行，实现基本的交互效果就可以了
后来项目越来越复杂，功能越来越多，业务逻辑越来越多，代码量也越来越大，前端开发得到重视
JavaScript却没有为组织代码提供任何明显帮助，甚至没有类的概念，更不用说模块（module）了
即使有规范的目录结构，也不能避免由此而产生的大量全局变量，这就导致了一不小心就会有变量冲突的问题，就好比下面这个例子中的onShow。

js逐渐拆分，项目中引入的js越来越多，前端代码变成了这样：

<script src="a.js"> 
       script> <script src="b.js"> 
        script> <script src="util/wxbridge.js"> 
         script>

//A同学a.js function onShow(){ 
     //xxxx} //B同学b.js function onShow(){ 
     //xxxx} //重名概率太高

容易冲突容易覆盖

这样带来的问题

全局变量污染：各个文件的变量都是挂载到window对象上，污染全局变量。
变量重名：不同文件中的变量如果重名，后面的会覆盖前面的，造成程序运行错误。
文件依赖顺序：多个文件之间存在依赖关系，需要保证一定加载顺序问题严重。

模块化解决方案

命令空间模式
闭包模块化模式（IIFE结合闭包）
面向对象开发
YUI
CommonJS
AMD
CMD
ES6模块化

命名空间模式

无法避免的全局变量污染
2002年左右，有人提出了命名空间模式的思路，用于解决全局变量被污染的问题

不过这种方式，毫无隐私可言，本质上就是全局对象，谁都可以来访问并且操作，一点都不安全

//A同学a.js var A={ 
      onShow(){ 
     }， onXXX(){ 
     }， //... } //B同学b.js var B={ 
      onShow(){ 
     } } //还是会重名，但比以前好一点 //比如 其他班A同学，由于合作，引入a.js、b.js  var A={ 
      onShow(){ 
     } }

模块太臃肿，不敢私自拆模块，又重名
拆模块带来的问题，私有属性乱，代码不灵活

多个文件之间存在依赖关系，需要保证加载顺序

//a.js var a=''//重名，全局变量不安全 var A={ 
      a:''//不重名，用起来比较乱 A1：{ 
     } A2：{ 
      B:{ 
      a:'' } } } console.log(A.A2.B.a);

闭包模块化模式（IIFE结合闭包）

2003年左右就有人提出利用IIFE结合闭包特性，以此解决私有变量的问题，这种模式被称为闭包模块化模式
Imdiately Invoked Function Expression，立即执行的函数表达式

像如下的代码所示，就是一个匿名立即执行函数:

(function(window, undefined){ 
      // 代码...  })(window);

js文件都是使用IIFE包裹的，各个js文件分别在不同的作用域中，相互隔离，最后通过闭包的方式暴露变量

// a.js var a = (function(cNum){ 
      var aStr = 'a'; var aNum = cNum + 1; return { 
      aStr: aStr, aNum: aNum }; })(cNum); // c.js var cNum = (function(){ 
      var cNum = 0; return cNum; })(); //index.js ;(function(a, cNum){ 
      console.log(a.aNum, cNum); })(a, cNum)

//引入 <script src="./c.js"> 
       script> <script src="./a.js"> 
        script> <script src="./index.js"> 
         script>

这种方法解决了
私有属性乱，代码不灵活
问题：命名会重复，文件依赖顺序仍然需要在入口处严格保证加载顺序

面向对象开发和 YUI

面向对象开发

// b.js var b = (function(a){ 
      var bStr = a.aStr + ' bb'; return { 
      bStr: bStr }; })(a);

YUI（雅虎）

CommonJs – 具有里程碑式意义的模块化工具

2009年Nodejs发布，其中Commonjs是作为Node中模块化规范以及原生模块面世的
原生Module对象，每个文件都是一个Module实例（模块）
文件内通过require对象引入指定模块
所有文件加载均是同步完成
通过module.exports或者exports来暴露接口或者数据

语法（关键字）

module export require

// a.js module.exports = { 
    aStr: 'a' };

// b.js var a = require('./a'); exports.bStr = a.aStr + ' bb';

// index.js var a = require('./a'); var b = require('./b'); console.log(a.aNum, b.bStr);

源码理解

//module.js function Module(id, parent) { 
    this.id = id; // 文件验重的表示，字符串形式的绝对路径 this.exports = { 
   }; this.parent = parent; if (parent && parent.children) { 
    parent.children.push(this); } this.filename = null; this.loaded = false; this.children = []; } module.exports = Module; var module = new Module(filename, parent); //在commonjs规范中每个模块都是一个Module实例 //require方法调用__load方法加载模块文件 //require的返回值是module.exports || {} //exports = module.exports

//gulp 'use strict'; var util = require('util'); //... function Gulp() { 
    //... } Gulp.prototype.task = Gulp.prototype.add; Gulp.prototype.run = function() { 
    var tasks = arguments.length ? arguments : ['default']; this.start.apply(this, tasks); }; //... var inst = new Gulp(); module.exports = inst;

var gulp = require('gulp')

优点

强大的查找模块功能，开发十分方便
标准化的输入输出，非常统一
每个文件引入自己的依赖，最终形成文件依赖树
解决了重名问题
解决了私有变量问题
解决了加载顺序问题
module export require

局限性

Commonjs在服务端可以实现模块同步加载，服务器上通过require加载资源是直接读取文件的，因此中间所需的时间可以忽略不计
浏览器这种需要依赖HTTP获取资源的，时间消耗非常大，资源的获取所需的时间不确定，这就导致必须使用异步机制，代表主要有2个：AMD和CMD

AMD（Asynchronous Module Definition）

AMD与Commonjs一样都是js模块化规范，是一套抽象的约束，2009年诞生
RequireJs，是AMD规范的具体实现（RequireJs诞生之后，推广过程中产生的AMD规范）

语法

//引入 require([module], callback); //定义 define(id?, dependencies?, factory);

示例

//引入require.js <script src="/require.js" data-main="/main" async="async" defer> 
     script>

//main.js requirejs.config({ 
    //... paths: { 
    a: '/a.js', c: '/c.js', index: '/index.js' } }); require(['index'], function(index){ 
    index(); });

//a.js define('a', ['c'], function(c){ 
    return { 
    aStr: 'aStr', aNum: c.cNum + 1 } });

//c.js define('c', function(){ 
    return { 
    cNum: 0 } });

//index/js define('index', ['a', 'c'], function(a, c){ 
    return function(){ 
    console.log(a.aNum, c.cNum); } });

CMD（Common Module Definition）

同样是受到Commonjs的启发，国内（阿里）诞生了CMD规范。该规范借鉴了Commonjs的规范与AMD规范，在两者基础上做了改进。
SeaJs是CMD规范的实现，跟RequireJs类似，CMD也是SeaJs推广过程中产生的规范

AMD CMD区别

AMD，依赖前置，提前执行

CMD，按需加载，延迟执行，用到时才运行

// AMD define( ['./a', './b'], // <- 前置声明，也就是在主体运行前就已经加载并运行了模块a和模块b function (a, b) { 
      a.doSomething(); b.doSomething(); } )

// CMD define(function (require) { 
      var a = require('./a'); // <- 运行到此处才开始加载并运行模块a a.doSomething(); var b = require('./b'); // <- 运行到此处才开始加载并运行模块b b.doSomething(); })

ES6中的模块化

2015年6月，ES6发布，JavaScript在语言标准的层面上，实现了模块功能，使得在编译时就能确定模块的依赖关系，以及其输入和输出的变量，不像 CommonJS、AMD之类的需要在运行时才能确定
关键字import，export，default，as，from
CommonJS和ES6有两点主要的区别
- CommonJS 模块输出的是一个值的拷贝，ES6 模块输出的是值的引用
- CommonJS 模块是运行时加载（动态加载），ES6 模块是编译时输出（静态解析）

一个经典的例子

// counter.js exports.count = 0 setTimeout(function () { 
    console.log('500ms后自增的count的值为', ++exports.count, '') }, 500) // commonjs.js const { 
   count} = require('./counter') setTimeout(function () { 
    console.log('commonjs：1000ms后读取count的值是', count) }, 1000) //es6.js import { 
   count} from './counter' setTimeout(function () { 
    console.log('es6：1000ms后读取count的值是', count) }, 1000)

分别运行 commonjs.js 和 es6.js：

➜ test node commonjs.js 500ms后自增的count的值为 1 commonjs：1000ms后读取count的值是 0 ➜ test babel-node es6.js 500ms后自增的count的值为 1 es6：1000ms后读取count的值是 1

示例解析

这个例子解释了CommonJS 模块输出的是值的拷贝，一旦输出一个值，模块内部的变化就影响不到这个值。
ES6 模块的运行机制与 CommonJS 不一样。JS 引擎对脚本静态分析的时候，遇到模块加载命令import，就会生成一个只读引用。等到脚本真正执行时，再根据这个只读引用，到被加载的那个模块里面去取值，原始值变了，import加载的值也会跟着变

Tree-Shaking

Tree-Shaking，代表的大意就是删除没用到的代码。这样的功能对于构建大型应用时是非常好的，因为日常开发经常需要引用各种库，但大多时候仅仅使用了这些库的某些部分，并非需要全部，此时Tree-Shaking如果能帮助我们删除掉没有使用的代码，将会大大缩减打包后的代码量，减少js包的大小，从而减少用户等待的时间。

tree-shaking的实现

著名的代码压缩优化工具uglify，uglify完成了javascript的DCE（dead code elimination）
其实关于tree shaking的实现原理，找到你整个代码里真正使用的代码，打包进去，那么没用的代码自然就剔除了。
ES6模块依赖关系是确定的，和运行时的状态无关，可以进行可靠的静态分析，这就是tree-shaking的基础
tree shaking首先会分析文件项目里具体哪些代码被引入了，哪些没有引入，然后将真正引入的代码打包进去

支持tree-shaking的构建工具

Rollup
Webpack2
closure compiler

ES6支持度

目前浏览器和Node.js的支持程度并不理想
Chrome：51 版起便可以支持 97% 的 ES6 新特性
Firefox：53 版起便可以支持 97% 的 ES6 新特性
Safari：10 版起便可以支持 99% 的 ES6 新特性
IE：IE7~11 基本不支持 ES6（IE内心独白：这种事别扯上我好不好）
Node.js：6.5 版起便可以支持 97% 的 ES6 新特性。（6.0 支持 92%）
大部分项目已通过 babel 或 typescript 提前体验

写在后面的话

2015 年提出的标准，依然没有得到完全实现
JS模块化与落实都非常缓慢，与 javascript 越来越流行的趋势逐渐脱节

参考资料模块化

JavaScript模块化发展
https://segmentfault.com/a/02578#articleHeader7
JavaScript模块化开发的演进历程
https://segmentfault.com/a/81338
详解JavaScript模块化开发
https://segmentfault.com/a/33959
精读 js 模块化发展
https://zhuanlan.zhihu.com/p/
JavaScript 模块化历程
http://web.jobbole.com/83761/
闲聊——浅谈前端js模块化演变
http://www.cnblogs.com/qingkong/p/5092003.html
Javascript模块化编程（一）：模块的写法
http://www.ruanyifeng.com/blog/2012/10/javascript_module.html
JavaScript语言的历史
http://javascript.ruanyifeng.com/introduction/history.html
require() 源码解读
http://www.ruanyifeng.com/blog/2015/05/require.html
Node中的Module源码分析
https://segmentfault.com/a/39548
CommonJS AMD CMD对比
https://segmentfault.com/a/99566

参考资料 tree-shaking

浅谈性能优化之Tree Shaking
https://www.jianshu.com/p/5028ebad5bb8
tree-shaking简单分析
https://www.jianshu.com/p/ff0230
Tree-Shaking性能优化实践 – 原理篇
https://juejin.im/post/5a4dc8e7279a9
Tree-Shaking性能优化实践 – 实践篇
https://www.colabug.com/2139553.html

Thanks!

发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/211694.html原文链接：https://javaforall.net

JavaScript模块化开发的演进历程

写在前面的话

延伸阅读 – JavaScript诞生（这也解释了JS为何一开始没有模块化）

什么是模块化

为什么需要模块化

这样带来的问题

模块化解决方案

命名空间模式

闭包模块化模式（IIFE结合闭包）

面向对象开发和 YUI

CommonJs – 具有里程碑式意义的模块化工具

语法（关键字）

源码理解

优点

局限性

AMD（Asynchronous Module Definition）

示例

CMD（Common Module Definition）

AMD CMD区别

ES6中的模块化

一个经典的例子

分别运行 commonjs.js 和 es6.js：

示例解析

Tree-Shaking

tree-shaking的实现

支持tree-shaking的构建工具

ES6支持度

写在后面的话

参考资料模块化

参考资料 tree-shaking

Thanks!

关于作者

全栈程序员-站长

发表回复

JavaScript模块化开发的演进历程

写在前面的话

延伸阅读 – JavaScript诞生（这也解释了JS为何一开始没有模块化）

什么是模块化

为什么需要模块化

这样带来的问题

模块化解决方案

命名空间模式

闭包模块化模式（IIFE结合闭包）

面向对象开发 和 YUI

CommonJs – 具有里程碑式意义的模块化工具

语法（关键字）

源码理解

优点

局限性

AMD（Asynchronous Module Definition）

示例

CMD（Common Module Definition）

AMD CMD区别

ES6中的模块化

一个经典的例子

分别运行 commonjs.js 和 es6.js：

示例解析

Tree-Shaking

tree-shaking的实现

支持tree-shaking的构建工具

ES6支持度

写在后面的话

参考资料 模块化

参考资料 tree-shaking

Thanks!

关于作者

全栈程序员-站长

相关推荐

RAII机制介绍

月之暗面（Kimi）近期完成5亿美元C轮融资，由IDG领投1.5亿美元，阿里、腾讯、王慧文等老股东超额认购，投后估值达43亿美元

进入实用主义时代：实测文心 4.5 Turbo 和 X1 Turbo 能做什么？

filter-policy_maven reimport

中标麒麟6桌面版安装达梦7图解

redission设置过期时间_设置redis过期时间

发表回复

面向对象开发和 YUI

参考资料模块化