JavaScript模块化开发的演进历程

最新推荐文章于 2024-01-09 00:47:10 发布

IronKee

最新推荐文章于 2024-01-09 00:47:10 发布

阅读量1.3k

点赞数 2

分类专栏： JavaScript 文章标签： javascript 前端

本文链接：https://blog.csdn.net/ironkee/article/details/121939224

版权

JavaScript 专栏收录该内容

14 篇文章 2 订阅

订阅专栏

写在前面的话

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/1190000015302578#articleHeader7
JavaScript模块化开发的演进历程
https://segmentfault.com/a/1190000011081338
详解JavaScript模块化开发
https://segmentfault.com/a/1190000000733959
精读 js 模块化发展
https://zhuanlan.zhihu.com/p/26118022
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/1190000015139548
CommonJS AMD CMD对比
https://segmentfault.com/a/1190000009899566