本文将带你客观了解2016前端领域的变化：从下至上、由低到高的维度盘点了过去一年中Web前端领域发生的重要事件；理智分析发展趋势，分析出影响2017前端领域的关键因素。同时，总结了业务类型变化给Web前端的工作所带来的明显差异，以及工程师整体技能方向的一些变化，切实给出前端工程师的个人技能提升方向。帮你在纷乱的前端江湖中，理清前端领域和自己发展的未来。
2016 年已经过去了，像过去六年中的每一年一样，Web前端领域又产生了“面目全非”而又“耳目一新”的变化，不但旧事物持续不断地被淘汰，新事物也难保坐久江山，大有岌岌可危之势。开源界如群雄逐鹿，不断生产新的概念、新的框架、新的工具，去年中一些流行的技术今年大多得到了进一步的演进和升级，活跃度非常高，却仍然不能保证前端的未来属于它们。在今年整体资本市场冷却的大环境下，to B的创业公司显现出了较强的生命力，这种类型的业务也给Web前端的工作带来了明显的差异性，工程师整体技能方向也展露出一丝不一样的分支。
今年中，几乎所有的现代桌面浏览器都已经支持了HTTP/2协议，移动端依靠降级为SPDY依旧可以覆盖几乎所有平台，这样使得从协议上优化页面的性能成为了可能。同时，前端静态资源打包的必要性成为了一定程度上的争论焦点，打包合并作为传统的前端性能优化方案，它的存留对前端工程化影响极大，Facebook公司著名的静态资源动态打包方案的优越性也会被弱化。社区上多篇文章纷纷发表对HTTP/2的性能实验数据，却不尽相同。
在2017年，我相信所有大型站点都会切换HTTP/2，但依旧不会放弃对静态资源打包合并的依赖。而且，对于Server Push等高级特性，也不会有太多的应用。
三年前还在考虑兼容IE6的前端技术社区，在前不久天猫宣布不再支持IE8后又引起了一股躁动。IE8是Windows XP操作系统支持的最高IE版本，放弃IE8意味着放弃了使用IE的所有XP用户。
其实在2016年的今天，前端社区中框架、工具的发展早已不允许IE8的存在，Angular 早在1.3版本就果断放弃了IE8，React 也在年初的v15版本上宣布放弃。在PC领域，你依旧可以使用像Backbone.js一样的其他框架继续对IE进行支持，但无论是从研发效率上还是从运行时效率上，放弃它都是更好的选择。
由于对HTML5兼容性不佳，在2017年，相信IE9也会逐渐被社区放弃，以取得更好的性能、更少的代码体积。
去年定稿的ES2015（亦称ES6）带来了大量令人激动的新语言特性，并快速被V8和SpiderMonkey所实现。但由于浏览器版本碎片化问题，目前编写生产环境代码仍然以ES5为主。今年年中发布的ES2017带来的新特性数量少的可怜，但这正好给了浏览器厂商消化ES2015的时间，在ES2017到来之前喘口气——是的，明年的ES2017势必又会带来一大波新特性。
JS解释引擎对新特性的支持程度并不能阻碍狂热的开发者使用他们，在接下来的很长时间，业界对Babel的依赖必然有增无减。Babel生态对下一代ECMAScript的影响会进一步加大，人们通过先增加新的Babel-plugin，后向ECMA提案的方式成为了ECMAScript进化的常态。开发者编写的代码能直接运行在浏览器上的会越来越少。
但使用Babel导致的编译后代码体积增大的问题并没有被特别关注，由于polyfill可能被重复引入，部署到生产环境的代码带有相当一部分冗余。
作为ECMAScript语言的超集，TypeScript在今年取得了优异的成绩，Angular 2放弃了传说中的AtScript，成为了TypeScript的最大客户。人们可以像编写Java一样编写JavaScript，有效提升了代码的表述性和类型安全性。
但凡事有两面，TypeScript的特性也在不断升级，在生产环境中，你可能需要一套规范来约束开发者，防止滥用导致的不兼容，这反而增加了学习成本、应用复杂性和升级安全性。个中优劣，仍需有大量的工程实践去积累经验。
此外，TypeScript也可以看做一种转译器，与Babel有着类似的新特性支持。在2017年，我们期待TypeScript与Babel会发展成怎样的一种微妙关系。
promise、generator 与 async/await
在回调地狱问题上，近两年我们不断被新的方案乱花了眼。过去我们会利用async来简化异步流的设计，直到“正房”Promise的到来。但它们只是callback模式的语法糖，并没有完全消除callback的使用。
ES2015带来的generator/yield似乎成为了解决异步编程的一大法宝，虽然它并非为解决异步编程所设计的。但generaor的运行是十分繁琐的，因此另一个工具co又成为了使用generator的必备之选。Node.js社区的Koa框架初始就设计为使用generator编写洋葱皮一样的控制流。
但昙花一现，转眼间async/await的语法，配合Promise编写异步代码的方式立即席卷整个前端社区，虽然async/await仍然在ES2017的草案中，但在今天，不写async/await立刻显得你的设计落后社区平均水平一大截。
在Node.js上，v7已经支持在harmony参数下的async/await直接解释，在明年4月份的v8中，将会正式支持，届时，Koa 2的正式版也会发布，几乎完全摒弃了generator。
受到回调问题的影响，传统的XMLHttpRequest有被fetch API 取代之势。如今，成熟的polyfill如whatwg-fetch、node-fetch、isomorphic-fetch在npm上的每日下载量都非常大，即便对于兼容性不好的移动端，开发者也不愿使用繁琐的AJAX。借助async/await的语法，使用fetch API能让代码更简洁。
Koa与流行的Express属于“同根生”的关系，它们由同一团队打造。相比Express，新的Koa框架更轻量、更灵活。但Koa的设计在短时间内曾经出现了较大的变动，这主要受到了async/await语法对异步编程的影响。在v2版本中，Koa的middleware抛弃generator转而支持async，所有第三方middleware实现，要么自行升级，要么使用Koa-convert进行包装转换。
目前Koa在Node.js社区的HTTP服务端框架中受到关注度比较高，不过其在npm上latest目前仍处于1.x阶段，预计在2017年4月份发布Node.js v8后，就会升级到2.x。
Koa的轻量级设计意味着你需要大量第三方中间件去实现一个完整的Web应用，目前鲜有看到对Koa的大规模重度使用，因此也就对其无从评价。相信在明年，越来越多的产品应该会尝试部署Koa 2，届时，对第三方资源的依赖冲突也会尖锐起来，这需要一个过程才能让Koa的生态完备起来。预计在2018年，我们会得到一个足够健壮的Koa技术栈。这会促进Node.js在服务端领域的扩展，轻量级的Web服务将会逐渐成为市场上的主流。
今年六月份jQuery发布了3.0版本，距离2.0发布已经有三年多的时间，但重大的更新几乎没有。由于老旧浏览器的逐渐放弃和升级，jQuery需要处理的浏览器兼容性问题越来越少，专注于API易用性和效率越来越多。
随着如Angular、React、Ember、Vue.js等大量具备视图数据单双向绑定能力的框架被普及，使用jQuery编写指令式的代码操作DOM的人越来越少。早在2015年便有人声称jQuery已死，社区中也进行了大量雷同的讨论，今天我们看到确实jQuery的地位已大不如前，著名的sizzle选择器在今天已完全可由querySelector原生方法替代，操作DOM也可以由框架根据数据的变动自动完成。
明年jQuery在构建大型前端产品的过程中的依赖会被持续弱化，但其对浏览器特性的理解和积淀将对现有的和未来的类Angular的MVVM框架的开发依旧具有很大的借鉴意义。
好事多磨，Angular 2的正式版终于在今年下半年发布，相比于1.x，新的版本几乎是完全重新开发的框架，已经很难从设计中找到1.x的影子。陡峭的学习曲线也随之而来，npm、ES2015 Modules、Decorator、TypeScript、Zone.js、RxJS、JIT/AOT、E2E Test，几乎都是业界这两年中的最新概念，这着实给初学者带来了不小的困难。
Angular 2也更面向于开发单页应用（SPA），这是对ES2015 Modules语法描述的模块进行打包（bundle）的必然结果，因此Angular 2也更依赖于Webpack等“bundler”工具。
虽然Angular 声称支持TypeScript、ECMAScript和Dart三种语言，不过显然业界对Dart没什么太大兴趣，而对于ECMAScript和TypeScript，两种语言模式下Angular 2在API和构建流程上都有着隐式的（文档标注不明的）差异化，这必然会给开发者以困扰。加上业界第三方工具和组件的支持有限，TypeScript几乎是现在开发者唯一的选择。
此外，Angular团队已声明并没有完全放弃对1.x组件的支持，通过特有的兼容API，你可以在2.x中使用针对1.x开发的组件。鉴于不明确的风险，相信很少有团队愿意这样折腾。
现在在产品中使用Angular 2，在架构上，你需要考虑生产环境和开发环境下两种完全不同的构建模式，也就是JIT和AOT，这需要你有两套不一样的编译流程和配置文件。在不同环境下模块是否符合期望，可以用E2E、spec等方式来进行自动化测试，好的，那么Angular 2的测试API又可能成了技术壁垒，它的复杂度可能更甚Angular本身。可以确信，在业务压力的迫使下，绝大部分团队都会放弃编写测试。
总之，Angular 2是一个非常具有竞争力的框架，其设计非常具有前瞻性，但也由于太过复杂，很多特性都会成为鸡肋，被开发者所无视。由于React和Vue.js的竞争，Angular 2对社区的影响肯定不如其前辈1.x版本，且其更高级的特性如Server Render还没有被工程化实践，因此相信业界还会持续观望，甚至要等到下一个4.x版本的发布。
Vue.js 绝对是类MVVM框架中的一匹黑马，由作者一人打造，更可贵的是作者还是华人。Vue.js在社区内的影响非常之大，特别是2.0的发布，社区快速生产出了无数基于Vue.js的解决方案，这主要还是受益于其简单的接口API和友好的文档。可见作为提供商，产品的简单易用性显得尤为重要。在性能上，Vue.js基于ES5 Setter，得到了比Angular 1.x脏检查机制成倍的性能提升。而2.0在模块化上又更进一步，开发难度更低，维护性更好。可以说Vue.js准确地戳中了普通Web开发者的痛点。在国内，Vue.js与Weex达成了合作，期待能给社区带来怎样的惊喜。
目前看来，React似乎仍是今年最流行的数据视图层解决方案，并且几乎已经成为了每名前端工程师的标配技能。今年React除了版本从0.14直接跃升至15，放弃了IE8以外，并没有更多爆发式的发展。人们对于使用JSX语法编写Web应用已经习以为常，就像过去十年间写jQuery一样。
React的代码在维护性能上显而易见，如果JSX编写得当，在重渲染性能上也具备优势，但如果只部署在浏览器环境中，那么首屏性能将会受到负面影响，毕竟在现阶段，纯前端渲染仍然快不过后端渲染，况且后端具备天生的chunked分段输出优势。我们在业界中可以看到一些负面的案例，比如某新闻应用利用React全部改写的case，就是对React的一种误用，完全不顾其场景劣势。
围绕着React发展的替代品和配套工具依旧很活跃，preact以完全兼容的API和小巧的体积为卖点，inferno以更快的速度为卖点，等等。每个框架都想在Virtual DOM上有所创新，但它们的提升都不是革命性的，由此而带来的第三方插件不兼容性，这种风险是开发者不愿承担的，笔者认为它们最大的意义在于能为React的内部实现提供另外的思路。就像在自然界，生物多样性是十分必要的，杂交能带来珍贵的进化优势。
今年是React-Native（以下简称RN）支持双端开发的第一年，不断有团队分享了自己在RN上的实践成果，似乎前途一片大好，RN确实有效解决了传统客户端受限于发版周期、H5受限于性能的难题，做到了鱼和熊掌兼得的理想目标。
但我们仍然需要质疑：
首先，RN目前以两周为周期发布新版本，没有LTS，每个版本向前不兼容。也就是说，你使用0.39.0的版本编写bundle代码，想运行在0.35.0的runtime上，这几乎会100%出问题。在这种情况下，如何制定客户端上RN的升级策略？如果升级，那么业务上如何针对一个以上的runtime版本编写代码？如果不升级，那么这意味着你需要自己维护一个LTS。要知道目前每个RN的版本都会有针对前版本的bug fix，相信没有团队有精力可以在一个老版本上同步这些，如果不能，那业务端面对的将是一个始终存在bug的runtime，其开发心理压力可想而知。
其次，虽然RN声称支持Android与iOS双端，但在实践中却存在了极多系统差异性。有些体现在了RN文档中，有一些则体现在了issue中，包括其他一些问题，GitHub上RN的近700个issue足以让人望而却步。如果不能高效处理开发中遇到的各种匪夷所思的问题，那么工期就会出现严重风险。
此外，RN在Android和iOS上的性能也不尽相同，Android上更差一些，即便你完成了整个业务功能，却还要在性能优化上消耗精力。并且无论如何优化，单线程模型既要实现流畅的转场动画，又要操作一系列数据，需要很高的技巧才能保证可观的性能表现。在具体的实践中，对于H5，往往由于时间关系，业务上先会上一个还算过得去的版本，过后再启动性能优化。然而对于RN，很有可能达到“过得去”的标准都需要大量的重构工作。
再次，RN虽然以Native渲染元素，但毕竟是运行在JavaScript Core内核之上，依旧是单线程，相对于H5这并没有对性能有革命性质的提升。Animated动画、大ListView滚动都是老生常谈的性能瓶颈，为了解决一些复杂组件所引起的性能和兼容性问题，诸多团队纷纷发挥主动能动性，自己建设基于Native的高性能组件，
这有两方面问题，一是不利于分发共享，因为它严重依赖特定的客户端环境，二是它仍依赖客户端发版，仍需要客户端的开发，违背了RN最最重要的初衷。可以想象，在大量频繁引用Native组件后，RN又退化成了H5+Hybrid模式，其UI的高性能优势将会在设备性能不断升级下被削弱，同时其无stable版本反而给开发带来了更多不可预测的风险变量。
最后，RN仍然难以调试和测试。特别是依赖了特定端上组件之后，本地的自动化测试几乎成为了不可能，而绝大多数客户端根本不支持自动化测试。而调试只能利用remote debugger有限的能力，在性能分析上都十分不便。
可以说RN的出现带给了移动开发以独特的新视角，使得利用JavaScript开发Native成为了可能，NativeScript、Weex等类似的解决方案也发展开来。显然RN目前最大的问题仍然是不够成熟和稳定，利用RN替代Native依然存在着诸多风险，这对于重量级的、长期维护的客户端产品可能并不是特别适合，比如Facebook自己。RN的优势显而易见，但其问题也是严重的，需要决策者对个方面利弊都有所了解，毕竟这种试错的成本不算小。
由于时间关系，市场上并没有一个产品在RN的应用上有着足够久的实践经验，大部分依然属于“我们把RN部署到客户端了”的阶段，我们也无法预测这门技术的长久表现，现在评价RN的最终价值还为时尚早。在2017年，期待RN团队能做出更长足的进步，但不要太乐观，以目前的状态来看，想达到stable状态还是有着相当大的难度。
Redux 成功成为了 React 技术栈中的最重要成员之一。与Vue.js一样，Redux也是凭借着比其他Flux框架更简单易懂的API才能脱颖而出。不过已经很快有人开始厌烦它每写一个应用都要定义action、reducer、store以及一大堆函数式调用的繁琐做法了。
Mobx也是基于ES5 setter，让开发者可以不用主动调用action函数就可以触发视图刷新，它只需要一个store对象以及几个decorator就能完成配置，确实比Redux简单得多。
在数据到视图同步上，无论使用什么样的框架，都有一个至关重要的问题是需要开发者自己操心，那就是在众多数据变动的情形下，如何保证视图以最少的但合理的频率去刷新，以节省极其敏感的性能消耗。在Redux或Mobx上都会出现这个问题，而Mobx尤甚。为了配合提升视图的性能，你依然需要引入action、transaction等高级概念。在控制流与视图分离的架构中，这是开发者无可避免的关注点，而对于Angular、Vue.js，框架会帮你做很多事情，开发者需要考虑的自然少了许多。
