割裂的前端工程师2017年前端生态窥探

有一天，我们组内的一个小伙伴突然问我，你知道有一个叫重构工程师的岗位？这是干什么的？重构工程师

这个问题引发了我对前端领域发展的思考，所以我来梳理下前端领域的发展过程，顺便小小的预测下2017年的趋势。不想看回忆的，可以直接跳到后面看展望。

神说，要有光，就有了光

自1991年蒂姆·伯纳斯-李公开提及HTML描述，到1999年W3C发布HTML4期间，写网页是为了更好的交流彼此的想法，为了能够维护自己的网页，各路大神也是八仙过海各显神通，甚至发明了PHP（这个世界最好的语言）。这个时期并没有一个所谓的前端开发岗位的，大家都是软件工程师。当然这个时代也是神人辈出的时代，太多现在互联网或者说整个IT行业的概念和雏形在这个时期形成。Google网站正式启用，个人PC开始慢慢普及。

神称空气为天

O&＃8217;Reilly Media、Battelle和MediaLive在2004年10月引导了第一个Web 2.0大会，web2.0时代开启，Blog，Wiki，RSS各种个人网站开始登陆大家的视野，同时，豆瓣，天涯这些符合2.0时代的产物开始在国内大行其道。我们有了第一波注重Web前端的软件开发师，同一时刻，米国诞生了FaceBook具有跨时代的产物，05年，校内网出现，前端们开始活跃起来了，06年8月，Jquery的第一个版本发布。

神称旱地为地，称水的聚处为海

之后的几年间，前端基本都是围绕着各种类库如MooTools，Underscore，Prototype，Dojo，jQuery ，YUI开发页面。各大类库也是相互吸收优点，不断完善自身，但是本质没有太多变化。

与此同时，在我们看不到的背后，浏览器第二次大战打响，V8引擎开始大放异彩，Web标准也在推动ECMAScript5.0进化着。Node发布了，意味着我们前端的领域扩大了，伸手到服务端了。

智能手机开始普及，移动端大浪潮流势不可挡，web前端们开始为了移动端开发各种类库了Sencha Touch，Zepto.js，JQ Mobile，HTML5概念火热了起来，各种网页小游戏层出不穷，和Flash的争斗也到了水火不容的地步，Twitter 也推出了 Bootstrap这个引领风骚的CSS工具包。

随着系统硬件的提升，V8引擎性能的提升，整个网页的性能极大提高，大家开始纷纷开发出复杂的Web页面来，这种需求开始催生了前端们对开发的工程化思考，首当其冲的就是模块化加载的问题，AMD、CMD、UMD 登上舞台，起衍生的产物Seajs，requirejs开始划分地盘。

这个时代还是服务端渲染为王的时代，包括很多模块或者组件上的拼接都是在服务端完成的，但同时也开启jquery + requirejs + template开发复杂页面的模式。（这个时间段，出现了重构工程师和JS工程师的划分。）

管理昼夜，分别明暗

12年之后，随着W3C规范和标准进一步推动，大家对Web页面复杂度进一步的加剧，人们不在满足于Jquery面条时的开发，出现了许多用于简化客户端开发的框架，诸如Backbone，Ember，AngularJS，Vue，Avalon，Knockout，React等等各种各样的MV*框架。

这是一个群雄割据的时代，如此多的框架涌出，每个开发者根据自己的喜好，业务的需求选择着不同框架来完成目标。

Node.js开始崛起，Express，Koa框架开始使用到各种生产项目中，PM2的服务管理，为企业解决了监控和稳定问题，同时，阿里开始探索Node.js中间层的开发道路，连续发声，提供前后端分离解决方案。

神说，水要多多滋生有生命的物

微信这个社交庞然大物已然崛起，微信公众号的玩法，让前端岗位开始火热了起来，也开始带来了Web和Native的争端。

15年，Facebook 在 React.js Conf 2015 大会上推出了基于 Javascript 的开源框架 React Native，一举将React推上了一个新的高度，learn once ，write everywhere。这一年是属于React的年份。

同时，构建工具也在不停的迭代，Grunt的辉煌已去，Gulp并未在王座上久呆，Webpack的风暴就席卷而来。

16年，Webpack已经成为了前端打包构建的主流，Vue强势崛起，Ng2完成发布。前端在主流开发上基本形成了三国时代（React，Vue，Ng）。与此同时，移动端也形成了以混合开发为主的方式，Native嵌入Webview页面。

因为网络和硬件性能不断提升，前端从原来的cs模式到现在更像 bs，但也依然有 cs 的分发优势。

神就照着自己形象造人 &＃8212; 细分或者割裂

上面回忆了一下前端大概的发展历程，下面来说说自己对17年前端发展的一些预测。

随着业务的不同，每个团队在前端技术点开始有所分化：

1. 重型SPA页面

2. Hybrid方式的Web页面

3. 活动页面

4. 游戏等其他

重型SPA页面 &＃8212; Teambition

重型的SPA页面，业务功能极其复杂，使用Vue，React，Angular这种MVVM的框架后，在开发过程中，组件必然越来越多，父子组件之间的通信，子组件之间的通信频率都会大大增加。如何管理这些组件之间的数据流动就会成为这类WebApp的最大难点。

