极简设计

近几年前端技术盘点以及 2016 年技术发展方向

近几年前端技术盘点以及 2016 年技术发展方向

基础类库完善,寻求突破

jQuery/Prototype/Dojo各大类库框架相互吸收优点,不断完善并提高自身性能,功能上没有太多增加的势头 开始思想上的转变,更注重组织和结构,条理性如YUI

浏览器引擎大战(比如V8),瓜分 IE 份额 Node.js/3G Mobile 巨兽浮出水面 Web 标准向 H5、es5.0 靠拢

看齐标准,关注 Web 性能

ExtJS/Dojo 摇身变为企业级框架,各类组件化概念和产品如约而至 HTML5 内容:Canvas/Video/Audio/Geolocation/Storage/Application Cache/Web SQL Database W3C 成立 Web 性能工作组,Google/Mozill推出应用商店,浏览器调试工具丰富了起来,更多关注开发体验和性能问题

HTML5 扛大旗(H5游戏火爆到了一个高潮),Flash 堪忧

响应式开发,工程化推进

众多移动端框架,如 Sencha Touch/Zepto.js/JQ Mobile 等,相对 PC 端框架,它们更加轻便

移动端崛起,带来多终端开发难题:多终端适配,多分辨率适配,远程调试等等 Twitter Bootstrap也方便了后端同学,快速建站更加简单

编程思想的切换,迎来了预处理语言 CoffeeScript/TypeScript,为 Js引来了不少其他方向转型过来的开发者

前端工程化上,几个派系相互争斗,产出AMD、CMD、UMD 等规范,衍生了 SeaJS、RequireJS 等模块化工具。这一年很有跳跃感

爆发式增长,百花齐放

规范和标准上有不少产出。Web Components 给前端开发开辟了新思路;WebDriver 推动自动化测试进程,ES 6草案落地

Chrome支持 SPDY,新渲染引擎Blink 取代 webkit ,DevTools 体验大幅度提升 LESS/SASS/Stylus 等 CSS 预处理语言开始走俏,Web 开发变得更加紧凑

无线端,应用不再局限于 Webapp(流畅度、性能等不能满足用户体验需求),大厂转向研究 Native 方向,Hybrid/PhoneGap 的繁荣,为 JS 调用提供更多的设备 API

Node.js 大放异彩,出现了诸如 Express、Meteor 等小巧的快速搭建 Node.js Server 的应用框架

自动化测试PhantomJS开始取代 Selenium,出现众多远程调试方案和工具

前端工程化开始普及,各公司开始推出自己的前端集成开发解决方案

移动端崛起,H5 和 ES6 落地

HTML5 正式定稿,这意味着,web page 正式演变为 web application。ES6 华丽丽走进前端,走的很稳重,它的 Module/Class 等特性已经完全让这门语言具备了开发大型应用的能力。

大而厚的基础库难以满足灵活场景,Mobile 要求极致体验,MV* 库铺卷而来,如 vue/angular/knockout 等。

Web Components 跨终端组件快速发展,移动端开发迎来一次升华。Node.js 前后端分离的流行,中间层的出现改变了前后端的合作模式。2014 是颠覆式的一年,前端发展在这一年开始形成了一个短暂的稳定格局

观念的转变,步入前端工业化生产

格外引人注目的框架: React,结合Web 应用和 Native 应用优势,用 JS开发 iOS/Android 原生应用。JS中用 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库越来越大,基础部分更多是对 JS本身的拓展,比如给 String 加一个 repeat/trim/endWith等等

复杂业务中经常一层又一层回调处理,回调嵌套让代码可读性很差,多个异步并行处理很难 为改变这种编程范式,使用事件监听,各种手段拉直回调,平坦地调用

被认可、广泛重复定义的东西,都被纳入了标准 prototype对语言本身的拓展,对 js各种类型做拓展,并且提供了一套拓展任何对象的功能集 jQuery主要是对浏览器做兼容处理,让开发者不再把精力放到浏览器的差异上

现在开发,很大程度上不再依托这些类库。规范和标准已经把这些差异都统一了 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 等等。待到山花烂漫时,再轻松删掉这些补丁程序

