共计 12528 个字符，预计需要花费 32 分钟才能阅读完成。
本文原文由作者“司徒正美”发布于公众号“前端你别闹”，即时通讯网收录时有改动，感谢原作者的分享。
1、引言
1990 年，第一个 Web 浏览器的诞生；1991 年，WWW 诞生，这标志着前端技术的开始。
在这将近 20 年的前端发展史中，我们经历了从最早的纯静态页面，到 JavaScript 跨时代的诞生；从 PC 端到移动端；从依赖后端到前端可自由打包开发；从早期的网景 Navigator 浏览器到现在各家浏览器百花齐放……
我们经历了前端的洪荒时代、Prototype 时代、jQuery 时代、后 jQuery 时期、三大框架割据时代，这其中均是由国外开发者主导，直到如今的小程序时代，才是中国开发者独创的。
这是漫长的技术储备下的成果，最终促成了良好的技术成长收获。期间的前端发展之路，崎岖艰难。
（本文同步发布于：http://www.52im.net/thread-27…）
2、相关文章
《小程序技术始于微信？来看看移动端小程序技术的前世今生！》
《盘点主流移动端跨平台 UI 技术：实现原理、技术优劣、横向对比等》
《最火移动端跨平台方案盘点：React Native、weex、Flutter》
《快速了解 Electron：新一代基于 Web 的跨平台桌面技术》
3、洪荒时代（1990~1994 年）
在 1990~1994 年期间，前端界发生的大事有：WWW（World Wide Web）的诞生、浏览器的诞生、JavaScript 的诞生，没有专业的前端，页面全是由后端开发的。
1990 年，万维网之父蒂姆·伯纳斯 - 李（Tim Berners-Lee）在 NeXT 电脑上发明了第一个 Web 浏览器。
▲ 互联网之父——伯纳斯·李（Tim Berners-Lee）
1991 年 8 月 6 日，Tim 在 alt.hypertext 新闻组贴出了一份关于 World Wide Web 的简单摘要，这标志了 Web 页面在 Internet 上的首次登场。
1990 年 12 月 25 日，罗伯特·卡里奥在 CERN（即位于日内瓦的欧洲原子核研究会）和蒂姆·伯纳斯·李一起成功通过 Internet 实现了 HTTP 代理与服务器的第一次通讯（有关 HTTP 的详细介绍，请见《网络编程懒人入门 (六)：深入浅出，全面理解 HTTP 协议》）。蒂姆·伯纳斯·李(Tim Berners-Lee) 爵士作为万维网 (World Wide Web，简称 WWW 或互联网) 的发明者，被尊称为互联网之父。蒂姆·伯纳斯·李建立的第一个网站 (也是世界上第一个网站) 是 http://info. cern. ch/，它于 1991 年 8 月 6 日上网(即北京时间 8 月 7 日)。
最早的 Web 主要被一帮科学家们用来共享和传递信息，全世界的 Web 服务器也就几十台。由于仅是用来传递信息，从可视化方式或从传递数量上看，仅比电报强一点点。
当时还没有 JavaScript，用的是纯静态的页面。
1993 年，CGI（Common Gateway Interface）出现了，人们可以在后端动态生成页面。
Perl 由于跨操作系统和易于修改的特性成为 CGI 的主要编写语言。当然，CGI 也支持其他支持标准输入输出和环境变量的语言编写，比如 Shell 脚本、C/C++ 语言，只要符合接口标准即可。
但显然，页面的内容更新完全由后端生成，这带来一个明显的缺憾：每次更新都要整页刷新，加上早期的网速情况，这个操作是非常慢的。因此针对这情况，人们从多方面着手改进：编写语言的升级、浏览器的升级、HTML 的升级。
1994 年，网景公司成立，发布了第一款商业浏览器 Navigator。自从这款浏览器面世后，微软推出 IE 浏览器。虽说有竞争才有发展，但这也埋下了 JavaScript 分裂的种子。
▲ 1994 年，网景浏览器的截图
同年，PHP 诞生。PHP 能将动态的内容嵌入到 HTML 中，提升了编写页面的效率与可读性，其性能也比一般的 CGI 高。PHP 的界定符、循环语句等的发明，深刻影响了后来的 ASP、JSP，乃致后来的 JavaScript 前端模板引擎。
1994 年 10 月，W3C 小组也成立了，他们负责 HTML 的发展路径，其宗旨是通过促进通用协议的发展。
待这一切就绪后，JavaScript 于 1995 年诞生了。
传闻，网景工程师布兰登·艾克（Brendan Eich）只花了 10 天时间设计出 JavaScript 语言，近乎上帝七日创造世界那么高效。但也因为工期太短的缘故，导致许多瑕疵，因此一直被正统程序员所嫌弃，直到 Ajax 的出世，才让人们找到理由忍受它的畸形。早期的浏览器都配有一个选项，用来禁止 JavaScript 语言运行。
兰登·艾克（Brendan Eich）:
艾奇不仅是 Mozilla 的联合创始人，还是 JavaScript 技术的创始人。自 1998 年起，他开始深度参与 Mozilla 各方面的发展工作，包括 Firefox 浏览器和 Thunderbird 的研发。2005 年，艾奇被任命为 Mozilla 公司的首席技术官。
JavaScript 主要语言特征：
1）借鉴 C 语言的基本语法；
2）借鉴 Java 语言的数据类型和内存管理；
3）借鉴 Scheme 语言，将函数提升到 ” 第一等公民 ”（first-class citizen）的地位；
4）借鉴 Self 语言，使用基于原型（Prototype）的继承机制。
时下，静态语言大行其道，类与接口被证明是构建大工程的最佳实践，人们想不出没有类的语言如何编写业务。因此当时的微软也打造了另一门运行于浏览器的语言——VBScript。
如果继续细探 JavaScript 的能力，你会发现它早期真的非常空洞，一门没有灵魂的语言，没有包管理机制，也没有像 Java 与 C ++ 那样的打辅助用的 SDK，内置的方法也屈指可数。比如说数组方法，早期只有 push、pop、shift、unshift、splice、slice、sort、reverse、concat、join 等操作。动态调用方面，Function 的 apply、call 操作还没有出现！
早年的偷懒，导致后来不得不补课：到了 2019 年，数组上的原型方法，是原来 3 倍。
除了方法缺乏，还有性能问题，大家讨论用 eval 还是 Function，用哪种循环方式，用 parseInit 还是~~，就是为了那一点点的性能提升。例如 jsperf.com，就是一个专门研究 JavaScript 性能的网站。
因此 JavaScript 诞生后，其两大任务就是完善语言特性与提高性能。这两座大山分别由著名的 prototype.js 与 jQuery 来搬掉。
在搬掉之前，前端界还有一个曲折实践——第一次浏览器战争，并由其发展而来 UA 嗅深技术。
4、浏览器战争（1994~2005 年）
浏览器战争一共打了三场，IE 浏览器 vs 网景浏览器、IE 浏览 vs 火狐浏览器、IE 浏览器 vs 谷歌浏览器。
第一场浏览器之战打得尤其激烈。
微软的 IE 浏览器发布于 1994 年，但此时的网景已经占领绝对优势。微软在落后的情况，反编译 Netscape 的源码，推出 IE 与 JScript。但是由于 Bug 非常多，大家不愿意为 IE 开发网站，因此发掘出 UA，专门过滤掉 IE 浏览器。
UA 即 Navigator.userAgent，是用一个字符串来记录用户当前运行在什么操作系统与浏览器中。
当时 IE3 的 UA 是这样的：
Mozilla/2.0 (compatible; MSIE 3.02; Windows 95)
程序判断 UA 信息，假如发现当前运行的环境是 IE 浏览器的话，就提示用户用网景浏览器打开。因此微软不得不让自己的 UA 尽量伪装成网景的 UA，欺骗用于检测 UA 的脚本，达到 IE 浏览器可以跑这些网站的目的。
最终，第一次浏览器之战以微软胜利，Netscape 被美国在线收购，而落下帷幕。
第一次浏览器战争年代非常久远了，但其结局告诉我们，其实技术强弱并不重要。那时技术保护并没有这么重视，否则微软的行为可能会被告（谷歌的 openSDK 仅抄袭几十行代码，被 Oracle 公司诉讼赔 88 亿）。
第一次浏览器战争带来了一个问题：尽管当时有 ECMA-262（JavaScript 规范文档）与 W3C（HTML 与 CSS 的规范文档），微软却没有照规范来实现 JavaScript、HTML 与 CSS，导致前端兼容问题的诞生。所以 CSS Hack、浏览器判定、特性侦测，这些技术就应运而生。
这个时代最著名的人物是 Dean Edwrad，他是最早的近乎完美解决事件绑定的兼容性大神，其 addEvent()内置于 jQuery 最早的版本中。jQuery 的作者 John Resig 看到其超强的技艺，最后放弃推出大而全的框架，专攻选择器引擎。
John Resig：
John Resig 是 jQuery 的创始人和技术领袖，目前在 Mozilla 担任 JavaScript 工具开发工程师。著有《Pro JavaScript Techniques》（即《精通 JavaScript》）等经典 JavaScript 书籍。
Dean Edwrad 的 IE7.js、IE8.js 是早期处理浏览器兼容的良药，可以说是一切 Polyfill 的起源。他写了大量的 Hack，比如在 IE 如何测量元素的宽高，许多操作 DOM 的兼容。
这时期太早，中国基本没有参与这次浏览器战争。
5、Prototype 时期（2005~2009 年）
Prototype 是 Sam Stephenson 写的一个非常优雅的 JavaScript 基础类库。他是 Ruby 的大牛，因此 Prototype 的许多方法名都是来自 Ruby 界。
Sam Stephenson 最大的贡献是发掘了 Prototype 与创造了 Function.prototype.bind，在数组上也写了一大堆方法，其中许多被标准化了。
同期的 MooTools 也是 Prototype 挂方法，当时，大家还在前端论坛为这个争吵。还有前端工程师喜欢在当时很出名的前端聚集地——蓝色理想（现沦为设计师网站）上，讨论如何扒脚本、分享弹层、日历等小组件的技术，这在当时已经是非常了不起的事。
Prototype 当时还解决两大问题：动画特效与 Ajax 请求。动画特效是由 Scriptaculous 提供，我们现在所熟知的各种缓动函数，各种特效的命名与大致的运行形态，都是由 Scriptaculous 确定下来的。
在早期，谷歌就开始使用 iframe 实现页面刷新。
2005 年 2 月，杰西·詹姆士·贾瑞特（Jesse James Garrett）发表了一篇名为《Ajax：一种 Web 应用程序开发的新方法》的文章后，Ajax 被挖掘出，大家才开始重视起这技术的应用。
杰西·詹姆士·贾瑞特（Jesse James Garrett）：
杰西·詹姆士·贾瑞特是一名用户体验设计领域的设计师、网页体验设计公司 Adaptive Path 的创办人，是 AJAX 技术术语的命名者。
例如 IE 下的 ActiveXObject(“Microsoft.XMLHTTP”)，这是 IE 创建 Ajax 引擎的。假如当时有工程师开发出一个核心库，如果不包含 Ajax 的封装，便不好意思发布出来。
▲ 一些 Ajax 书藉
当时前端开发模式是选择一个核心库，找一些组件，或者扒别人的脚本进行开发。
Prototype 的源码挺好理解的，代码量也少，只有 5000 多行，里面的每个方法也很易扒出来，因此一些大公司总有高手能创造自己的 Prototype。
但前端开发还是离不开后端，因为前端没有模块机制，当时我们需要用 PHP 进行打包。
打包是雅虎 34 条军规之一，可以减少请求数。打包的同时也可以进行混淆，防止代码小偷来窥探。
N 年前，前端面试必问的题目：
▲ 模块化的雏型，在注释中标注它的依赖
这个时期，还没有前后端分离，可国内一些带着深厚后端背景的高手已经入场。
6、jQuery 时期（2009~2012 年）
2006 年，jQuery 发布，它当时的竞争对手很多：Dojo、Prototype、ExtJS、MooTools。
所以那时 jQuery 的宣传口号仅能说是它的性能上升了 100%、200%、300%。直到 2009 年，Sizzle 选择器引擎研发成功，jQuery 才取得压倒性的优势。
当时前端界首要面对的是浏览器兼容性问题，jQuery 在处理 DOM 兼容上真是知微见著, 发掘出大量的 DOM/BOM 兼容方案（例如 Dean Edwrad 的 addEvent()，IE 的 px 转换方案，domReady 的 doScroll 方案，globalEval 的兼容方案等）
jQuery 也打破了前端开发者的编程思维，之前是按照后端的开发思路来的：做一个业务就先封装一个类，有了这个类后，再想办法传入一个 DOM，然后再通过类方法操作 DOM。而 jQuery 是 DOM 为中心，开发者可以选一个或多个 DOM，变成 jQuery 对象，然后进行链式操作。当时为了改变用户的思维，国内的高手写了不少文章来引导大家。
其次，开发者们已开始注重前后端分离，并要求不能污染 Object 原型对象，不能污染 window 全局变量。这样，jQuery 只占用两个全局变量。
再次，jQuery 非常轻量级，采用 Dean Edwards 编写的 Packer 压缩后，大小不到 30KB。并且里面实现得非常精妙，以令人瞠目的手段解决各种兼容痼疾。
为了学习这些技巧，高手们翻了一遍遍 jQuery 的源码，所以网上有大量关于其源码详解的书藉。甚至前端工程师在面试时也会被考到 jQuery 的源码实现，这样，jQuery 在国内更加流行。
jQuery 的流行间接带来以下的发展：
1）促使人们对 CSS1~CSS3 选择器的学习；
2）促进了浏览器原生选择器引擎 document.querySelectorAll、Element.matches 的诞生；
3）提高人们对 domReady（DOMContentLoaded 事件）的认识；
4）促进了 Promise 与 requestAnimateFrame 的诞生；
5）最重要的是降低前端门槛，让更多人进入这行业，前端工程师的队伍越来越壮大。
这样的话，不断涌现出优秀的工程师，他们创造了大量 jQuery 插件与 UI 库。为后 jQuery 时代，人们研发前端模块加载、统一异步机制、打造大型 MVC 框架，甚至伸向后端，接管打包脚本而发明 Node.js，来腾出大量时间。
这个时期涌现了大量 jQuery-like 的库，其中最著名的是 Zepto.js。Zepto 的出现也标志着我们进入移动互联网时代。那时配套出的著名库还有 iScroll、fastclick、Lazy Load、Modernizr、fullPage。
jQuery 的链式操作风靡一时，也带来许多问题，当 Ajax 出现依赖时，就不可避免就出现回调地狱。因此针对这方面的讨论，诞生 Deffered 与 Promise。有关回调地狱的讨论，在后来讲 Node.js 异步处理时，将会再一次热烈地讨论。因此太阳下没有新事，我们总是遇到相似的问题。
jQuery 如此多的选择器也法维护，随着越来越多人涌现这行业，页面的交互也越来越复杂，从 Web Page 向 Web App 进化，新的趋势带来新的开发方式。
7、后 jQuery 时期（2012~2016 年）
这时期以 RequireJS 的诞生为起点，以 RN 的出现结束。同时解决了前端的模块定义问题，模块打包问题（通过 Node.js），JavaScript 不依靠其他语言创造了一套自己的工具链。
jQuery 的出现让前端工程师开发更加轻松，假如工程师想实现一个功能，现搜索出一个 jQuery 插件来实现。那时候大家在前端网站就整天介绍 jQuery 插件，很少讨论一些底层的实现。
前端工程师通常编写一个页面，会引入十多个乃至几十个 jQuery 插件，页面上塞满了 Script 标签。众所周知，浏览器是单线程，Script 的加载，会影响到页面的解析与呈现，导致著名的白屏问题（当时前端用力过猛，body 中的所有东西都是动态生成的）。
jQuery 另一个问题是全局污染，由于插件的质量问题，或者开发的素质问题，这已经是 IIEF 模块或命名空间等传统手段无法解决了。
于是一些优秀的前端工程师们决定向后端取经，引入模块机制。早期，这种模块机制在 Dojo、EXT 这些框架中都是内置的，但是显然说服不了另一个框架的用户用对方的模块机制，于是有人立志要统一这种模块定义方式，成立了 CommonJS。
但不料，CommonJS 内部也有派系，谁也说不服对方。终于有一个人忍不住自己独立开发出 RequireJS，其模块规范即为 AMD。AMD 最大的优势是它支持各种插件，且简单明了，并且提供 shim 机制加载以非 AMD 规范编写的 JavaScript 代码。
但在 CommonJS 诞生很久一段时间后，在后端的 Node.js 出现时才有用武之地。而国内，则流行另一种规范风格，背靠阿里的大旗，有人推出了 SeaJS，号称其规范为 CMD。其实无论国内还是国外，都产生许多模块加载器，但最后还是被淘汰了，规范一个就够了，不宜过多。
但是前端工程师的创造力就是这么惊人，从无到有，再到泛滥成灾，一年足矣。这可能与前端代码是开源的原因。最后有人统一了前两种规范（AMD、Node.js 模块），同时还支持老式的“全局”变量规范。
自此，JavaScript 开发模式焕然一身了，大家只要在代码外面包一层就可以全世界通用，不用担心全局污染的问题。
其次，jQuery 开发者需要解决大段 HTML 的生成问题，之前 jQuery 有 $.html, $.append, $before 等方法，可以将一大段符合 HTML 结构的字符串转换成 DOM 再插入到页面上。
但现在我们想分离出来，让 HTML 独立到不同的文件中，然后插数据，这就是前端模板。前端模板的情况与模板规范一样，从没有到多如芝麻的境地。这时筛选一个好用且性能高的模板是一件让前端工程师头疼的问题，那时网上有许多评测文章来介绍它们。
前端模板技术可以用一个公式来描述：
HTML = template(vars)
有了前端模板后，又诞生了前端路由，基于它们，人们发明一个新词汇 SPA。作为这个时代的尾声，来自 Ruby 界的高手 Ryan Dahl 发明了 Node.js。前端工程师们欢呼：可以不用传统的后端就能自己写一个网站了！
▲ Node 之父 Ryan Dahl
Node.js 的发展就不详述上，很快它就冒出海量模块、路由、状态管理、数据库、MVC 框架都有了。这时，前端就缺自己的 MVC 框架了。Node.js 转眼就十岁生日了。
著名的 MEAN 架构，是 JavaScript 全栈开发的先锋。当时涌现了大量的 MVC 与 MVVM 框架。最先火起来的是 Backbone.js，使用纯正的 MVC 模型，Backbone.js 是 jQuery 最后的支持者，它强依赖于 jQuery。
Backbone.js 的作者还搞了另一套编译语言 CoffeeScript, 里面的箭头函数、类机制、解构赋值等语法糖都深深影响了后来的 ES6。
接着下来是谷歌的 Angular，微软的 Knockout.js，苹果的 Ember.js 这三个 MVVM 框架，MVVM 就是比 MVC 多一个数据绑定功能，但这数据绑定功能是非常难实现。Knockout 是使用函数代替属性的技巧实现，它的设计影响到后来的 Mobx；Ember.js 是基于 Object.defineProperty；Angular 是将函数体转译成 setter()、getter()函数。
大公司的介入，对个人开发者影响是很大，毕竟大家都爱迷信大公司，因此局面一下子就稳定下来。大公司还带来了全新的开发模式，早期都是找一个核心库，再搜刮一大堆插件，然后自己写业务代码，最后后端打包。
大公司将后端开发经验挪用过来，用 Node.js 开发了一套 CLI，里面包含了脚手架生成，打包脚本、语法风格检测、环境变量插入，代码复杂度检测，代码提交时自动跑单元测试，图片与 JS 压缩等功能。ESLint、JSLint、JSHint、CSS Lint、htmllint 等就是那时期出现的。
但 CLI 的出现导致了前端的分裂，以前大家都使用 jQuery，但自 CLI 帮你建好项目的那一刻起，就将你划归某一子阵营，你是 Angular？Ember.js？还是 jQuery？对了，jQuery 没有大公司支撑的阵营被快速边缘化。
对于个人开发者，他们是没有能力开发这么功能完备的 CLI，于是出现了 Code Climate、Travis CI、CircleCI 这样的平台。它们的出现标志着 jQuery 小作坊时代的终结了。
▲ CircleCI 官网
前端开发者也出现分化：有些人转向后端，出现了 CNode 的门户网站。另外一些人开始搞工程化。一时间出现上百种构建工具，出名的有 Grunt、Gulp、FIS3、webpack、Rollup、npm-script。
你方唱罢我登场，这些构建工具均会经历时代的考验，如大浪淘沙般，最后存活得仅为寥寥。
因此在这场工程化的盛宴中，注定把许多低层次的 jQueryer 淘汰掉。jQueryer 在空闲之余培育出的前端模板、前端路由、MVC 框架、模块加载器、Node.js 构建工具，却不料最终成为它自己的挖墓人。
jQuery 的时代一去不返了，再没有人关心拖了 N 年的 Bootstrap 4 终于发布了，没有人知道 jQuery3.5 的瘦身计划，也没有人问 jQuery 的源码，渐渐地，大家不关注 jQuery 的工具链了。
8、三大框架割据时代（2016~ 至今）
React 是突然爆发的，虽然它是与 Angular 是同时期发布，但因为 JSX 怪异的语法让人们远离它。此时已经进入移动互联网的中期，大公司都有自己的 App，或者基于原生，或者基于 Hybird（详见：《盘点主流移动端跨平台 UI 技术：实现原理、技术优劣、横向对比等》、《最火移动端跨平台方案盘点：React Native、weex、Flutter》）。
Hybird 是用 WebView 加载一个网站或一个 SPA。
由于原生成本太贵，需要招两套班子，一套安卓的，一套 iOS 的；而 Hybird 则一直存在性能问题。于是在 2017 年，Facebook 推出了 React Native（RN）。
RN 的性能不比原生差多少，比 Hybird 能好些，其次使用 JSX 开发界面比原生的快；RN 只需要低成本的前端开发人员就能上手了。中国国内经过瀑布流（图片导购）、团购、P2P、区块链等全新商业模式的开发浪潮后，前端人员数量大增。现在，他们只要稍微培训就可以转型为 App 开发。
在开发 RN 的过程中，人们开始了解 React 一系列的优胜之处。比如 JSX 背后的虚拟 DOM 技术，虽然事实证明虚拟 DOM 不会带来性能的巨大优势，但保证了你怎么写其性能不会太差。
React 为了引入 JSX，必须需要引入编译，这又间接促成 Babel 与 webpack 的壮大。尤其是 Babel，让我们在很旧的浏览器中使用非常新的语法，甚至一些还没有定案的语法。React 从 14 升级到 React 15，强制使用 class 语法，让这个推了好久的语法糖终于大规模落地。
之前如果 JavaScript 想使用类，只能自己模拟类，由于没有官方的实现，只能任由各优秀工程师发挥。而普通人想用好类，需要了解很复杂的 Prototype 机制。
现在只用几个新关键字就可以得到这一切。
如果对比 Python 2 与 Python 3 间的升级，JavaScript 实在太辛运了！针对 CSS 逻辑功能过弱的问题，我们也有了新的解决方案：Less、Sass、PostCSS 与 CSS Modules！
谷歌在发布 Angular 的同时，也发布了一个叫 Polymer 的框架，那时它想推广一种叫 Web Components 的浏览器自定义组件技术。这其实是微软在 IE5 就玩剩的 HTC 技术的升级版。虽然它没有火起来，但它将 Script、Style、Template 三种内容混在一个文件的设计，启发一个留美华人，再结合当时的 Backbone.js、Angular 等设计，Vue.js 横空出世。目前，这是国人最成功的前端框架了。
尤雨溪：
尤雨溪是 Vue.js 框架的作者，HTML5 版 Clear 的打造人。尤雨溪毕业于上海复旦附中，在美国完成大学学业，本科毕业于 Colgate University，后在 Parsons 设计学院获得 Design & Technology 艺术硕士学位，现任职于纽约 Google Creative Lab。
除此之外，国人也弄了好几套迷你 React 框架与迷你 Vue 框架。这有点像 jQuery 时代，大家疯狂做迷你 jQuery 框架一样。
总的来说，最有创造力的是 React 团队，做出状态管理器、CSS-in-JS、Flow 静态类型检查、devTool、Fetch、前后端同构、Fiber、suspend、并发渲染等名词层出不穷。其中，状态管理器拥有上百套，CSS-in-JS 也拥有上百套，Flow 则让前端尝鲜到接口编程的好处，间接推动 TypeScript 发展。这三大框架无法比拼个一二出来：Vue.js 有国人的拥趸，React 与 Angular 有大公司光环。
三大框架的缠斗从 PC 领域扩展到移动端：React 有 RN，Vue.js 有 Weex，Angular 有 ionic。想当年我们为了兼容浏览器，攒了一大堆浏览器侦探的 Hack，全部贬值为垃圾了。
在这时期，一种全新的后端渲染崛起，称之为前后同构，既拥有早期 SEO 的功效，又能复用大量的业务逻辑。随着国内移动互联网的发展，获客成本提高，各种有效的商业模式都进入红海，但只有头部用户能赚到钱，马太效应越来越严重，纯粹的技术解决方案已经无法满足商业诉求了。
9、小程序时代（2017~ 至今）
小程序时代与三大框架的时代几乎重合，但是出自不同一批人，决战的平台也不一样。
一直以来前端技术都是由国外开发者主导的，即便是 Vue.js 也是由美国的华人创造的。但是国内外的技术更新是存在代差，国内通常延期两三年，这个时间差可以让一些模仿者得以生存（如 SeaJS、FIS、avalon）。但随着封闭的时间越来越长，国内肯定也会诞生自己的专有物种。小程序就是其中之一。
小程序的出现有着明显的商业诉求，因为马太效应，一些超大流量的 App 诞生了。这些大流量 App 集成了许多功能，但显然公司再多员工，也无法所有功能全是自己弄，于是产生小程序这种“外包”的手段。
小程序是国内前端技术的一次厚积薄发：底层运行的迷你 React 的虚拟 DOM，内置组件是使用 Web Component，API 来源于 Hybird 的桥方法，打包使用 webpack，调试台是 Chrome console 的简化版，WXML、WXSS 的语法高亮也应该是 webpack 或 VS Code 的插件，模块机制是 Node.js 的 CommonJS……其中最值得一提的是微信开发者工具，以后开发者工具成了各种小程序 / 快应用的标配。
但微信小程序一开始的复用能力非常弱，没有类继承，不能使用 npm, 不支持 Less、Sass，因此基于它的转译框架就应运而生。第一代转译框架是 wept、WePY、mpvue，它们无一例外是 Vue 风格的。因为 WXML 的模板指令与 Vue 非常相似，只是改一下就能兼容。当时也出现了一个 MINA 的框架，听说是微信团队开发的，可以单独架起 Node.js 后端，让小程序运于浏览器中，方便做单元测试。
第一代转译框架主要是基于 Template 标签实现组件机制，自定义组件机制是以后的事了。这就造成了利用第一代转译框架编写的小程序项目很难升级。那时候是个人开发者的天堂，这些框架都是某一大牛独力开发的。
第二代转译框架是大公司主导的，因为需要兼容的小程序越来越多，百度、支付宝、字节跳动、小米、华为等公司都推出自己的小程序和快应用。个人开发者很难凭个人力量去开发转译框架，这时候各大团队纷纷推出自己的轮子：如京东的 Taro、滴滴的 Chameleon、网易的 Megalo、去哪儿网的 nanachi、百度的 Okam 等。
在这个时期，Angular 显然落伍了，一是 Angular 升级太快，国内的高手还没有消化好，新一版的 Angular 又发布了。二是国内缺乏迷你 Angular 的轮子，导致庞大的 Angular 无法塞进小程序中。
国外谷歌发布了 Flutter 跨平台转译框架，但是它的编写语言是 Dart，它也无法跨界到小程序中。
未来不仅国内一线巨头争夺小程序，二三线的巨头也可能会加入小程序的混战中，例如有人称 360 也在打造自己的小程序平台。小程序这种新的流量变现模式深刻地影响了国内的互联网布局。
10、结束语
当初 JavaScript 被误解为最糟糕的语言，时至今日它是最流行的语言：GitHub 60% 的开源项目都是与 JavaScript 有关。
以前，从事这行业的人被称为页面仔，现在他们的起薪有的比 PHP、JAVA、C++ 等后端还高。甚至有人说，“任何可以使用 JavaScript 来编写的应用，最终会由 JavaScript 编写。”
我们前端开发者触及的领域不仅仅是浏览器，还可以做后端，做桌面端，做手机端，做小程序端，前端开发者的性价比越来越高，越来越重要。可谓是时代造英雄。
笔者有幸成为前端开发者大队伍中的一员，也坚信我们前端开发者以后的路会越来越宽，越来越好走。
附录：有关 Web 即时通讯技术的文章
Web 即时通讯新手入门贴：
《新手入门贴：详解 Web 端即时通讯技术的原理》
Web 端即时通讯技术盘点请参见：
《Web 端即时通讯技术盘点：短轮询、Comet、Websocket、SSE》
关于 Ajax 短轮询：
找这方面的资料没什么意义，除非忽悠客户，否则请考虑其它 3 种方案即可。
有关 Comet 技术的详细介绍请参见：
《Comet 技术详解：基于 HTTP 长连接的 Web 端实时通信技术》
《WEB 端即时通讯：HTTP 长连接、长轮询（long polling）详解》
《WEB 端即时通讯：不用 WebSocket 也一样能搞定消息的即时性》
《开源 Comet 服务器 iComet：支持百万并发的 Web 端即时通讯方案》
更多 WebSocket 的详细介绍请参见：
《新手快速入门：WebSocket 简明教程》
《WebSocket 详解（一）：初步认识 WebSocket 技术》
《WebSocket 详解（二）：技术原理、代码演示和应用案例》
《WebSocket 详解（三）：深入 WebSocket 通信协议细节》
《WebSocket 详解（四）：刨根问底 HTTP 与 WebSocket 的关系(上篇)》
《WebSocket 详解（五）：刨根问底 HTTP 与 WebSocket 的关系(下篇)》
《WebSocket 详解（六）：刨根问底 WebSocket 与 Socket 的关系》
《理论联系实际：从零理解 WebSocket 的通信原理、协议格式、安全性》
《Socket.IO 介绍：支持 WebSocket、用于 WEB 端的即时通讯的框架》
《socket.io 和 websocket 之间是什么关系？有什么区别？》
有关 SSE 的详细介绍文章请参见：
《SSE 技术详解：一种全新的 HTML5 服务器推送事件技术》
更多 WEB 即时通讯文章请见：
http://www.52im.net/forum.php…
（本文同步发布于：http://www.52im.net/thread-27…）