从页面的加载来说，SPA可以依靠首次加载的Loading动画，来掩盖一些页面加载性能的问题（TB我这里加载一般在5S左右），很多懒加载和延迟加载之类的也是不需要做。因为相关的数据后面都需要用到，也就不存在是否会使用的问题。

从最近Rx.js的star数，我们也能看出来，大家也越来越关心数据管理的问题，本地的数据管理只是一个方面，还会涉及到多个用户数据同步的问题，也就是服务端和客户端数据同步问题，如和及时正确的同步数据。

及时正确同步数据这个概念指的是： 多人操作一个任务时，两个人都在修改一个任务时，容易造成数据覆盖。A刚修改完，B过几秒也修改了，因为同步不及时，B不知道A修改了，结果B新修改的数据覆盖了A的修改。所以想要减少类似的错误，就必须要能保证及时正确的同步数据。

既然数据和请求如此多，那么就肯定要利用好本地的缓存和各种存储了，LocalStorage，SessionStorage的都会使用上。

如此多的业务和组件，必然对内存上会造成压力，如何管理好内存也是一门学问，比较典型的是组件的销毁，该如何合理的创建和销毁组件，已经组件内部data数据的组织都会很考验代码人员。

相关的可以看@徐飞的文章

Hybrid方式的Web页面 &＃8212; 现在大多数App的主流

Hybrid方式的开发目前还是移动端的主流，这种web页面的特点是业务并不复杂，大多是展示信息为主，再加上一些操作按钮，需要解决的问题，在于很多时候要和Native来通信，而且Android的webview有各种各样的国产厂商问题也是很难以解决，这方面微信做的不错，直接搞了一个自己的浏览器来统一底层的支持。

对于jsbridge的实现，各个公司有不同的实现方案，主要还是要看Native的开发怎么来定义bridge的方案，以我自己开发的经验来看，有这么几个点需要解决：

用户验证问题，怎么来确认Native的用户身份，是用原来Web网站常用的session还是使用Native比较常用的token，但是不管用哪种，都需要Native帮忙来注入标识。

ajax请求问题，如果使用一个URL的形式来嵌入，可以独自发送ajax请求没有任何问题，但是如果使用Html文本，直接Webview渲染的方式，就类似PC上，文件夹打开html文件一样，ajax请求发送不出去，需要Native帮忙做bridge来调用。

沟通成本问题，因为和原来PC端相比，多了参与方，所以排查问题就更加麻烦了，这个还是主要看整体App的架构怎么设计了。

性能问题，怎么说呢，不是每个App的开发人员都很厉害，那么如果Native的代码有问题，Webview出错的概率就会变高，比如Css3的动画，容易引起崩溃，内存占有率过高等等。

所以，对于这个方向的web前端的开发人员来说，如果会Native开发的经验更加如鱼得水。

活动页面 &＃8212; 比如来自宇宙的邀请函

这类活动页面，主要就是设计和动画上效果炫酷，吸人眼球，震撼人心，基本出来一个精彩的活动页面，都能在朋友圈掀起一波浪潮。技术上以WebGL为主，一般使用Three.js,渲染canvas来展示各种动画和视觉效果。

这个方向的前端会更加关注，浏览器的兼容，性能，设计出来的效果，动画的流畅度，体验等等。主要兼容的微信的浏览器，因为要在朋友圈来营销，总体来说，会偏设计以及动画些。

游戏等其他 &＃8212; H5小游戏，数据可视化

当时风靡国内的各种H5小游戏，特别多，基本是用CreateJs来制作的多，接触不多，不多评论。

HTML游戏引擎

随着大数据时代的来临，前端领域各种数据可视化的库也是层出不穷，D3，Highcharts，国内的Echarts都是这个领域的佼佼者。

转领域

其实还有一个领域，就是通过Nodejs，学习服务端的各种知识，切换到服务端领域去。

未来

上面的我所提到的细分（或者说是割裂&＃8211;比较有噱头），自我感觉，已经在慢慢展现出一些趋势了，不知道大家有木有感觉到，比如徐飞就会更加擅长TB这种重型业务流派，而手淘的人就会比较关注Hybrid的流派，甚至自己来搞Weex这种JS-Native开发的框架。当然大部分开发人员还是可能都会做，没有那么明显的倾向，但随着公司的业务的转变和公司重点资源的倾斜，很多开发人员还是会慢慢有所区分。

个人认为这种细分其实对我们前端更加有利的，

1. 前端业务重量化、场景多样化，表现出前端整个领域发展比较迅速，各方面都有参与到，一直跟随着时代发展而发展。

2. 有各种细分的领域，大家可以做到一专多精，不同细分领域的知识点，都需要认真的学习和研究，比如前端对数据的组织趋于集中化和范式化（Redux等）要求前端同学要懂基本的数据库原理。能够吃透每一个领域的知识点，都是一个巨大的挑战。

3. 利于交流，各种不同分支的人，可以拿出自己特长的技术来相互交流，取长补短，构建更加系统的知识网络。

其实要说的很多，感觉说不完，比如@寇云 提议加上Backbone，Ember，AngularJS，Vue，Alavon，Knockout，React 框架不是一个时间段出现，先驱者的思想被后生框架集成发展，以及框架生态这部分内容。但感觉并不算我这篇文章的重点，就没有加上。还有目前Native和Web前端之间的竞争与合作。

原文和讨论地址：知乎原文

（以上只是个人见解，如有雷同，只能说英雄所见略同）