2016年Web前端开发技术总结

2016年Web前端开发技术总结

前言

2016 年马上过去了，像过去六年中的每一年一样，Web前端领域又产生了“面目全非”而又“耳目一新”的变化，不但旧事物持续不断地被淘汰，新事物也难保坐久江山，大有岌岌可危之势。开源界如群雄逐鹿，不断生产新的概念、新的框架、新的工具，去年中一些流行的技术今年大多得到了进一步的演进和升级，活跃度非常高，却仍然不能保证前端的未来属于它们。在今年整体资本市场冷却的大环境下，to B的创业公司显现出了较强的生命力，这种类型的业务也给Web前端的工作带来了明显的差异性，工程师整体技能方向也展露出一丝不一样的分支。

一、更新的网络与软件环境

1.1 HTTP/2 的持续普及

今年中，几乎所有的现代桌面浏览器都已经支持了HTTP/2协议，移动端依靠降级为SPDY依旧可以覆盖几乎所有平台，这样使得从协议上优化页面的性能成为了可能。

同时，前端静态资源打包的必要性成为了一定程度上的争论焦点，打包合并作为传统的前端性能优化方案，它的存留对前端工程化影响极大，Facebook公司著名的静态资源动态打包方案的优越性也会被弱化。社区上多篇文章纷纷发表对HTTP/2的性能实验数据，却不尽相同。

在2017年，我相信所有大型站点都会切换HTTP/2，但依旧不会放弃对静态资源打包合并的依赖。而且，对于Server Push等高级特性，也不会有太多的应用。

1.2 Internet Explorer 8

三年前还在考虑兼容IE6的前端技术社区，在前不久天猫宣布不再支持IE8后又引起了一股躁动。IE8是Windows XP操作系统支持的最高IE版本，放弃IE8意味着放弃了使用IE的所有XP用户。

其实在2016年的今天，前端社区中框架、工具的发展早已不允许IE8的存在，Angular 早在1.3版本就果断放弃了IE8，React 也在年初的v15版本上宣布放弃。在PC领域，你依旧可以使用像Backbone.js一样的其他框架继续对IE进行支持，但无论是从研发效率上还是从运行时效率上，放弃它都是更好的选择。

由于对HTML5兼容性不佳，在2017年，相信IE9也会逐渐被社区放弃，以取得更好的性能、更少的代码体积。

二、如何编写(Java)Script

2.1 ES2016？ES2017？Babel!

去年定稿的ES2015（亦称ES6）带来了大量令人激动的新语言特性，并快速被V8和SpiderMonkey所实现。但由于浏览器版本碎片化问题，目前编写生产环境代码仍然以ES5为主。今年年中发布的ES2017带来的新特性数量少的可怜，但这正好给了浏览器厂商消化ES2015的时间，在ES2017到来之前喘口气——是的，明年的ES2017势必又会带来一大波新特性。

JS解释引擎对新特性的支持程度并不能阻碍狂热的开发者使用他们，在接下来的很长时间，业界对Babel的依赖必然有增无减。Babel生态对下一代ECMAScript的影响会进一步加大，人们通过先增加新的Babel-plugin，后向ECMA提案的方式成为了ECMAScript进化的常态。开发者编写的代码能直接运行在浏览器上的会越来越少。

但使用Babel导致的编译后代码体积增大的问题并没有被特别关注，由于polyfill可能被重复引入，部署到生产环境的代码带有相当一部分冗余。

2.2 TypeScript

作为ECMAScript语言的超集，TypeScript在今年取得了优异的成绩，Angular 2放弃了传说中的AtScript，成为了TypeScript的最大客户。人们可以像编写Java一样编写JavaScript，有效提升了代码的表述性和类型安全性。

但凡事有两面，TypeScript的特性也在不断升级，在生产环境中，你可能需要一套规范来约束开发者，防止滥用导致的不兼容，这反而增加了学习成本、应用复杂性和升级安全性。个中优劣，仍需有大量的工程实践去积累经验。

此外，TypeScript也可以看做一种转译器，与Babel有着类似的新特性支持。在2017年，我们期待TypeScript与Babel会发展成怎样的一种微妙关系。

2.3 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。

2.4 fetch

polyfill如whatwg-fetch、node-fetch、isomorphic-fetch在npm上的每日下载量都非常大，即便对于兼容性不好的移动端，开发者也不愿使用繁琐的AJAX。借助async/await的语法，使用fetch API能让代码更简洁。

三、Node.js服务与工具

Koa 2

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服务将会逐渐成为市场上的主流。