今年格外引人注目的框架是，类 React。Facebook 在 React.js Conf 2015 大会上推出了基于 JavaScript 的开源框架 React Native，它结合了 Web 应用和 Native 应用的优势，可以使用 JavaScript 来开发 iOS 和 Android 原生应用。在 JavaScript 中用 React 抽象操作系统原生的 UI 组件，代替 DOM 元素来渲染等。敲一次代码，能够运行在多个平台上，其优势可见一斑。除了 React ，还有手机淘宝推出的 Weex 框架，它吸收了 vue.js 的编程精华，编程风格更加简约。

在众多构建工具中，如今潇洒存活的并不多。体验完 grunt 和 browserify 后，gulp 顺势而至，尔后又出现了 webpack、jspm 等。而包管理工具，经历了 components、bower、spm 后，npm 开始主导整个市场。

Node.js 的应用已经铺天盖地，各大公司前端都把 Node.js 作为分离前后端的主要手段，并且在测试、监控等方面沉淀了大量内容。不过，这个市场是很苛刻的，Node.js 的性能难以达到 C/C++ 的水平，那么接下来要做的就是要提升性能，至少得接近 C/C++。

// @法海 师兄 批注：对时间点的总结是，其实很多技术方案很早就出现了，只不过没有大规模应用，因此，对于上文中时间点的谬误，你可以将语句从「xxx 出现了」改成「xxx 得到广泛应用」。其实我发现，问题在于，一个技术领域的新起和发展并不是一年内能完成的，一个技术方案的出现和广泛应用也不是一年内能落地的，所以执着于以「年」为时间点来编史，会画地为牢。

Web 规范和标准

最开始，我们看到的 JavaScript 还只是一个简单的脚本语言，配合着 AJAX，在网页上翻腾了好几个年头。随着互联网趋势越来越明显，互联网业务量和业务复杂度不断增加，很多网页变得相当复杂，如让我们震惊了好一会儿的 Gmail，交互复杂，体验优良。为了更好的多人协作，代码中的 Utils 库越来越大，在这些库中，基础部分更多的是对 JavaScript 语言本身的拓展，比如给 String 加一个 repeat 函数，再加一个 trim 函数，再加一个 endWith 函数等等。

复杂的业务中会经常看到一层又一层的回调处理，回调的嵌套让代码的可读性变的很差，而且很难将多个异步并行处理。为了改变这种编程范式，我们做了很多的思考，使用事件监听，使用各种手段拉直回调，平坦地调用。

慢慢的，如果你在关注 W3C 小组的动向，会发现，那些被认可的，并且被广泛重复定义的东西，都被纳入了标准。最开始的 jQuery/prototype，前者主要是对浏览器做兼容处理，让开发者不再把精力放到浏览器的差异上；后者是对语言本身的拓展，对 JavaScript 各种类型做拓展，并且提供了一套拓展任何对象的功能集。而现在的开发，我们很大程度上不再依托这些类库。规范和标准已经把这些差异都统一了，String 中自带了 includes/startsWith/endsWith/repeat/padStart/padEnd 等函数，Array 自带了 from/forEach/of/keys/values/find/findIndex 函数…

规范的标准是为了让开发者得到更好的编程体验，编程不是目标，目标是将编程生产力转化成实际效益，越少的阻碍对开发者越有利。各浏览器厂商当然也认识到了这一点，他们不断地提升自己产品的体验，将标准中的新特性都融合进去，比如 ES6 中的 Promise/Generator/Class/Module 等等。在这些内容普及之前，我们不需要加入 jQuery/prototype 这些「不纯粹」的东西，而是添加两个 shim 和 polyfill，如 es5-shim，html5shiv 等等。待到山花烂漫时，再轻松删掉这些补丁程序。

这两年工程化很热，W3C 小组也看到了，这就是市场的需求，为了完成一个大型应用的编程，就必须模块化、组件化，于是在规范中也出现了 Module & Module Loader；Node.js 的到来，让很多前端工程师开始接触数据库操作，面对巨量的异步，我们忍气吞声写了无数的回调地狱，尽管使用了很多 Promise 相关的操作，程序结构依然松散难以阅读，于是规范中也开始出现了 async/await 等对 Generator 的上层封装。文字已经不能满足当代人的沟通需求，音视频等富媒体传输走进了我们的生活，于是规范中也出来了 WebRTC/WebAudio 等规范。

只要规范出来了，后续市面上就会根据规范来实现一套 shiv，这些 shiv 提供了同样的 API，提供了同样的编程体验。当浏览器自我进化完成之后，这些 shiv 也将成为历史，被开发者遗弃在代码的注释之中。这些都是规范和标准的魅力，它的存在，就是让开发者把精力投入到自己的业务之中，编程和范式的工作交给它。

在 这里 可以看到，W3C 各个小组最近都在干啥。标准不能囊括一切。

生态的自我完善和自我拓展

技术的更迭过于频繁，我们能够清晰地看到，很多人还在用更迭前一波甚至是前好几波的产品。

当年的 IE6，在战场上鏖战了 10 多个年头，依然屹立不到，而现在它在市面上依然有百分之一左右的占有率，这种小强精神不得不让人肃然起敬。“只要用户在，我们就得追随”，这可能是很多公司的服务理念，因为用户就是潜在的利润。正是因为这种服务理念，成就了 IE6 一个又一个的 5 年！然而低版本的 IE 已经不仅仅是被前端从业人员抵制和排斥了，网络安全、网络运维、QA 等等，各个技术岗位的人员都开始对他不屑，它的存在对工作效率、对安全、对很多方面产生了极为不良的影响，甚至影响到一些核心内容的推广，所以 2016 将是低版本 IE 消亡的一年，我也呼吁业界所有的朋友举起义旗反抗起来！

庆幸的是，也有人开始吃螃蟹了。从支付宝到天猫到淘宝，阿里巴巴在很多业务上已经主（bèi）动（bī）地放弃了对 IE6 和 IE7 的支持，甚至在统一接入层直接做了 302 跳转，提示用户更新浏览器或者引导流量到无线端。这是一个好的开始，我们期望这也是业界达成共识的开始！

HTTP 协议，从 1.0 快速过度到了 1.1，整个互联网的上层建筑变的十分稳固。当然，我也了解到依然有很多产品还是保持了 1.0 的状态，据说电信公司的很多产品就是使用 HTTP/1.0 进行通讯，这无疑让人惊愕。为了追求更高的效率，减少网络传输中的无效流量，W3C 工作组对 HTTP 协议也做了重新的定义，SPDY 就是 13 年比较火热的一个话题，Firefox 和 Chrome 都陆续开始支持 SPDY，后来在 SPDY 的基础上做了升级，正式定义为 HTTP/2.0，它的一个很大特点就是多路复用，这个小小的特点改变了我们前端编程的很多优化模式，比如

当然，除了多路复用，还有很多其他的优化，比如传输的数据为二进制流，HEAD 头会被压缩处理，服务器可以向客户端推送内容等。在这个技术水平指数式增长的年代，我相信以后的革新不会比消灭 IE6 痛苦。