这两年工程化很热,就是市场的需求,为完成大型应用的编程,就必须模块化、组件化,于是在规范中也出现了 Module & Module Loader

Node.js 的到来,让很多前端工程师开始接触数据库操作,面对巨量的异步,我们忍气吞声写了无数的回调地狱,尽管使用了很多 Promise 相关的操作,程序结构依然松散难以阅读,于是规范中也开始出现了 async/await 等对 Generator 的上层封装

文字已经不能满足当代人的沟通需求,于是出现WebRTC/WebAudio 等规范

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

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

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

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

吃螃蟹的支付宝到天猫到淘宝,很多业务上已经主(bèi)动(bī)放弃对 IE6/7 的支持,甚至在统一接入层直接做了 302 跳转,提示用户更新浏览器或者引导流量到无线端。这是一个好的开始,我们期望这也是业界达成共识的开始!

HTTP/2.0一大特点就是多路复用,改变了前端编程的很多优化模式,比如 域名不是越多越好,为了能够充分利用浏览器的连接数,给 JS 和 CSS 开一个域名,给 img 开好几个域名,网页打开的时候,恰到好处的利用浏览器的连接数上限限制 HTTP/2.0 的多路复用,就是可以在一个 HTTP 请求中进行多个资源的传输,如果域名散列,反而不能利用这个特性

资源合并没有任何优势,以前的资源合并是为了减少请求数以节约建立 TCP 链接的网络开销和头部传输的流量开销,而在 HTTP/2.0 中,一个 HTTP 请求上完全可以把所有的资源全部推送过来,如果合并了资源,反而不能良好运用浏览器对资源的缓存

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

模块加载上,经过了各派系的争论之后,流传下来几个不错的产品 SeaJS、RequireJS 等,那么那个模块加载器将成为工具平台中短暂的终点呢? 似乎这些都不是。当我们按照规范中的方式进行模块定义,按照规范中的方式加载定义的模块时,加载这个流程就显得不那么重要了,因为这些事情最后都会变成 shiv/polyfill 的事情,最终会变成浏览器的固有属性

当一个东西在社区中被暴力追捧的时候,会有很多衍生的产品出来,当这些衍生物根深蒂固时,可能又会出现一个更加原生更加符合开发习惯的东西出来。就像 jQuery,我们为它编写的插件不计其数,而在工程化的需求冲击下,它却显得那么的弱不禁风,因为它关注的点和当前的发展态势不太吻合,仅此而已

Mobile 的发展驱动着战场的转移

当年Nokia5230 屏幕尺寸也就是三个手指的宽度,紧紧攥在手里看着页面混排效果极差的网页文档

如今iPhone 出到 6s,一个版本一个尺寸,而且尺寸越来越大,还有各种宽高不一的 Android 机器,种类繁多 以前触屏是电阻式,只支持单点触碰;现在电容式的触屏精度更高,还支持多指触控,这如丝般顺滑的体验在三四年前是完全体会不到的 曾经手机开一个程序久了就会卡,动不动还会自动重启;现在的手机开一堆程序,完全无感知,这就是硬件发展前后的差异

面对庞大的移动用户,我们的技术是否做好了充足的准备 PC 上那一套经验不是直接搬到移动端就可以使用了,在移动端还需要解决更多的问题:

  • 多分辨率问题,这里涉及到了响应式设计和前端响应式技术
  • 不同网络环境的网页加载优化问题,2g/3g/4g/wifi
  • 手指交互带来的一系列体验问题
  • 为了提升用户体验,将 Web Native 化 —— 类 React 技术带来的一系列问题
  • 远程调试问题
  • 移动安全问题等等

端的融合

不同分辨率的手机,不同物理尺寸的终端,为保持良好视觉/用户体验,不得不为每一个尺寸写一份 Media Query 代码,设计师也要设计多套版式供前端使用,这给设计师、前端和测试带来了无尽的麻烦。为此,通过前端技术重塑屏幕,重新定义像素尺寸,使用流式布局,通过百分比来响应不同的终端尺寸。这是端的融合

