你的位置:首页 > 软件开发 > Java > 2015前端生态发展回顾(转)

2015前端生态发展回顾(转)

发布时间:2015-12-30 10:00:24
引用苏宁前端架构师的一个总结作为开篇编程技术及生态发展的三个阶段最初的时候人们忙着补全各种API,代表着他们拥有的东西还很匮乏,需要在语言跟基础设施上继续完善然后就开始各种模式,标志他们做的东西逐渐变大变复杂,需要更好的组织了然后就是各类分层MVC,MVP,MVVM之类,可视化开 ...

2015前端生态发展回顾(转)

引用苏宁前端架构师的一个总结作为开篇

编程技术及生态发展的三个阶段

  • 最初的时候人们忙着补全各种API,代表着他们拥有的东西还很匮乏,需要在语言跟基础设施上继续完善
  • 然后就开始各种模式,标志他们做的东西逐渐变大变复杂,需要更好的组织了
  • 然后就是各类分层MVC,MVP,MVVM之类,可视化开发,自动化测试,团队协同系统等等,说明重视生产效率了,也就是所谓工程化

处在2015年这个时间段来看,前端生态已经进入了第三阶段。看上去好像已经走的挺远了,实则不然。如果再用人类历史上的三次工业革命来类比,前端发展其实不过刚刚迈入了蒸汽机时代,开始逐步用工具来替代过往相当一部分的人肉作业,但是离电气时代的自动化流水线作业还有很长一段路要走。回顾一下2015年前端的生态发展,我大致整理了几个我觉得比较有历史意义的事件。

按时间顺序: 至于我对函数式编程的看法,后面单独阐述。

在我看来,react的优势并不在组件化,组件化的实现方案多种多样。react的优势在于virtual dom及一个几乎构成闭环的强大生态,这归功于Facebook工程师强大的工程能力跟架构能力。virtual dom将应用表现层从浏览器这个基于dom的上下文中抽离出来,通过原生js对象模型的方式使得react具备在任何环境支撑上层表现的能力。上层的渲染引擎可以是canvas、native、服务端甚至是桌面端,只要相应的端提供基于react组件的渲染能力,即可达到一套代码、或者只要很少的改动就能移植到任一终端环境的效果,这个就非常夸张了。react从0.14版本之后便将react-dom抽出来变成一个独立的库,可见react的野心并不局限于浏览器,相反从这点来看,react反而是受到了dom的掣肘。

Angular2 & Vue.js

ng2跟ng1相比是一个完全革命性版本而不是升级版,它是一个为了迎合未来的标准及理念来设计的全新框架,而这些新的理念又无法通过改进ng1.x的方式来实施,所以angular团队做了这么一个看似激进的决策,可以理解成重构已经无法满足需求只能重写了。ng2也采用纯组件化的开发思路,任何单元对于它来说都是组件。同时,ng2里面也引入了一些全新的概念(对于前端而言)来提升框架的性能及设计,例如基于worker的数据检测机制能大幅度提升渲染性能(对应实现是zone.js),基于响应式编程的新的编程模型能更大的改善编码体验(对应实现RxJS)。赶在2015年的尾巴,ng2正式发布beta版,对于angular的这次自我革命是否能成功,还有待后续检验。另外原angular团队中出来的一个成员开发了一个类ng2的框架aurelia,有相当的开发者认为它更配称为ng2,值得关注。

由于阿里在背后的技术实践及支持,Vue.js今年也开始得到越来越多的关注。vue相对于angular1.x的优势在于轻量、易用、更优异的性能及面向组件化的设计,目前发展态势也非常好,是移动端开发的一个重要技术选型之一。

标准 & 语言的变化

现在回顾起来,2015年是很有意义的一年:这一年是Web诞生25岁周年,也是js诞生的20周年。同时又是ES6标准落地的一年。ES6是迄今为止ECMAScript标准最大的变革(如果不算上胎死腹中的ES4的话),带来了一系列令开发者兴奋的新特性。从目前es的进化速度来看,es后面应该会变成一个个的feature发布而不是像以前那样大版本号的方式,所以现在官方也在推荐 ES+年份 这种叫法而不是 ES +版本。

ES2015(ES6) & ES2016(ES7) & TypeScript

6月中ES2015规范正式发布,从ES2015带来的这些革命性的新语法来看,JS从此具备了用于开发大型应用的语言的基本要素:原生的mudule支持、原生的class关键字、更简洁的api及语法糖,更稳定的数据类型。而这些new features中,有几个我认为是会影响整个前端发展进程的:

        Module & Module Loader写过C#的同学应该对这两个关键字很熟悉了,async/await是为了更优雅的异步编程做的一个关键字级别的封装,术语叫协程。ES2016中 async/await 实际是对Generator&Promise的上层封装,几乎同步的写法写异步比Promise更优雅更简单,非常值得期待。

        decorator另外webcomponents将目标对准的是HTML体系下的组件化,这一点跟React比就相对狭隘了(但是这并不表明React把战线拉的那么长就不会有问题)。不过原生支持的跨框架的组件还是有存在的意义的,比如基础组件库,只是在当前来看web components发展还是有点营养不良。期待2016年能有实质上的突破吧。

