JavaScript 模块化发展史
[toc]
第一阶段
在 JavaScript 语言刚刚诞生的时候，它仅仅用于实现页面中的一些小效果
那个时候，一个页面所用到的 JS 可能只有区区几百行的代码
在这种情况下，语言本身所存在的一些缺陷往往被大家有意的忽略，因为程序的规模实在太小，只要开发人员小心谨慎，往往不会造成什么问题
在这个阶段，也不存在专业的前端工程师，由于前端要做的事情实在太少，因此这一部分工作往往由后端工程师顺带完成
第一阶段发生的大事件：
- 1996 年，NetScape 将 JavaScript 语言提交给欧洲的一个标准制定阻止 ECMA（欧洲计算机制造商协会）
- 1998 年，NetScape 在与微软浏览器 IE 的竞争中失利，宣布破产
第二阶段
ajax 的出现，逐渐改变了 JavaScript 在浏览器中扮演的角色。现在，它不仅可以实现小的效果，还可以和服务器之间进行交互，以更好的体验来改变数据
JS 代码的数量开始逐渐增长，从最初的几百行，到后来的几万行，前端程序逐渐变得复杂
后端开发者压力逐渐增加，致使一些公司开始招募专业的前端开发者
但此时，前端开发者的待遇远不及后端开发者，因为前端开发者承担的开发任务相对于后端开发来说，还是比较简单的，通过短短一个月的时间集训，就可以成为满足前端开发的需要
究其根本原因，是因为前端开发还有几个大的问题没有解决，这些问题都严重的制约了前端程序的规模进一步扩大：
- 浏览器解释执行 JS 的速度太慢
- 用户端的电脑配置不足
- 更多的代码带来了全局变量污染、依赖关系混乱等问题
上面三个问题，就像是阿喀琉斯之踵，成为前端开发挥之不去的阴影和原罪。
在这个阶段，前端开发处在一个非常尴尬的境地，它在传统的开发模式和前后端分离之间无助的徘徊
第二阶段的大事件：
- IE 浏览器制霸市场后，几乎不再更新
- ES4.0 流产，导致 JS 语言 10 年间几乎毫无变化
- 2008 年 ES5 发布，仅解决了一些 JS API 不足的糟糕局面
第三阶段
时间继续向前推移，到了 2008 年，谷歌的 V8 引擎发布，将 JS 的执行速度推上了一个新的台阶，甚至可以和后端语言媲美。
摩尔定律持续发酵，个人电脑的配置开始飞跃
突然间，制约前端发展的两大问题得以解决，此时，只剩下最后一个问题还在负隅顽抗，即全局变量污染和依赖混乱的问题，解决了它，前端便可以突破一切障碍，未来无可限量。
于是，全世界的前端开发者在社区中激烈的讨论，想要为这个问题寻求解决之道......
2008 年，有一个名叫 Ryan Dahl 小伙子正在为一件事焦头烂额，它需要在服务器端手写一个高性能的 web 服务，该服务对于性能要求之高，以至于目前市面上已有的 web 服务产品都满足不了需求。
经过分析，它确定，如果要实现高性能，那么必须要尽可能的减少线程，而要减少线程，避免不了要实用异步的处理方案。
一开始，他打算自己实用 C/C++语言来编写，可是这一过程实在太痛苦。
就在他一筹莫展的时候，谷歌 V8 引擎的发布引起了他的注意，他突然发现，JS 不就是最好的实现 web 服务的语言吗？它天生就是单线程，并且是基于异步的！有了 V8 引擎的支撑，它的执行速度完全可以撑起一个服务器。而且 V8 是鼎鼎大名的谷歌公司发布的，谷歌一定会不断的优化 V8，有这种又省钱又省力的好事，我干嘛还要自己去写呢？
于是，它基于开源的 V8 引擎，对源代码作了一些修改，便快速的完成了该项目。
2009 年，Ryan 推出了该 web 服务项目，命名为 nodejs。
从此，JS 第一次堂堂正正的入主后端，不再是必须附属于浏览器的“玩具”语言了。
也是从此刻开始，人们认识到，JS（ES）是一门真正的语言，它依附于运行环境（运行时）（宿主程序）而执行
nodejs 的诞生，便把 JS 中的最后一个问题放到了台前，即全局变量污染和依赖混乱问题
要直到，nodejs 是服务器端，如果不解决这个问题，分模块开发就无从实现，而模块化开发是所有后端程序必不可少的内容
经过社区的激烈讨论，最终，形成了一个模块化方案，即鼎鼎大名的 CommonJS，该方案，彻底解决了全局变量污染和依赖混乱的问题
该方案一出，立即被 nodejs 支持，于是，nodejs 成为了第一个为 JS 语言实现模块化的平台，为前端接下来的迅猛发展奠定了实践基础
该阶段发生的大事件：
- 2008 年，V8 发布
- IE 的市场逐步被 firefox 和 chrome 蚕食，现已无力回天
- 2009 年，nodejs 发布，并附带 commonjs 模块化标准
第四阶段
CommonJS 的出现打开了前端开发者的思路
既然后端可以使用模块化的 JS，作为 JS 语言的老东家浏览器为什么不行呢？
于是，开始有人想办法把 CommonJS 运用到浏览器中
可是这里面存在诸多的困难（课程中详解）
办法总比困难多，有些开发者就想，既然 CommonJS 运用到浏览器困难，我们干嘛不自己重新定一个模块化的标准出来，难道就一定要用 CommonJS 标准吗？
于是很快，AMD 规范出炉，它解决的问题和 CommonJS 一样，但是可以更好的适应浏览器环境
相继的，CMD 规范出炉，它对 AMD 规范进行了改进
这些行为，都受到了 ECMA 官方的密切关注......
2015 年，ES6 发布，它提出了官方的模块化解决方案 —— ES6 模块化
从此以后，模块化成为了 JS 本身特有的性质，这门语言终于有了和其他语言较量的资本，成为了可以编写大型应用的正式语言
于此同时，很多开发者、技术厂商早已预见到 JS 的无穷潜力，于是有了下面的故事
- 既然 JS 也能编写大型应用，那么自然也需要像其他语言那样有解决复杂问题的开发框架
- Angular、React、Vue 等前端开发框架出现
- Express、Koa 等后端开发框架出现
- 各种后端数据库驱动出现
- 要开发大型应用，自然少不了各种实用的第三方库的支持
- npm 包管理器出现，实用第三方库变得极其方便
- webpack 等构建工具出现，专门用于打包和部署
- 既然 JS 可以放到服务器环境，为什么不能放到其他终端环境呢？
- Electron 发布，可以使用 JS 语言开发桌面应用程序
- RN 和 Vuex 等技术发布，可以使用 JS 语言编写移动端应用程序
- 各种小程序出现，可以使用 JS 编写依附于其他应用的小程序
- 目前还有很多厂商致力于将 JS 应用到各种其他的终端设备，最终形成大前端生态
可以看到，模块化的出现，是 JS 通向大型应用的基石，学习好模块化，变具备了编写大型应用的基本功。