后续的 Mobile 的技术发展方向上,应该是相当明确的。很多公司都是三套人马维护三端的程序,iOS、Android 和 Web,而这三端做的事情都是一样的,一样的界面,一样的后端接口,一样的交互方式。为了能够快速响应业务的变更,我们不得不将三端合并为一端对待,用一套程序编程成三端代码,然后发布到三个平台上。这也是端的融合。React 系列技术发展到此,绝对不是终点,它只是一个探路灯,给我们照明了方向

技术需要为业务做保障,而好的技术是能够及时响应业务的变化,我们不可能投入大量的人力在 Web 的修补工作上,通过开发统一工具,屏蔽端和端之间的差异,统一开发模式和开发体验,这才是 Mobile 的未来

我们目前所做的「屏蔽差异」工作,今后也会有统一的标准来规范,目前手机厂商没有这个共识,是因为还处于当年 Chrome、Firefox 抢占 IE6 市场份额的阶段。端的最终融合在于一个统一的标准,以及强有力的执行

栈的融合

「全栈」,Web 技术栈往小里说,包含了从前端设计、交互、前端实现、网络数据传输、后端实现、后端运维和数据库等几个方面,能短时间内从无到有实现这么一套系统,并且能够抗得住一定流量冲击的人,可以称之为全栈工程师 能够有架构有条理地实现这套系统,并且抗得住大流量、有集成测试、有监控的,可以称之为资深全栈工程师。现在不乏这种人才,也不乏自吹为这种人

栈的融合得益于 Node.js 的出现,作为前后端分离的桥梁,它拉近了前端工程师与后端的距离,有的人在这座桥梁上卖力行走,渐渐的也从前端走进了后端,甚至走进了后端的运维。至此,前端也拥有了部署和发布整个应用的能力,这是一个质的突破

使用 Node.js,简单几行程序便能实现一个 web 服务器、便能搭建一个多人聊天的网页,它的便捷性可见一斑。NPM 社区的发展,沉淀了成千上万的组件包,一行命令即可获取,这种组件拼凑式的开发,任何功能的实现都不会显得太复杂,而这里的「不复杂」也蕴含了无数的坑坑洼洼,在这一层的融合上也会遇上不少阻碍

  • 冗余的庞大的包内容,为了使用一个小功能,我们从网络上拉取下来一个巨大的包,而且这里的「巨大」对很多人来说都是无感知的,很少会有人进入 node_modules 去查看依赖的第三方包是如何实现的,实际情况可能会相当震撼,第三方包还引用了一堆第三方包,这些包都会在 Node.js 执行的时候被收纳进去,放在内存中
  • 猛烈的迭代,今年的 Node.js 被人嫌弃迭代太慢了(当然,这是表面原因),走出了一个分支 io.js,发展了一会儿,进度赶超了 Node.js,后来觉得一家人不干两家活,又合并回去了。虽说上层 API 几乎没有变化,但是底层却被翻了一个天
  • 偶尔的巨大漏洞,每隔一端时间就会暴露 Node.js 存在漏洞,这些漏洞的补救措施就是立即升级版本号,比较让人担心受怕
  • 后端意识不强烈,前端占领了中间层的开发,有的时候还干这后端的活儿,然而却没有后端沉淀多年固有的意识,测试和监控做的相当潦草

Js 从客户端的脚本语言纵身跃进进入了后端行列,而今也开始深入到移动端 Native 领域,确实是无孔不入,这可能就是语言的特性,也可能是技术本身就在寻求融合点,把有差异的地方全部躺平,然后用统一的方式去关注业务,关注用户。端和栈也在融合

后端服务化,云数据,云安全

用户体验变得越来越重要,响应式技术的发展也是后续网页应用的一大特点,端和端之间的差异只是在表现上,数据这一层差异不是特别大,很多应用 PC 和 Mobile 共用一套接口,或者 Mobile 的接口在 PC 接口的基础上做了一层包装,对接口字段做了些许删减。后端为了响应各个端之间的数据需求,也需要关注数据的可利用性,接口包装的拓展性等,这是后端服务化的一个表现。移动端的开发上,前后端间隙十分明显,越来越多移动端应用的发布已经脱离了后端,前端完全通过异步方式获取数据

