[转] 2016前端开发技术巡礼

 

 

2016年立刻过去了，像过去六年中的每年同样，Web前端领域又产生了“面目全非”而又“耳目一新”的变化，不但旧事物持续不断地被淘汰，新事物也难保坐久江山，大有朝不保夕之势。开源界如群雄逐鹿，不断生产新的概念、新的框架、新的工具，去年中一些流行的技术今年大多获得了进一步的演进和升级，活跃度很是高，却仍然不能保证前端的将来属于它们。在今年总体资本市场冷却的大环境下，to B业务的创业公司显现出了较强的生命力，这种类型的业务也给Web前端的工做带来了明显的差别性，工程师总体技能方向也展露出一丝不同的分支。本文将从下至上、由低到高的维度盘点过去一年中Web前端领域发生的重要事件以及影响将来2017的关键性因素。视野所限，不尽完整。

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

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也会逐渐被社区放弃，以取得更好的性能、更少的代码体积。

2、如何编写(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

受到回调问题的影响，传统的XMLHttpRequest有被fetch API 取代之势。现在，成熟的polyfill如whatwg-fetch、node-fetch、isomorphic-fetch在npm上的每日下载量都很是大，即使对于兼容性很差的移动端，开发者也不肯使用繁琐的AJAX。借助async/await的语法，使用fetch API能让代码更简洁。

3、Node.js服务与工具

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

4、框架纷争

4.1 jQuery已死？

今年六月份jQuery发布了3.0版本，距离2.0发布已经有三年多的时间，但重大的更新几乎没有。因为老旧浏览器的逐渐放弃和升级，jQuery须要处理的浏览器兼容性问题愈来愈少，专一于API易用性和效率愈来愈多。

随着如Angular、React、Ember、Vue.js等大量具有视图数据单双向绑定能力的框架被普及，使用jQuery编写指令式的代码操做DOM的人愈来愈少。早在2015年便有人声称jQuery已死，社区中也进行了大量雷同的讨论，今天咱们看到确实jQuery的地位已大不如前，著名的sizzle选择器在今天已彻底可由querySelector*原生方法替代，操做DOM也能够由框架根据数据的变更自动完成。

明年jQuery在构建大型前端产品的过程当中的依赖会被持续弱化，但其对浏览器特性的理解和积淀将对现有的和将来的类Angular的MVVM框架的开发依旧具备很大的借鉴意义。

4.2 Angular 2

好事多磨，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版本的发布。

4.3 Vue.js 2.0

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达成了合做，期待能给社区带来怎样的惊喜。

4.4 React

目前看来，React彷佛还是今年最流行的数据视图层解决方案，而且几乎已经成为了每名前端工程师的标配技能。今年React除了版本从0.14直接跃升至15，放弃了IE8之外，并无更多爆发式的发展。人们对于使用JSX语法编写Web应用已经习觉得常，就像过去十年间写jQuery同样。

React的代码在维护性能上显而易见，若是JSX编写得当，在重渲染性能上也具有优点，但若是只部署在浏览器环境中，那么首屏性能将会受到负面影响，毕竟在现阶段，纯前端渲染仍然快不事后端渲染，何况后端具有天生的chunked分段输出优点。咱们在业界中能够看到一些负面的案例，好比某新闻应用利用React所有改写的case，就是对React的一种误用，彻底不顾其场景劣势。

围绕着React发展的替代品和配套工具依旧很活跃，preact以彻底兼容的API和小巧的体积为卖点，inferno以更快的速度为卖点，等等。每一个框架都想在Virtual DOM上有所创新，但它们的提高都不是革命性的，由此而带来的第三方插件不兼容性，这种风险是开发者不肯承担的，笔者认为它们最大的意义在于能为React的内部实现提供另外的思路。就像在天然界，生物多样性是十分必要的，杂交能带来珍贵的进化优点。

4.5 React-native

今年是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状态仍是有着至关大的难度。

4.6 Redux 与 Mobx

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，框架会帮你作不少事情，开发者须要考虑的天然少了许多。

4.7 Bootstrap 4

Bootstrap 4处于alpha阶段已经很是久了，即便如今3.x已经中止了维护，它彷佛受到了Twitter公司业务不景气的影响，GitHub上的issue还很是多。Bootstrap是建设内部平台最佳的CSS框架，特别是对于那些对前端不甚了解的后端工程师。咱们不清楚Bootstrap还能坚持多久，若是Twitter不得不放弃它，最好的归宿多是把它交给第三方开源社区去维护。

5、工程化与架构

5.1 Rollup 与 Webpack 2

Rollup是近一年兴起的又一打包工具，其最大卖点是能够对ES2015 Modules的模块直接打包，以及引入了Tree-Shaking算法。经过引入Babel-loader，Webpack同样能够对ES2015 Modules进行打包，因而Rollup的亮点仅在于Tree-Shaking，这是一种可以去除冗余，减小代码体积的技术。经过分析AST（抽象语法树），Rollup能够发现那些不会被使用的代码，并去除它。

不过Tree-Shaking即将不是Rollup的专利了，Webpack 2也将支持，并也原生支持ES6 Modules。这能够说是“旁门左道”对主流派系进行贡献的一个典型案例。

Webpack是去年大热的打包工具，俨然已经成为了替代grunt/gulp的最新构建工具，但显然并非这样。笔者一直认为Webpack做为一个module bundler，作了太多与其无关的事情，从而表象上看来这就是一个工程构建工具。经典的构建须要有任务的概念，而后控制任务的执行顺序，这正是Ant、Grunt、Gulp作的事情。Webpack不是这样，它最重要的概念是entry，一个或者多个，它必须是类JavaScript语言编写的磁盘文件，全部其余如CSS、HTML都是围绕着entry被处理的。估计你很难一眼从配置文件中看出Webpack对当前项目进行了怎样的“构建”，不过彷佛社区中并无人提出过异议，一切都运行得很好。

题外话：如何使用Webpack构建一个没有任何JavaScript代码的工程？

新的Angular 2使用Webpack 2编译效果更加，不过，已经提了一年的Webpack 2，至今仍处于beta阶段，好在如今已经rc，相信离release不远了。

5.2 npm、jspm、Bower与Yarn

在模块管理器这里，npm依旧是王者，但要说明的是，npm的全称是node package mamager，主要用来管理运行在Node上的模块，但如今却托管了大量只能运行在浏览器上的模块。形成这种现象的几个缘由：

1. Webpack的大量使用，使得前端也能够并习惯于使用CommonJS类型的模块；
2. 没有更合适的替代者，Bower之前不是，之后更不会是。

前端的模块化规范过去一直处于战国纷争的年代。在Node上CommonJS没什么意见。在浏览器上，虽然如今有了ES2015 Modules，却缺乏了模块加载器，将来多是SystemJS，但如今仍处于草案阶段。不管哪一种，都仍处于JavaScript语言层面，而完整的前端模块化还要包括CSS与HTML，以及一些二进制资源。目前最贴近的方案也就只能是JSX+CSS in JS的模式了，这在Webpack环境下大行其道。这种现象甚至影响了Angular 二、Ember 2等框架的设计。从这点看来，jspm只是一个加了层包装的壳子，彻底没有任何优点。

npm自己也存在着各类问题，这在实践中总会影响效率、安全以及一致性，Facebook果断地出品了Yarn——npm的替代升级版，支持离线模式、严格的依赖版本管理等在工程中很是实用的特性。

至于前端模块化，JavaScript有CommonJS和ES2015 Modules就够了，但工程中的组件，可能还须要在不一样的框架环境中重复被开发，它们依旧不兼容。将来的话，WebComponents多是一个比较优越的方案。

5.3 同构

同构的设计在软件行业早就被提出，不过在Web前端，仍是在Node.js、特别是React的出现后，才真正成为了可能，由于React内核的运行并不依赖于浏览器DOM环境。

React的同构是一个比较低成本的方案，只要注意代码的执行环境，先后端确实能够共享很大一部分代码，随之带来的一大收益是有效克服了SPA这种前端渲染的页面在首屏性能上的瓶颈，这是全部具有视图能力的框架Angular、Vue.js、React等的共性问题，而如今，它们都在一种程度上支持server render。

能够想到的作先后端同构面临的几个问题：

1. 静态资源如何引入，CSS in JS模式须要考虑在Node.js上的兼容性；
2. 数据接口如何fetch，在浏览器上是AJAX，在Node.js上是什么；
3. 如何作路由同构，浏览器无刷新切换页面，新路由在服务端可用；
4. 大量DOM渲染如何避免阻塞Node.js的执行进程

目前GitHub上star较多的同构框架包括Vue.js的nuxt和React的next.js，以及数据存储全包的meteor。能够确定的是，不论它们是否能部署在生产环境中，都不可能知足你的全部需求，适当的从新架构是必要的，在这个新的领域，没有太多的经验能够借鉴。

6、将来技术与职业培养

6.1 大数据方向

愈来愈多作toB业务的公司对前端的需求都是在数据可视化上，或者更通俗一些——报表。这个部分在从前一般都是前端工程师嗤之以鼻的方向，认为无聊、没技术。不过在移动端时代，特别是大数据时代，对此类技能的需求增多，技术的含金量也持续提高。根据“面向工资编程”的原则，必定会有大量工程师加入进来。

对这个方向的技术技能要求是Canvas、WebGL，但其实绝大多数需求都不须要你直接与底层API打交道，已经有大量第三方工具帮你作到了，不乏很是优秀的框架。如百度的ECharts，国外的Chart.js、Highcharts、D3.js等等，特别是D3.js，几乎是大数据前端方向的神器，很是值得学习。

话说回来，做为工程师，心存忧患意识，必定不能以学会这几款工具就知足，在实际的业务场景中，更多的须要你扩展框架，生产本身的组件，这须要你具有必定的数学、图形和OpenGL底层知识，能够说是很是大的技术壁垒和入门门槛。

6.2 WebVR

今年能够说是VR技术爆发式的一年，市场上推出了多款VR游戏设备，而淘宝更是开发出了平民的buy+购物体验，等普及开来，几乎能够颠覆传统的网上购物方式。

VR的开发离不开对3D环境的构建，WebVR标准还在草案阶段，A-Frame能够用来体验，另外一个three.js框架是一个比较成熟的构建3D场景的工具，除了能在将来的VR应用中大显身手，一样也在构建极大丰富的3D交互移动端页面中显得必不可少，淘宝就是国内这方面的先驱。

6.3 WebAssembly

asm.js已发展成WebAssembly，由谷歌、微软、苹果和Mozilla四家共同推进，彷佛是很是喜人乐见的事情，毕竟主要浏览器内核厂商都在这里了。不过合做的一大问题就是低效，今年终于有了能够演示的demo，容许编写C++代码来运行在浏览器上了，你须要下载一大堆依赖库，以及一次很是耗时的编译，不过好歹是个进步。

短期内，咱们都不太可能改变使用JavaScript编写前端代码的现状，Dart失败了，只能指望于将来的WebAssembly。有了它，前端在运行时效率、安全性都会上一个台阶，其余随之而来的问题，就只能等到那一天再说了。

6.4 WebComponents

WebComponents能带给咱们什么呢？HTML Template、Shadow DOM、Custom Element和HTML Import？是的，很是完美的组件化系统。Angular、React的组件化系统中，都是以Custom Element的方式组合HTML，但这都是假象，它们最终都会被编译成JavaScript才会执行。但WebComponents不同，Custom Element原生就能够被浏览器解析，DOM元素自己的方法均可以自定义，并且元素内部的子元素、样式，因为Shadow DOM的存在，不会污染全局空间，真正成为了一个沙箱，组件化就应该是这个样子，外部只关心接口，不关心也不能操纵内部的实现。

当前的组件化，无不依赖于某一特定的框架环境，或者是Angular，或者是React，想移植就须要翻盘推倒重来，也就是说他们是不兼容的。有了WebComponents，做为浏览器厂商共同遵循和支持的标准，这一现状将极有可能被改写。

将来的前端组件化分发将不会是npm那么简单，可能只是引用一个HTML文件，更有可能的是包含CSS、HTML、JavaScript和其余二进制资源的一个目录。

目前只有最新的Chrome彻底支持WebComponents的全部特性，因此距离真正应用它还尚需时日。因为技术上的限制，WebComponents polyfill的能力都很是受限，Shadow DOM不可能实现，而其余三者则更多须要离线编译实现，能够参考Vue.js 2的实现，很是相似于WebComponents。

6.5 关于微信小程序

微信小程序对于今年不得不说，却也无话可说。依托于庞大的用户量，微信官方出品了自有的一套开发技术栈，只能说给繁杂的前端开发又填了一个角色——微信前端工程师。

7、总结

最后还有几点须要说明。

7.1 工程化

首先，如今业界都在大谈前端工程化，人人学构建，个个会打包。鄙人认为，工程化的要点在于“平衡诸方案利弊，取各指标的加权收益最大化”。仅仅加入了项目构建是远远不够的，在实践中，咱们常常须要考虑的方向大能够分为两种：一是研发效率，这直接应该响应业务需求的能力；二是运行时性能，这直接影响用户的使用体验，同时也是产品经理所关心的。这两点都直接影响了公司的收入和业绩。

具体到细节的问题上来，好比说：

1. 静态资源若是组织和打包，对于具有众多页面的产品，考虑到不断的迭代更新，如何打包能让用户的代码下载量最少（性能）？不要说使用Webpack打成一个包，也不要说编译common chunk就万事大吉了，难道还须要不断地调整编译脚本（效率）？改错了怎么办？有测试方案么？
2. 利用Angular特别是React构建纯前端渲染页面，首屏性能如何保证（性能）？引入服务端同构渲染，好的，那么服务端由谁来编写？想来必是由前端工程师来编写，那么服务端的数据层架构是怎么样的？运维角度看，前端如何保证服务的稳定（效率）？
3. 组件化方案如何制定（效率）？若是保证组件的分发和引用的便捷性？如何保证组件在用户端的即插即用（性能）？

对于工程师来讲，首先须要量化每一个指标的权重，而后对于备选方案，逐个计算加权值，取最大值者，这才是科学的技术选型方法论。

然而在业界，不多能看到针对工程化的更深刻分享和讨论，大多停留在“哪一个框架好”，“使用XXX实现XXX”的阶段，每每是某一特定方向的优与劣，不多有科学的全局观。甚至只看到了某一方案的优点，对其弊端和可持续性避而不谈。形成这种现状的缘由是多方面的，一是技术上，工程师能力的缘由并无考虑获得，二是政治上，工程师须要快速实现某一目标，以取得可见的KPI收益，完成团队的绩效目标，但更多的多是，国内绝大多数产品的复杂性都还不够高，根本无需考虑长久的可持续发展和大规模的团队合做对于技术方案的影响。

所以，你必须接受的现状是，不管你是否使用CSS预处理器、使用Webpack仍是grunt、使用React仍是Angular，使用RN仍是Hybrid，对于产品极有可能都不是那么地敏感和重要，每每更取决于决策者的我的喜爱。

7.2 角色定位

确实，近两年，Web前端工程师开始不够老实，要么用Node.js插手服务端开发，要么用RN插手客户端开发。如何看待这些行为呢？

鄙人觉得，涉足服务端开发是没问题的，由于只涉及到渲染层面，仍是属于“前端”的范畴的。何况，在实际的工程实践中，已经能够证实，优秀的前端研发体系确实离不开服务端的参与，想一想Facebook的BigPipe。不过，这须要服务端良好的分层架构，数据与渲染彻底解耦分离，后端工程师只负责业务数据的CRUD，并提供接口，前端工程师从接口中获取数据，并推送到浏览器上。数据解耦是比接口解耦更加优越的方案。所以如今只要你的服务端架构容许，Node.js做为Web服务已经比较成熟，前端负责服务端渲染是彻底没有问题的。

前端涉足客户端开发也是合理的，毕竟都运行在用户端，也属于前端的范畴。抛开阿里系的Weex鄙人不甚了解，NativeScript、RN都还缺少大规模持续使用的先例，这是与涉足服务端领域的不一样，客户端上的方案都还不够成熟，工具的限制阻碍了前端向客户端的转型，仍然须要时间的考验。不过期间可能不会不少，将来的Web技术依托高性能硬件以及普及的WebGL、WebRTC、Payment API等能力，在性能和功能上都会挑战Native的地位。最差的状况，还能够基于Hybrid，利用Native适当扩展能力，这就是合做而非竞争关系了。

总以前端工程师的本仍然在浏览器上，就这一点，范围就足够广使得没人有敢言本身真正“精通”前端。若是条件容许的话，特别是技术成熟以后，涉猎其余领域也是鼓励的。

7.3 写在最后

在各类研发角色中，前端注定是一个比较心累的一个。每年的年底，咱们都能看到几乎彻底不同的世界，这背后是无数前端人烧脑思考、激情迸发的结果。不管最终产品的流行与否，都推进着前端技术领域的高速更新换代。正是印证了那一句“惟有变化为不变”。做为业务线的研发工程师，咱们的职责是甄选最佳组合方案，取得公司利益最大化。这个“最佳”的涉猎面很是广，取决于设计者的技术视野广度，也有关于决策者的管理经验，历来都不是一件简单的事。

将来的Web前端开发体验必定是更丰富的，依托WebComponents的标准化组件体系，基于WebAssembly的高性能运行时代码，以及背靠HTTP/2协议的高速资源加载，前端工程师没必要在性能上、兼容性上分散太多精力，从而能够专一于开发具有丰富式交互体验的下一代Web APP，多是VR，也多是游戏。

在迎接2017的同时，咱们仍然要作好心理准备，新的概念、新的框架和工具以及新的语法依旧会源源不断的生产出来，不完美的现状也依旧会持续。

因为水平有限，笔者在上述内容中不免有失偏颇，请多包涵。