js前端模块化（个人笔记）

要了解模块化，首先我们得知道代码模块化得目的什么，我们为什么要代码模块化？其实不仅是前端，后端，不管是学啥的，都会将代码模块化，因为模块化以后得代码更便于我们管理和使用，还能降低代码得耦合度，提高复用性，还能解决命名冲突的麻烦。

那现在我们来讲讲前端代码模块化的历史变迁。

”远古开荒“时期

那时候我们的代码模块化也只是简单的将代码打包在一个一个的函数中。

function () {
   ...
}
function () {
   ...
}

这样打包代码随着代码的体积变大，代码会越来难以维护并且很容易因为都是定义在全局上面很容易产生命名冲突，给开发人员造成巨大的困难。

”铁器“时代

后来的程序猿，为了解决这种全局冲突，于是开始将代码打包在一个个的对象当中

var a = {    q: function () {        console.log(123);    }
    w: function () {
        console.log('zzz')
    }
    name: '大帅逼'}a.q()  //123
a.w()   //zzz
a.name  // 大帅逼

这样写虽然解决了命名冲突，但是模块中的代码却会受对象外部的影响，这样使得模块化将毫无意义。

a.name= '我才是大帅逼'

于是代码模块化又迎来一次革新。

“四大发明”时代

自执行函数的使用使得代码模块化向前迈进了一大步

//使用立即执行函数 通过函数作用域解决命名冲突 (function(globalVariable){    globalVariable.test = function() {}    //声明各种变量函数都不会污染全局的作用 })(globalVariable)

自执行函数的使用将上面两大问题基本上全解决了。

”电器“时代

上面的发展都是模块化发展的基础，为了将模块化规范，于是nodeJS搞出了第一个模块化规范CommonJs：CommonJS 的出发点： JS 没有完善的模块系统，标准库较少，缺少包管理工具。（虽然这些东西，在后端语言中已经是早就被玩的不想玩的东西了）伴随着 NodeJS 的兴起，能让 JS 可以在任何地方运行，特别是服务端，以达到也具备 Java、C#、PHP这些后台语言具备开发大型应用的能力，所以 CommonJS 应运而生。

 //CommonJS module.exports= {  //a.js    a:1}//orexports.a=1var module = require('./a.js')  //b.jsmodule.a  // 1

CommonJS 是同步导⼊，因为⽤于服务端，⽂件都在本地，同步导⼊即使卡住主线程影响也不⼤。但是不适用于浏览器端，于是又有了AMD和CMD，两者都是异步导⼊，因为⽤于浏览器，需要下载⽂件，如果也采⽤同步导⼊会对渲染有很⼤影响。不过现在用的不多，了解一下语法即可。

//AMD define(['./a','./b'],function(require,factory){     //加载模块完毕使用     a.do()     b.do() }); //CMD  define (function(require,exports,module){     //加载模块     //可以把 require 写在函数的任意位置实现延迟加载     var a = require('./a')     a.doSomthing() })

向前发展的历史

历史的脚步是不可能止步的，ES6的出现又让模块化进一步发展，ES6的出现，为前端模块化又推进了一步：

//引入模块API import xxx from './a.js' import {} from './a.js'//导出模块 exports default xxx exports  xxx

最后：

总结一下，模块化的发展说到底都是为了封装代码，将代码打包成块或者一个个的文件，便于代码管理和维护，便于引用和导入模块，防止全局污染，提高代码的可复用性。

能看到这里的呀，都是人才。

本文参考juejin.cn/post/684490…