前端三大框架vue,angular,react大杂烩

摘要:从angular的诞生独步天下,到现在三大框架平分天下,基本形势已经趋于稳定。每一个框架从诞生到受欢迎,都有其特定的原因和背景。不同的开发者选择时,也是依据于其特定情景下的原因和背景。

一、为什么前端会被vue,angular,react瓜分?

   不知道大家有没有发现,这三个框架除了都是前端框架之外,还大有搞基的成分存在。注意他们三个的名字,分别以v,a,r 开头,我这么一说,你是不是忽然间就想到了什么。哈哈,正是如此,将他们组合起来不就是javascript中无处不在的鬼东西么?var (当然纯属于开玩笑的)

   var关键字,是js的变量声明关键字,可以说,它是js得以运行的核心关键字,因为要想一段代码运行,首先得有各种变量和逻辑判断做支撑,而在es6之前,js能声明变量的,就它一个。这似乎也是暗示了vue,angularjs,react这三个框架的不可替代性啊,也不知道当时这三个框架的作者起名时的想表达的特殊含义是什么,但偏偏就刚好对上了。当然,反过来说,也有可能是起var关键字的这个人,当时考虑得面面俱到。虽然看上去是巧合,但我总感觉这之中总有一种道不明的关系。虽然vue是后起之秀,但就目前的受欢迎程度来说,好像就是这个顺序,至少国内现在肯定是这样的。

   有了这三个框架之后,我们告别了以前jquery面条式的代码,也摆脱了到处操作dom元素带来的繁琐,模块业务划分更清晰。这三个框架的出现,不仅让前端的工作得以高效,也让后端省了不少事,比如,路由控制。在以前,干后端是对决要比前端高一个档次的,但现在,完全不一样了。如果有一个牛逼的前端,后端差不多只需要会增删改查的基本业务就能完全搞定一个web应用。当然,这里只是针对代码部分,搭建服务器之类的另当别论。

二、三大框架的优缺点

  我们主要从数据流、视图渲染、性能与优化、模块化组件化等四个方面来作比较

1、数据流

  Angular 使用双向绑定即:界面的操作能实时反映到数据,数据的变更能实时展现到界面。

1.1、它的实现原理:

   $scope变量中使用脏值检查来实现。像ember.js是基于setter,getter的观测机制,

   $scope.$watch函数,监视一个变量的变化。函数有三参数,”要观察什么”,”在变化时要发生什么”,以及你要监视的是一个变量还是一个对象。

   使用ng-model时,你可以使用双向数据绑定。

   使用$scope.$watch(视图到模型)以及$scope.$apply(模型到视图),还有$scope.$digest

   调用$scope.$watch时只为它传递了一个参数,无论作用域中的什么东西发生了变化,这个函数都会被调用。在ng-model中,这个函数被用来检查模型和视图有没有同步,如果没有同步,它将会使用新值来更新模型数据。

1.2、双向绑定的三个重要方法:

$scope.$apply()

$scope.$digest()

$scope.$watch()

   在angularjs双向绑定中,有2个很重要的概念叫做dirty check,digest loop,dirty check(脏检测)是用来检查绑定的scope中的对象的状态的,例如,在js里创建了一个对象,并且把这个对象绑定在scope下,这样这个对象就处于digest loop中,loop通过遍历这些对象来发现他们是否改变,如果改变就会调用相应的处理方法来实现双向绑定

   Vue 也支持双向绑定,默认为单向绑定,数据从父组件单向传给子组件。在大型应用中使用单向绑定让数据流易于理解。

1.3、脏检测的利弊

   和ember.js等技术的getter/setter观测机制相比(优):

   getter/setter当每次对DOM产生变更,它都要修改DOM树的结构,性能影响大,Angular会把批量操作延时到一次更新,性能相对较好。

   和Vue相比(劣):

   Vue.js 有更好的性能,并且非常非常容易优化,因为它不使用脏检查。Angular,当 watcher 越来越多时会变得越来越慢,因为作用域内的每一次变化,所有 watcher 都要重新计算。并且,如果一些 watcher 触发另一个更新,脏检查循环(digest cycle)可能要运行多次。 Angular 用户常常要使用深奥的技术,以解决脏检查循环的问题。有时没有简单的办法来优化有大量 watcher 的作用域。Vue.js 则根本没有这个问题,因为它使用基于依赖追踪的观察系统并且异步列队更新,所有的数据变化都是独立地触发,除非它们之间有明确的依赖关系。唯一需要做的优化是在 v-for 上使用 track-by。

   React-单向数据流

   MVVM流的Angular和Vue,都是通过类似模板的语法,描述界面状态与数据的绑定关系,然后通过内部转换,把这个结构建立起来,当界面发生变化的时候,按照配置规则去更新相应的数据,然后,再根据配置好的规则去,从数据更新界面状态。

   React推崇的是函数式编程和单向数据流:给定原始界面(或数据),施加一个变化,就能推导出另外一个状态(界面或者数据的更新)。

   React和Vue都可以配合Redux来管理状态数据。

