理性看待前端框架（库）之争（React Vs Vue）

Posted 2021-04-05 CFgeek

背景

这两年来，对于前端框架之争，愈演愈烈，不论知乎、Q群或者微信群，甚至在公司内部都会引起激烈的争论，争论点其实都围绕着框架各自的设计细节之争。其实很容易理解，程序员比较注重开发体验，开发体验越好，必然会引起大家的关注和喜爱。特别是国内 Vue 和 React 之争，导致整个前端技术圈的氛围变得越来越紧张。为此，就着这波势，咱们理性的通过不同的技术角度和业务场景分析 Vue 和 React之间的差异。

技术分析

首先我们从技术选型的角度进行分析，技术的选型需要通过业务场景、团队现状、框架完整性（稳定性、性能和生态）这几方面开始入手做分析，本文仅讨论 Vue和React两个库技术比较情况。

1、业务场景：

类型	To B（企业级）	To C （用户级）
业务	CRM/ERP/供应链/OA/后台管理	电商/游戏/团购/P2P
场景	票据表单、数据报表、可视化图表	营销、活动、专题、多终端、动画、游戏、内嵌页
特征	复杂交互表单、大数据量报表、可编辑大数据量表格、复杂的图形化展示、组件可复用程度高	轻量级页面、快速响应、变化快、追求小体积、组件可复用程度偏弱、追求首屏速度（服务端渲染）、追求启动速度快、跨终端代码复用、CSS动画

我们将常见的业务类型分为企业级和用户级，基本上能够涵盖我们常用的大部分业务场景。这些场景，会存在一部分重叠的特征，比如用户级场景可能也会有复杂的图形化展示，随着业务的推进，用户级部分场景，也会形成一些可复用的组件。企业级也会存在跨终端代码复用，比如初创公司，或者部分快速迭代的项目。接下来我们将介绍在这些场景Vue和React现有的解决方案以及生态。

2、生态体系：

	Vue	React
UI  框架	iView  / Element UI	Ant  Design
表单处理	vee-validate	Redux Form  / React Form
可视化图表	v-charts  / vue-chartjs	Recharts  / BigCharts
数据表格	vue  data-tables	React  Datasheet
脚手架	vue-cli	create-react-app
路由	vue-router	react-router
数据管理	vuex	dva  / redux / mobox / saga
前后端同构	nuxtjs	nextjs
移动端跨平台	weex	react-native
交互动画	vue-animation	react-motion
CSS  IN JS	.vue模板	styled-components  等数十款
无限滚动	vue-infinite-scroll	react-infinite

我们发现Vue / React的生态基本上都能够满足我们实际的业务场景需求，Vue相对于React生态成熟度偏弱一些。同时我们发现，React 生态圈子创新输血能力很强，而Vue生态圈子更多是基于借鉴 + 微创新的模式。企业级应用上，And Design为我们提供更全面的UI框架方案，同时在表单处理上， ReduxForm提供了更复杂的表单处理功能。可视化方面，其实一般情况下eChart / hChart / D3 基本上已经能够满足我们的需求，而提供的各自框架的可视化版本，Recharts / BigCharts都有相对v-charts有更丰富的图形展示。

两者脚手架和前后端同构提供更快更简洁方式构建项目，Vue提供以项目模板的方式构建项目，React则可以自由组合自己想要的模块、组件和库，可以根据Create-React-App推荐的组件和库来构建项目，由简单到复杂的过程。

3、性能对比：

指标	React（ms）	Vue（ms）
加载页面后创建1000行的持续时间	169.2	187.6
更新表格的所有1000行（5次热身迭代）的持续时间	161.8	165.2
需要更新10行的表格每10行的文本（5次热身迭代）	93.6	168.1
持续时间，突出显示一行以响应该行的点击（有5次热身迭代）	12.4	9.8
在1K表上交换2行的时间（有5次热身迭代）	19.6	21.8
删除一行的时间（有5次热身迭代）	51.5	52.5
创建10,000行的持续时间	2033.7	1521.4
在10,000行的表上添加1000行的持续时间	271.8	338.4
清除填满10.000行的表格	224.4	240.9
加载，解析和启动的时间	49.4	48.4
Slowdown  = Duration / Fastest	1.26	1.33

以上是基于React 16.1.0 和Vue 2.5.3（Keyed）进行的性能基准测试，整体来看，React略弱一点点，对于用户体验来讲，并不会有感知（动画除外）。React 在创建1w行这样的99.9%不会出现的场景，略慢于Vue 0.5s左右。而更新表格10行文本，Vue却比React慢80%。加载，解析和启动时间仅仅只有1ms的差距，而实际上浏览器线程是会受到OS的影响会有一定偏差，所以我认为性能上，两者其实不相上下，而React在性能表现中更稳定。基准测试来源于：http://www.stefankrause.net/js-frameworks-benchmark7/table.html

同时我们通过 Vue 官方过去的对比其他框架的性能基准测试，进行了性能测试对比（PC）

指标	React 16（ms）	Vue 2.3（ms）
最快	8	36
中位数	8	56
平均值	11.87	59.93
最慢	129	235

同时我们继续在 ios 10 safari（iPhone 6），看看测试的结果

指标	React 16（ms）	Vue 2.3（ms）
最快	29	51
中位数	33	88
平均值	39.8	83.65
最慢	193	206

从上面性能测试数据中，无论在移动端或者是PC端，React 16都表现出优异的性能，这取决于React 16最新的Fiber算法，让我们能够尽可能地在60FPS下平滑的操作页面DOM。而实际上这些差异对于用户来说，在肉眼上不会有感知。而在动画方面，React 16推出之际，就提供了一个满二叉树的更新动画，效果非常平滑。