架构的变化

2015年出现的新的技术及思路,影响最大的就是技术选型及架构了。我们可以从下面几点来看看它对前端架构上都有哪些影响。

组件化

React的风靡使得组件化的开发模式越来越被广大开发者关注。首先要肯定的是,组件化是一个非常值得去做的事情,它在工程上会大大提升项目的可维护性及拓展性,同时会带来一些代码可复用的附加效果。但这里要强调的一点是,组件化的指导策略一定是分治(分而治之)而不是复用,分治的目的是为了使得组件之间解耦跟正交,从而提高可维护性及多人协同开发效率。如果以复用为指导原则那么组件最后一定会发展到一个配置繁杂代码臃肿的状态。如果以组件的形态划分,可以分为两个类型:基础控件和业务组件。基础控件不应包含业务逻辑不然达不到拿来即用的效果,因此它也会表现出可复用的价值,但是根本还是为了提高业务组件的可维护性。至于业务组件,可复用的价值就很低了。

狭义的组件化一般是指标签化,也就是以自定义标签(自定义属性)为核心的机制。这也是我们通常认识的组件。广义的组件化包括对数据逻辑层业务梳理,形成不同层级的能力封装。它不一定是一个自定义语义标签:它可以是一个包含逻辑(js)、样式(css)、模版(html)的功能完备的结构单元,也就是我们常“口口相传”的模块(从术语准确性的角度来看模块这个描述并不合适,应该称之为组件);它也可以是一个单纯的js,比如http组件这种纯逻辑单元。严格从概念上来讲,css跟html是不具备单独/组合成一个组件的,它们不具备描述逻辑的能力(非图灵完备)。从这个层面来看,全组件化是没有任何问题及疑义的。

是否需要全组件化

代表框架是React。React+Flux体系下,它提倡尽可能将页面作细粒度的组件拆分,组件的数据全部由父级组件通过props传递而来。这本身是一件非常有价值的事情,能有效的确保应用状态的稳定及可预测性,但是应用一旦复杂庞大起来,组件树变得“枝繁叶茂”导致叶子节点层级过深,当出现数据问题时,我们必须一层层的回溯来定位bug。而且组件树过于庞大也会增加组件之间的通讯负担。从狭义的组件来看,我对全组件化是存怀疑态度的,工程上的成本太高是最大的问题,而且大部分开发者很难拿捏合适的组件粒度,容易出现过细/过粗的拆分。很多场景其实并不适合实现成狭义上的组件,它以零散的模板的方式存在更合适。但是如果从广义的组件来看,全组件的意义是很大的,我们需要通过拆分页面逻辑区块的方式实现程序的解耦,从而提升应用的可维护性。

综合来看,我觉得工程上更具可行的全组件化方案应该是:细粒度的基础组件库 + 粗粒度的模板/组件。

工程化

工程化是近年前端提到最多的问题之一,而且个人认为是当前前端发展阶段最有价值的问题,也是前端开发通往工业化时代的必经之路。这里不赘述,有兴趣的同学看我前阵子整理的一篇文章前端工程化知识点回顾

应用架构层 MVVM & Flux

MVVM想必大部分前端都耳熟能详了,代表框架是angular、vue、avalon。angular在1.2版本之后加入了controllerAs语法,使得controller可以变成一个真正意义上的VM,angular整个架构也才真正能称之为严格的MVVM(之前只能说是带有双向绑定的MVC/MVP)。Flux是facebook随React一并推出的新的(准确来说其实是改进的,并非原创)架构模型,核心概念是单向数据流。Flux实质上就是一个演进版的中介者模式,不同的是它同时包装了action、store、dispatcher、view等概念。关于Flux对应用分层、数据在不同层之间只能单向流转的方式我是很赞成的。应用的分层在业务稍复杂的应用中都是很有必要的,它更利于应用的伸缩及拓展,副作用是会带来一定的复杂度(在我看来这点复杂度根本就可以忽略不计)。

今年被黑的最多的前端主流框架莫过于angular了。老实讲前端圈真的挺善变的,去年各种大会都在分享angular黑jquery,今年就变成了都在分享react黑angular了。黑的点大致有三:

MVVM在富表格型(自造的词2015前端生态发展回顾(转))应用开发效率上是高于Flux的,典型的就是一些后台管控平台。而且最重要的是,MVVM跟Flux并不互斥,我们在MVVM中照样可以引入Flux中的一些机制从而确保应用状态的稳定。很多时候我们对于框架/架构的孰优孰劣的争论是没意义的,抛开业务场景谈解决方案都是耍流氓。

业务数据层 Relay & falcor

