前端印记 DFE_evernote

前端模块化

  • CommonJs 与 node
  • 浏览器模块化：AMD、CMD
  • ES6模块化

JavaScript模块化的发展历史：

目录：

• 第一阶段
• 第二阶段
• 第三阶段
• 第四阶段

第一阶段

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

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

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

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

第一阶段发生的大事件：

1. 1996年，NetScape将JavaScript语言提交给欧洲的一个标准制定组织ECMA（欧洲计算机制造商协会）
2. 1998年，NetScape在与微软浏览器IE的竞争中失利，宣布破产

第二阶段

ajax的出现，逐渐改变了 JavaScript 在浏览器中扮演的角色。现在，它不仅可以实现小的效果，还可以和服务器之间进行交互，以更好的体验来改变数据

JS代码的数量开始逐渐增长，从最初的几百行，到后来的几万行，前端程序逐渐变得复杂

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

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

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

  1. 浏览器解释执行JS的速度太慢
  2. 用户端的电脑配置不足
  3. 更多的代码带来了全局变量污染、依赖关系混乱等问题

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

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

第二阶段的大事件：

1. IE浏览器制霸市场后，几乎不再更新
2. ES4.0流产，导致JS语言10年间几乎毫无变化
3. 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语言实现模块化的平台，为前端接下来的迅猛发展奠定了实践基础

该阶段发生的大事件：

1. 2008年，V8发布
2. IE的市场逐步被 firefox 和 chrome 蚕食，现已无力回天
3. 2009年，nodejs发布，并附带commonjs模块化标准

第四阶段

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

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

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

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

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

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

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

这些行为，都受到了ECMA官方的密切关注 2015年，ES6发布，它提出了官方的模块化解决方案 —— ES6 模块化

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

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

JS无穷潜力

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

    • Angular、React、Vue等前端开发框架出现
    • Express、Koa等后端开发框架出现
    • 各种后端数据库驱动出现

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

    • npm包管理器出现，使用第三方库变得极其方便
    • webpack等构建工具出现，专门用于打包和部署

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

    • Electron发布，可以使用JS语言开发桌面应用程序
    • RN和Vuex等技术发布，可以使用JS语言编写移动端应用程序
    • 各种小程序出现，可以使用JS编写依附于其他应用的小程序
    • 目前还有很多厂商致力于将JS应用到各种其他的终端设备，最终形成大前端生态

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

← 包管理器 →