前端模块化发展史

第一阶段:  js刚诞生，使用js开发的程序规模极其小

在 JavaScript 语言刚刚诞生的时候，它仅仅用于实现页面中的一些小效果

那个时候，一个页面所用到的 JS代码 可能也就那么区区几百行的代码

在这种情况下，语言本身所存在的一些缺陷往往被大家有意的忽略，因为程序的规模实在太小，只要开发人员小心谨慎，往往不会造成什么问题

在这个阶段，也不存在专业的前端工程师，由于前端要做的事情实在太少，因此这一部分工作往往由后端工程师顺带完成

第一阶段发生的大事件：

• 1996年，NetScape（网景公司）将JavaScript语言提交给欧洲的一个标准制定阻止ECMA（欧洲计算机制造商协会）

• 1998年，NetScape在与微软浏览器IE的竞争中失利，宣布破产

第二阶段：因为AJAX出现，js能实现的功能多了，项目开始复杂

JavaScript本身不能向服务器发送请求，也就不能向服务器那边拿到数据，只能在页面中做一些简单的效果

但是因为ajax的出现，逐渐改变了 JavaScript 在浏览器中扮演的角色

现在，它不仅可以实现小的页面效果，还可以和服务器之间进行交互，以更好的体验 来改变数据

AJAX出现之后，JavaScript能实现的页面功能更多了，JS代码的数量开始逐渐增长，从最初的几百行，到后来的几万行，前端程序逐渐变得复杂

后端开发者压力逐渐增加，致使一些公司开始招募专业的前端开发者

但此时，前端开发者的待遇远不及后端开发者，因为前端开发者承担的开发任务相对于后端开发来说，还是比较简单的，通过短短一个月的时间集训，就可以成为满足前端开发的需要

究其根本原因，是因为前端开发还有几个大的问题没有解决，这些问题都严重的制约了前端程序的规模进一步扩大：

1. 浏览器引擎解释执行JS代码的速度太慢

2. 用户端的电脑配置不足

3. 更多的代码会带来了全局变量污染、依赖关系混乱等问题

上面三个问题，就像是阿喀琉斯之踵，成为前端开发挥之不去的阴影和原罪。

在这个阶段，前端开发处在一个非常尴尬的境地，它在传统的开发模式和前后端分离之间无助的徘徊

第二阶段的大事件：

1. IE浏览器制霸市场后几乎不再更新

2. ES4.0流产，导致JS语言10年间几乎毫无变化

3. 2008年ES5发布，仅解决了一些 JS API 不足的糟糕局面

第三阶段:  commonjs模块化方案诞生（前端模块化启蒙者) ,但commonjs模块化仅用于node.js服务端

时间继续向前推移，到了2008年，谷歌的 V8 引擎发布，将JS的执行速度推上了一个新的台阶，甚至可以和后端语言媲美

摩尔定律持续发酵，个人电脑的配置开始飞跃

突然间，制约前端发展的两大问题得以解决

此时，只剩下最后一个问题还在负隅顽抗，即全局变量污染和依赖混乱的问题，解决了它，前端便可以突破一切障碍，未来无可限量

于是，全世界的前端开发者在社区中激烈的讨论，想要为这个问题寻求解决之道......

2008年，有一个名叫 Ryan Dahl 小伙子正在为一件事焦头烂额，它需要在服务器端手写一个高性能的web服务，该服务对于性能要求之高，以至于目前市面上已有的web服务产品都满足不了需求。经过分析，它确定，如果要实现高性能，那么必须要尽可能的减少线程，而要减少线程，避免不了要实用异步的处理方案。

一开始，他打算自己实用C/C++语言来编写，但是使用C/C++来解决异步处理,处理起来十分复杂，这一过程实在太痛苦,就在他一筹莫展的时候，谷歌 V8 引擎的发布引起了他的注意，他突然发现，JS不就是最好的实现web服务的语言吗？它天生就是单线程，并且是基于异步的！有了V8引擎的支撑，它的执行速度完全可以撑起一个服务器。而且V8是鼎鼎大名的谷歌公司发布的，谷歌一定会不断的优化V8，有这种又省钱又省力的好事，我干嘛还要自己去写呢？

于是，Ryan Dahl基于开源的V8引擎，对源代码作了一些修改，便快速的完成了该项目。

2009年，Ryan推出了该web服务项目，命名为nodejs。

（node.js 是基于v8引擎的，里面能运行JavaScript代码）

