前几天看到同事转发的《ReactEurope
Conf 参会感想》,这篇文章讲的react的一些理念感觉有些道理,但我对react最终能很好的实现learn once, write everywhere还是持怀疑态度,毕竟世界是多样的,Apple的iOS(扁平化风格),Google的Android各自有自己的UI规范(Material
Design和AngularJs Material Design
),即使React的理念很好,在别人的地盘上也不一定能弄出多大成果。但在Web前端领域,React作为创新者,必然会推动整个前端开发的进步。
这几年前端开发领域的快速发展,个人感觉主要有几个原因:互联网行业对用户体验的高要求和前端项目的复杂化,导致以前基于jquery框架和插件的前端代码逐渐复杂化,跟不上需求的快速变化,代码膨胀导致维护成为问题,这个是催生新框架的实际需求;前端项目的生命周期相对比较短,一些活动页面可能就用几天,一般的主站页面几个月也会大改版,相当于服务器端,前端的历史包袱少,工程师更可能倾向于使用新技术提供开发效率;互联网的原住民90后开始写代码了,这部分人可能很多是从前端入手开发的,他们更喜欢从国外引入新的框架。这也是React现在很热的一个原因。
我感觉现在React的问题是目标太大,既要做web前端,还要做做iOS原生页面,后面还要搞Android原生UI。虽然FaceBook的研发能力挺强,Virtual DOM的概念很好,有点像UI层的JVM了,可是大家都知道,即使是JVM做了十几年了,还是主要在服务器上用,目前对跨平台的支持也不是特别理想,而UI领域是更加感性和多样化的,对UI原生层的依赖相对更复杂,各移动平台有自己的UI规范,并且差别很大,因此VDOM在移动端的前景不容乐观。就移动端开发来说,React
VDOM相当于在Apple和Google的地盘上另外建立一种开发方式,以后必然会出现利益博弈。 特别是Android平台情况复杂,各种版本,不同的分辨率,各种厂商定制设备,各种定制UI,很怀疑React后面能不能hold住,我估计React Android 10月份跳票的可能性大。
下面说说Flux架构。Flux
是一个Facebook开发的、利用单向数据流实现的应用架构,用于 React。Flux应用有三个主要的部分组成:调度程序、存储和视图(React
组件)。现在的Flux架构只是个概念,缺少官方标准实现,第三方的实现又有点乱,就连我们公司都自己弄了个iFlux架构,相关的框架太多,后面必然会统一,一些Flux框架后面肯定会死掉或合并。
相对于AngularJS,React不是一个完整的前端解决方案,很多地方还需要补充,这就对团队的技术能力提出了要求,而AnguarJS框架相对完善,适合作为整体的前端开发解决方案使用,适合大规模工程化开发。至于AngularJS
2,还是等浏览器能普遍支持ES6的时候再考虑吧。
个人感觉后面Relay会逐渐替代Flux。Relay是Facebook在React.js
Conf(2015年1月)上首次公开的一个新框架,用于为React应用处理数据层问题。在Relay中,每个组件都使用一种叫做GraphQL的查询语句声明对数据的依赖。组件可以使用this.props
访问获取到的数据。开发者可以自由地组合React组件,而Relay负责把不同组件的数据查询语句(原文的query
)集中高效地组织并处理,向组件提供精确粒度的数据(没有多余数据),当数据变化时通知相应组件更新,并在客户端维护一份包含所有数据的数据缓存store
。
最后说下GraphQL。GraphQL是一种用于描述复杂、嵌套的数据依赖的查询语句。它已经在Facebook的原生APP上使用了多年。在服务器端,我们通过配置将GraphQL与底层的数据查询代码映射起来。这层配置使得GraphQL可以访问不同的底层存储系统。Relay使用GraphQL作为数据查询语句,但并不指定GraphQL的具体实现。
我觉得GraphQL是一个很好的想法,可能是这一系列项目中后面最有前途的。GraphQL确实解决了REST
API的一些痛点,特别是在移动网络环境下接口返回太多冗余数据的问题,这个问题在目前移动网络流量费还不够便宜,速度还不够快的情况下很重要。GraphQL的发展前景是看好的,但目前需要完善生态环境,特别是基于Java的实现框架,Android和iOS的客户端支持框架,有了这些东西才能真正推动GraphQL的普及,目前仅有node.js版本是远远不够的,毕竟大多数服务器端项目都不是Node.js的,大多数服务器端工程师也不精通js。在Android客户端,已经有大量支持REST的网络情况框架,例如Spring Android,Google
Volley等。
以上文字只是个人看法,至于是否使用React要根据具体的项目和研发团队情况具体分析。
版权声明:本文为博主原创文章,转载请保留出处http://blog.csdn.net/offbye