4、性能优化 ：React should  Component Update Vs Vue Auto Watcher

React 提供 Should Component Update 来处理 5-10% 场景下（例如超长列表下复杂数据结构）的性能问题，避免在数据没有发生变化的时候，重复渲染（re-render）组件。90%-95%+场景下，我们不需要使用它，甚至通过无状态组件（组件即函数）的方式简单地获得45%以上的性能提升。（具体可以查这篇文章：https://medium.com/missive-app/45-faster-react-functional-components-now-3509a668e69f）

我们在使用 Should Component Update时，往往需要遍平化数据结构或者根据关键字段来做对比，来避免组件的重复渲染（re-render）。除此之外还可以通过增加子组件的方式，来减少对比的方式，即子组件对应一层数据结构数据。这些方式相对来说略有点繁琐，但是在以往的业务场景中往往用得较少。即未出现性能瓶颈的时候，也没有优化的必要。而组件因为使用Should Component Update，不进行re-rendner，自然也会导致其子组件无法更新，这个是需要注意的。

Vue 自动遍历（收集）所有需要监听的对象属性，内部自动追踪它们依赖的变化。同时对数组的常用函数自动追踪，来保证对复杂数据结构的数组进行操作时智能跟踪。而实际上我们在某些少量的场景（大型数据表格绑定，监听数量过多的情况），就需要绕开自动收集依赖的行为。而事实上，Vue 并没有通过索引检测赋值的手段，仍然需要手动去更新。（具体可以参考：https://blog.cloudboost.io/reactivity-in-vue-js-2-vs-vue-js-3-dcdd0728dcdf）

5、体积对比

React 16 （34.8kb gzipped）和 Vue （20.9k gzipped）比略大一些，在实际开发中，会依赖其它生态（React-Router或者Vue-Router等）的情况下，体积可能会不分上下。而编写业务代码的时候，Vue 提供了对业务代码编译时优化，来降低体积，而在实际业务代码中，并不一定能够达到理想的体积减小的效果。而我们应该更多的是聚焦到业务代码的体积成本中，而实际上CSS/HTML/JS等业务代码，也不会完全因为使用了不同的框架，体积有很大的差异。我们在移动端弱网环境开发中，RTT时间（往返握手时间）往往是整个应用JS下载耗时最大的一部分。我们通过代码分割（按需加载）和预加载用户路径上的JS资源来保证用户响应的速度。或者通过首屏渲染来达到目标。

6、其它对比

当然还有通过服务端渲染提升页面渲染速度的 SSR，Vue 会更快一些，但是同时因为使用了Node JS，非常消耗CPU资源，只能通过水平扩展服务器，来保证高并发时首屏渲染性能。当然我们也可能通过对首屏的组件预编译成 doT.JS等Node JS模板，这样能够让渲染速度，最低能达到 0 - 2ms。但事实上遇到复杂的页面结构，我们需要付出相对较高的开发成本来保证效果。

技术选型的核心点

熟悉或偏好：无论是React、Vue，还是 Angular，根据自身能力选择自己熟悉或偏好的库，才能够最小降低的业务开发的成本，如果是团队的前端负责人或架构师，这一点往往很重要。

业务现状：无论是基于 React 或者是 Vue，更多应该考虑目前已有项目的现状，使用了何种库或者框架生态，更多的是避免重构的成本。如果使用的是JQ/Angular，相对来说，更需要考虑的是团队现状，以及如何编写胶水代码，在不影响原有的项目功能前提下，使用新框架进行业务开发。

团队现状：考虑现有团队成员大部分掌握或者能够上手的技能为主，若成员大部分基于Vue，而架构师基于React，则对于架构师来说会有成本，需要考虑培训成本。事实上，在有前端架构师的团队，React 和 Vue 上手成本基本差不多，只是因为React本身文档是面向有一定JS前端开发经验的，而Vue文档则更多是让前端小白在不需要太多JS前端开发经验上快速上手。

版本升级与生态：版本的升级，往往影响我们业务代码的状态，能否在最小代价和成本升级库（框架），以及升级带来相对应生态库可用性大打折扣，所以在考虑使用何种框架时，要考虑迭代的成本。React 在升级，往往会隔代迁移，即提供API变化，会预留一个版本做API兼容过渡（警告性提醒），同时API变化数量往往控制在极少量的情况（本身React Api并不多）。而 Vue 往往升级，会带来数十个API变化，不会采用隔代迁移的策略，但通常会对上一版本做一个周期的维护，来降低API变化的成本，据了解 Vue 3，将采用Proxy的策略追踪依赖，会不考虑兼容 IE 11的版本，升级会对移动端用户兼容性带来一定的成本和风险。在选择使用何种库或者框架，需要谨慎地去考虑这个问题。

以上仅仅是我粗浅的见解，不足之处，我们可以共同讨论，还有很多相应对比的细节，我就不再多说了。我认为没有任何框架或库是能够一直长青，只有不断地学习和了解它们，知道它们的优点或者缺点，不去站队，根据实际的业务现状、团队现状态以及自身的情况去选择适合自己的库或者框架。回归初心，我们的技术选型是为实现业务，保证项目迭代快速进行。

莫汝航    前端架构师

7年前端开发经验，曾服务过小米、百度和金山西山居等企业。目前专注于大前端技术领域，在电商、游戏、ERP、支付和彩票等行业有相关项目开发经验，同时也是位撩妹高手！