2、视图渲染

Angular1

   AngularJS的工作原理是:HTML模板将会被浏览器解析到DOM中, DOM结构成为AngularJS编译器的输入。AngularJS将会遍历DOM模板, 来生成相应的NG指令,所有的指令都负责针对view(即HTML中的ng-model)来设置数据绑定。因此, NG框架是在DOM加载完成之后, 才开始起作用的。

React

   React 的渲染建立在 Virtual DOM 上——一种在内存中描述 DOM 树状态的数据结构。当状态发生变化时,React 重新渲染 Virtual DOM,比较计算之后给真实 DOM 打补丁。

Virtual DOM:

   提供了函数式的方法描述视图,它不使用数据观察机制,每次更新都会重新渲染整个应用,因此从定义上保证了视图与数据的同步。它也开辟了 JavaScript 同构应用的可能性。

   在超大量数据的首屏渲染速度上,React 有一定优势,因为Vue 的渲染机制启动时候要做的工作比较多,而且React 支持服务端渲染。React 的Virtual DOM 也需要优化。复杂的应用里可以选择 1. 手动添加shouldComponentUpdate 来避免不需要的 vdom re-render;2. Components 尽可能都用 pureRenderMixin,然后采用 Flux 结构 + Immutable.js。其实也不是那么简单的。相比之下,Vue由于采用依赖追踪,默认就是优化状态:动了多少数据,就触发多少更新,不多也不少。React 和 Angular 2 都有服务端渲染和原生渲染的功能。Vue.js不使用 Virtual DOM 而是使用真实 DOM 作为模板,数据绑定到真实节点。Vue.js 的应用环境必须提供 DOM。Vue.js 有时性能会比 React 好,而且几乎不用手工优化。

3、性能与优化

   性能方面,这几个主流框架都应该可以轻松应付大部分常见场景的性能需求,区别在于可优化性和优化对于开发体验的影响。Vue 的话需要加好 track-by 。React 需要 shouldComponentUpdate 或者全面 Immutable,Angular 2 需要手动指定 change detection strategy。从整体趋势上来说,浏览器和手机还会越变越快,框架本身的渲染性能在整个前端性能优化体系中,会渐渐淡化,更多的优化点还是在构建方式、缓存、图片加载、网络链路、HTTP/2 等方面

4、模块化与组件

Angular1 -> Angular2

   Angular1使用依赖注入来解决模块之间的依赖问题,模块几乎都依赖于注入容器以及其他相关功能。不是异步加载的,根据依赖列出第一次加载所需的所有依赖。

   可以配合类似于Require.js来实现异步加载,懒加载(按需加载)则是借助于 ocLazyLoad 方式的解决方案,但是理想情况下应该是本地框架会更易懂。

   Angular2使用ES6的module来定义模块,也考虑了动态加载的需求。

Vue

   Vue中指令和组件分得更清晰。指令只封装 DOM 操作,而组件代表一个自给自足的独立单元 —— 有自己的视图和数据逻辑。在 Angular1 中两者有不少相混的地方

React

一个 React 应用就是构建在 React 组件之上的。

   组件有两个核心概念:props,state。 一个组件就是通过这两个属性的值在 render 方法里面生成这个组件对应的 HTML 结构。

   传统的 MVC 是将模板放在其他地方,比如 script 标签或者模板文件,再在 JS 中通过某种手段引用模板。按这种思路,想想多少次我们面对四处分散的模板片段不知所措?纠结模板引擎,纠结模板存放位置,纠结如何引用模板。

   React 认为组件才是王道,而组件是和模板紧密关联的,组件模板和组件逻辑分离让问题复杂化了。所以就有了 JSX 这种语法,就是为了把 HTML 模板直接嵌入到 JS 代码里面,这样就做到了模板和组件关联,但是 JS 不支持这种包含 HTML 的语法,所以需要通过工具将 JSX 编译输出成 JS 代码才能使用(可以进行跨平台开发的依据,通过不同的解释器解释成不同平台上运行的代码,由此可以有RN和React开发桌面客户端)。

三、我们如何选?

   年轻的程序员都是好奇的猫,玩过一个又一个的前端框架。从毛球上弄出一条条的线,玩啊玩,最后这一个个的框架在脑子里搅浆糊。有太多的选择,就是一件麻烦的事;没有选择时,就是一件更麻烦的事;有唯一的选择时,事情就会变得超级简单。

   当一个程序员学了某个最新的框架之后,通常来说这个框架有着更多的优点,这个时候最容易出现的想法就是替换现有的框架,科室现有的框架并没有什么大的问题,并且评估不充分的时候,新的框架则会有更多的风险。

   所以最后总结一下:技术选型没有银弹,没有一个框架能够解决所有的问题。这时,为了更好的考量不同的因素,你需要列出重要的象限,如开发效率,团队喜好,开发周期等时机情况选择哪个框架最合适你当前的团队和项目。

  • 发表于:
  • 原文链接:http://kuaibao.qq.com/s/20171228A118N100?refer=cp_1026

扫码关注云+社区