从此，JS第一次堂堂正正的入主后端，不再是必须附属于浏览器的“玩具”语言了。

也是从此刻开始，人们认识到，JS（ES）是一门真正的语言，它依附于运行环境（运行时）（宿主程序）而执行

nodejs的诞生，便把JS中的最后一个问题放到了台前，即全局变量污染和依赖混乱问题

要知道，nodejs是服务器端，如果不解决这个问题，分模块开发就无从实现，而模块化开发是所有后端程序必不可少的内容

经过社区的激烈讨论，最终，形成了一个模块化方案，即鼎鼎大名的CommonJS，该方案，彻底解决了全局变量污染和依赖混乱的问题（CommonJS：JavaScript模块化方案）

该方案一出，立即被nodejs支持，于是，nodejs成为了第一个为JS语言实现模块化的平台，为前端接下来的迅猛发展奠定了实践基础

第三阶段发生的大事件：

• 2008年，V8发布

• IE的市场逐步被 firefox 和 chrome 蚕食，现已无力回天

• 2009年，nodejs发布，并附带commonjs模块化标准

第四阶段:  AMD、CMD 、ES6模块化诞生，实现浏览器中的模块化规范

CommonJS的出现打开了前端开发者的思路

既然后端可以使用模块化的JS，作为JS语言的老东家浏览器为什么不行呢？

于是，开始有人想办法把CommonJS运用到浏览器中

可是这里面存在诸多的困难（课程中详解）

办法总比困难多，有些开发者就想，既然CommonJS运用到浏览器困难，我们干嘛不自己重新定一个模块化的标准出来，难道就一定要用CommonJS标准吗？

于是很快，AMD规范出炉，它解决的问题和CommonJS一样，但是可以更好的适应浏览器环境

相继的，CMD规范出炉，它对AMD规范进行了改进

这些行为，都受到了ECMA官方的密切关注......

2015年，ES6发布，它提出了官方的模块化解决方案 —— ES6 模块化

从此以后，模块化成为了JS本身特有的性质，这门语言终于有了和其他语言较量的资本，成为了可以编写大型应用的正式语言

于此同时，很多开发者、技术厂商早已预见到JS的无穷潜力，于是有了下面的故事

既然有了ES6模块化，JS也能编写大型应用，那么自然也需要像其他语言那样有解决复杂问题的开发框架

• Angular、React、Vue等前端开发框架出现

• Express、Koa等后端开发框架出现

• 各种后端数据库驱动出现

要开发大型应用，自然少不了各种实用的第三方库的支持

• npm包管理器出现，使用第三方库变得极其方便

• 因为第三方库用的多了，webpack等构建工具出现，专门用于打包和部署，压缩代码，减小体积

既然JS可以放到服务器环境，为什么不能放到其他终端环境呢？

• Electron发布，可以使用JS语言开发桌面应用程序

• RN和Vuex等技术发布，可以使用JS语言编写移动端应用程序

• 各种小程序出现，可以使用JS编写依附于其他应用的小程序

• 目前还有很多厂商致力于将JS应用到各种其他的终端设备，最终形成大前端生态

模块化主要要解决的两个问题

1. 全局变量污染  全局变量污染分两种情况

   首先知道var 定义的变量会变成全局对象的属性，在当前所有的js文件中都可以使用var定义的变量

   多个程序员合作开发的项目中定义的变量名是一样的，那么会导致后面定义的变量会覆盖前面定义的变量，从而导致程序出现问题

2. 依赖关系混乱等问题

   前期在没有模块化的时候，js文件十分庞大，于是就按功能抽离划分为多个js文件。

   但是在html页面通过script的方式加载大量js文件会出项许多问题，例如文件之间的相互依赖问题

   最终模块依赖于下面的这些模块，当然这里只是几个模块，成百个模块，那么模块(文件）的依赖关系会很复杂

   模块规范中的导入和导出，会让模块的依赖关系处理起来很简单

这么多前端化规范都要学习吗？

commonjs模块化解决方案，commonjs应用在node.js中，以后会学习webpac打包工具 和学习node.js的时候 commonj是需要用到的（必学）

ES6模块化：浏览器端实现模块化 （必学）

ADM CMD 现在基本已经退出了，不再使用了，但是可以去了解，这样你就知道在ES6模块化出现之前是怎么实现模块化的   

可以看到，模块化的出现，是JavaScript通向大型应用的基石，学习好模块化，变具备了编写大型应用的基本功