这一层对大部分前端来说可能是比较新的概念,其实我们可以这样理解:在一个完整的应用中,业务数据层指的就是数据来源,在angular体系中可以等同于ngResource模块(准确来说应该是$http)。Relay是f家推出的在react上应用GraphQL的框架,它的大致思路是:前端通过在应用中定义一系列的schema来声明需要的接口数据结构,后端配合GraphQL引擎返回相应的数据。整个事情对于前端来说意义简直是跨时代的,工业化典范!不仅能极大提升前后端协同的开发效率,还能增加前端对于应用完整的掌控力。但是目前来看问题就是实施过于复杂,而且还得后端服务支持,工程成本太高,这一点上Meteor显然做的更好。falcor则是Netflix出品的一个数据拉取库,核心理念是单一数据源,跟Redux的单store概念一致。用法跟Realy类似,也需要前端定义数据schema。业务数据层是前端应用中比较新的概念,它的多元化主要会影响到应用的架构设计,这里不细讲后面再来说。

新的编程范式

函数式编程(FP)

函数式编程(functional programming)是近年比较火爆的一个编程范式,FP基于lambda演算,与以图灵机为基础的指令式编程(Java、C++)有着明显的差异。lambda演算更关注输入输出,更符合自然行为场景,所以看上去更适合事件驱动的web体系,这点我也认同。但问题是,太多开发者看到redux那么火爆就急着学redux用js去玩函数式,我觉得这个有待商榷。js作为一个以基于函数(scheme,父亲)跟基于对象(Self,母亲)的编程语言为蓝本设计然后语法又靠近Java(隔壁老王)的“混血”语言,你非得用它去写函数式,是不是过于一厢情愿?尤其是在现在浏览器还不支持尾调用优化的情况下,你让那激增的调用栈可如何是好2015前端生态发展回顾(转)如果你确实钟情于函数式,可以去玩玩那些更functional的语言(Haskell、Clojure等),而不是从js入手。最近看到一个老外关于js的函数式编程的看法,最后一句总结很精辟:Never forget that javascript hate you.2015前端生态发展回顾(转)

函数式响应型编程(FRP)

函数式响应型编程(functional reactive programming)不是一个新概念,但也不过是近两年才引入到前端领域的,代表类库就是ng2在用的rxjs。FRP关注的是事件及对应的数据流,你可以把它看作是一个基于事件总线(event bus)的观察者模式,它主要适用于以GUI为核心的交互软件中。但FRP最大的困难之处在于,如果你想使用这样的编程范式,那么你的整个系统必须以reactive为中心来规划。目前微软维护的ReactiveX项目已经有各种语言的实现版本,有兴趣的同学可以去了解下。

工具链的变化

去年最主流的前端构建工具还是grunt&gulp,2015年随着react的崛起和web标准的快速推进,一切又有了新的变化。

webpack & browserify & jspm

webpack跟browserify本质上都是module bundler,差异点在于webpack提供更强大的loader机制让其更变得更加灵活。当然,webpack的流行自然还是离不开背后的react跟facebook(可见有个强大的干爹多么重要)。但是从现在HTTP/2标准的应用及实施进展来看,webpack/browserify这种基于bundle的打包工具也面临着被历史车轮碾过的危机,相对的基于module loader的jspm反而更具前景(虽然现在使用前两者的开发者都多于jspm)。

PostCSS & cssnext

PostCSS作为新一代的css处理器大有取Sass/Less而代之的趋势,Bootstrap v5也有着基于PostCSS去开发的计划。但从本质来讲它又不算一个处理器,它更像是一个插件平台,能通过配置各种插件从而实现预处理器跟后处理器的效果。这种理想的方式当然是完全正确的方向,但是目前来看它对 开发者/架构师 的要求还是太高,工业级别上一套带有约束性的框架还是有相当的需求的(特别是当团队开发者的水平良莠不齐时。当然我觉得更正确的方式是流程上有一套完整的自动化方案用于确保团队提交的代码质量,只是目前基于动态分析的代码质量检测工具还没有出现,而且估计很长一段时间内都不会有)。虽然美好但是组合的方式也不是没有问题,各种五花八门的搭配容易造成社区的分化跟内耗,一定程度上不利于整个生态圈的发展。

近年前端生态的野蛮发展影响最大的应该就是新产品的技术选型了,乱花迷人眼,我们很难设计出一套适应大部分场景、而且短时间内不会被淘汰的架构。前端的变化太快通常会导致一些技术决策的反复,今天的最佳实践很可能明天就被视为反模式。难道最合适的态度是各种保留各种观望,以不变应万变?在这一点上即使如我这般在技术上一向激进的人都有点畏手畏脚了。那句话怎么说的来着?从来没有哪个圈子像今天的前端一样混乱又欣欣向荣了。有人说2015年或许是大前端时代的元年,目前看来,如果不是2015,那么它也一定会是2016年。

最后引用计子winter的一句话作为结语吧:

前端一直是一个变化很快的职能,它太年轻,年轻意味着可能性和机会,也意味着不成熟和痛苦。我经常担心的事情就是,很可能走到最后,我们会发现,我们做了很多,却还是一无所获。所幸至今回顾,每年还是总有点不同,也算给行业贡献了些经验值吧。

 

转自:https://github.com/kuitos/kuitos.github.io/issues/32

 


原标题:2015前端生态发展回顾(转)

关键词:前端

*特别声明:以上内容来自于网络收集,著作权属原作者所有,如有侵权,请联系我们: admin#shaoqun.com (#换成@)。