业务变化很快很快快,今天这个产品被并购,明天那个业务被砍掉,每个人负责的业务线可能冷不丁地就变了。很多大公司的决策是由上往下的,上面微动,下面可能就是大动,可能某个部门就不存在了,也可能被划分成几个产品部门

所以「大后台,小前台」的趋势必然形成。前端,毫无疑问,在这个前台之中。前台的特点是灵活的,多变的,可快速重组的。对后台而言,为了响应前台的变化,需要提供更细粒化的 API,将数据打散,打得更加零碎,零碎的数据易于重组,这是在考验后端的架构能力。如今,很多前端也都是半栈工程师,盘踞在前后端中间层上,然而如何迎接这种后端服务化的模式,似乎这个准备还是不够充足的

GraphQL 的出现场景跟 React 类似,React 是前端应对不同场景的一种强有力手段,而 GraphQL 则是后端应对不同需求场景的一次尝试,Web APIs 将会成为 Web App 和 Mobile App 的一个中心点,前端基于后端的 RESTful 服务构建应用,这里面存在太多未知的问题需要探索,这是一个大数据下探索的新起点,也给前端开发者创造了无数的可能

这几年各类网盘,各个云服务商都在抢占市场,有提供图片储存的,有提供 CDN 静态资源缓存的,有提供大文件储存的,也有卖数据库服务的。种类繁多,而归根到底都是,你付钱给我,我提供储存和安全,还提供方便的 SDK 让你获取自己的数据。云服务卖的是一套服务,它是把所有人的数据风险集于一身,用强硬的技术做安全防御。云,赋予了我们无穷的想象空间

三辆马车,我们还差一辆

开发功能对很多人来说是轻松活儿,基本的前端语言加些复杂的特效,实现成本不会很高;即便是搭建一个网站,使用 Node.js 社区中的框架也能够轻松实现。然后极少人会去关注每个功能点的测试,一个项目下来基本看不到测试用例,更不用说会去做监控相关的事情。结果就是,踏过了无数的坑洼之后终于上线了,而后续加功能的时候发现,加了东西就跑不通,新内容影响了之前的逻辑,只好去修复之前的逻辑,修好之后发现更早之前的逻辑又不通了,整个修复过程就像玩多米诺骨牌。

程序开发三板斧:功能、测试和监控。在 github 上可以看到很多程序都加入了持续集成,这是一个好兆头,意味着我们写的程序也越来越健壮,至少贡献给世人使用的程序是健壮的。很多程序的代码覆盖率也达到了 90%+,这些数据都是重视测试的证据

然而,三辆马车,我们最后一辆依然没有开动起来。很多公司都会有自己的 log 平台,每个用户访问页面中的任何一个链接都会将用户信息和访问信息以 log 日志形式收集到 log 平台上,然后通过监控平台或者离线分析的方式,获取业务数据或者技术数据,进行分析和二次开发。这些东西在大公司见的很多,而这方面的东西在前端,尤其是使用 Node.js 做程序开发的前端身上,看到的并不多

最后

2016 年,我觉得技术上的新创造会稍微缓和些,这两年很多人已经被新技术冲击得有些找不着方向了,同一类东西,前者还没学完,后者就开始火爆了,紧接着又是一阵技术的凋零和新技术的出现,这样搞久了也会有一丝的疲倦。而更多的会关注,如何更好地服务多端,如何更大幅度地提升开发体验和用户体验,很多技术都会往性能、往极致这个方向上钻研

写长文真不轻松。写到这里,感觉说的不通透,还有很多想说的,但是个人理解力有限,也难以表达全面。技术的变化很快,今天说过的东西,到了明天就可能过时了。我们猜不透未来,只能把现有的东西好好消化吸收下,留下一个话柄,给读者吧

http://www.barretlee.com/blog/2015/12/10/after-framework-we-gonna-to-hug-data/

with :