乐趣区

关于react.js:京东云开发者|关于React-和-Vue-该用哪个我真的栓Q

一、前言:我全都要

面对当今前端界两座大山一样的支流框架,React 和 Vue,置信很多小伙伴都或多或少都产生过这样疑难,而这样的问题也往往很让人头疼和当机立断:

  1. 业务场景中是不是团队用什么我就用什么?
  2. 如果抉择了其中一个应用,那为什么不必另一个?
  3. 这两个框架各有什么长处和无奈解决的问题?
  4. 最新版本的 Vue3 曾经出了一段时间了,我要不要做组内第一个吃螃蟹的壮士?
  5. 我该根据什么样的因素决定应用哪个技术栈?

以上问题如果想不明确,很容易产生一个“算了不想了真麻烦,还是随大流好了,至多不会出错”的答案,其实种种疑难都指向了一个终极问题,那就是对于 技术栈的选型
而技术栈抉择的适合与否,往往对我的项目后续的开发有着极大的影响,甚至关系到业务落地的效率和成果。仅仅掌握业务逻辑的开发,曾经齐全不能满足集体倒退了,就好比一门武林绝学,招式用的再熟,也须要心法辅助,所以也就引出了本文的主题:

  1. 旨在帮忙那些对技术栈抉择艰难症的同学,并对 React 和 Vue 产生肯定的认知
  2. 同时也适宜那些只理解繁多技术栈的小伙伴,能够拓展一下对不同框架的了解

二、注释:到底要啥

本文不会从侧面答复下面列出的问题,技术栈的抉择往往要根据现实情况从多方面思考,所以我也将从以下几个方面别离论述观点,各位读者能够联合本身状况和以下观点,决定 React 和 Vue 到底要用哪一个。而其实对于技术选型,很容易代入本人的主观意识,“好和坏”在同样优良的框架背后更像是一种自我感触,但笔者会尽量从主观的角度去论述,如果过程中观点呈现抵触或有误,欢送与我交换、斧正。

  • 选型对象阐明
  • 团队的适用性
  • 兼容性要求
  • 应用层面比照
  • 周边配套
  • 跨端解决
  • 设计思路
  • 性能比照
  • 心智模型
  • 社区生态
  • 开源代码许可协定

1. 选型对象阐明

比照对象:React(hooks 版本)、Vue2、Vue3

对于比照对象的抉择:

  • React 有函数式组件的和类组件两种写法,鉴于 class 写法较老,且这种写法 不利于构建工具的 Tree-shaking,可能导致构建产物体积减少,而函数式组件的hooks 写法更合乎将来的潮流,所以类组件在此也不做具体的介绍,只选取函数式组件写法的 React 作为比照对象。
  • Vue2 相较 Vue3 版本而言牢牢占据着大部分 Vue 开发者的视线,然而因为 Vue 官网曾经把 Vue3 作为默认的版本,所以在此同时把 Vue2 和 Vue3 作为比照对象。
  • 比照的内容不会波及到具体的某个 API 的实现,也不会解说大篇幅干涩的源码,过于具体的内容不是本文的重点,作为技术选型要从整体登程去思考。

2. 团队的适用性

在这方面,其实选哪个框架取决于团队全体成员

  • 历史起因:如果你是以开发者的身份刚入职到一个新的环境,并且接手的是一个成熟的我的项目,处于失常迭代或者保护周期,那千万不要想着颠覆团队已有技术栈,技术栈切换就相当于重构
    而这种重构面临的首要影响就是投入和产出不成正比,置信文章的读者大多也都是扑在各个业务一线上,对业务方来说,采纳什么样的技术去实现他们并不关怀,并且切换技术栈带来的危险、开发人力和测试回归的老本都难以评估,除非带来微小价值,否则这也是与咱们单干的上下游都难以承受的。
  • 团队习惯:如果你是我的项目负责人,在抛开对框架自身进行比照的同时,要思考的是团队成员对技术栈的相熟水平,在大多数人都对某一项技术栈相熟、而对另一项技术理解不深的状况下,那更为相熟的技术栈带来的人效和产出品质,显然能帮忙业务疾速验证和试错。

留神 :不相熟某项技术,绝不能成为不应用这项技术的托词,从集体晋升的角度思考,学习新的技术栈能够帮忙咱们裁减思路和视线,如果要做的 新我的项目 周期不缓和,也预留了短缺的工夫,那么新的技术显然能够作为备选项之一。

3. 兼容性要求

  • PC 端:React 和 Vue 均不反对 IE8,对于个别浏览器兼容模式应用 IE 内核也可能是不反对的,具体要看应用的内核版本(IE 浏览器几乎是前端界的噩梦),其余浏览器下能够放心大胆地应用了。
  • H5 端:React 和 Vue 2.x 均能应用。

留神:在挪动端对于想要尝鲜 Vue 3.x 版本的同学来说要关注一下,Vue 3.x 依赖收集是应用 Proxy 这个 API,而 Proxy 在 IOS 端最低反对 IOS10 版本,并且因为这个 API 具备更底层的对象监听能力,导致 polyfill 无奈齐全兼容,已实现的 polyfill 都是基于 Object.defineProperty,并不能残缺反对 Proxy 所有个性(比方数组长度的监测),所以如果业务环境对 IOS9 有兼容需要的状况下,就不要尝试了。

4. 应用层面比照

框架引入

    • React 和 Vue 都是渐进式框架,反对 script 标签间接应用,也反对在工程中通过模块化形式引入应用。

Jsx VS Template

    • React:
      采纳的 Jsx 在写法上更为 灵便多变,属于在 Js 中减少了 HTML 语法,组件的实现思路是All in Js,开发过程中领有 Js 残缺的生态。同时开发工具对 JSX 的反对相比于现有可用的其余 Vue 模板也比拟先进 (比方,linting、类型查看、编辑器的主动实现)。
    • Vue:
      整体思路是 Template 模板语法,跟 Jsx 相比,它是在 HTML 中减少了对局部 Js 语法的反对,在灵便度上不如 Jsx,实质是模板语法无奈穷举所有 Js 能力,所以笔者认为 Vue 外部应用的 slot、directive 等,也恰好是对模板语法不够灵便所做出的一种补充,使模板语法也能实现跟 Jsx 同样的事件。
      模板语法也有长处,它 更靠近原生 HTML,对于新手上手更敌对 ,并且在 Vue3 中,它从模版层面进行动态剖析,对 动态模版做标记,从而晋升 diff 的效率
      值得一提的是,与 React 一样,Vue 在技术上也反对 render 函数和 Jsx,但只是不是默认的而已。

那么你可能会有疑难,为什么 Template 不去适配所有的 Js 语法?这里举一个例子:Taro

Taro1.x 和 Taro2.x 采纳了穷举所有 Jsx 语法的形式,去生成不同平台的代码,导致每次 Jsx 或 Js 语法有更新,这两个版本的 Taro 编译器都要同步去做适配,这是一种重编译时的计划,对 Jsx 的反对其实十分苦楚,所以 Taro3 索性采取了重运行时、轻编译时的重构,以取得编译器对 Jsx 更有好的反对。
并且还有另一个起因是,咱们如果 Template 反对了所有 Js 能力,那么势必又导致了 Template 语法变得复杂,也可能和本来对立的 Ecma 标准割裂(层出不穷的小程序就是一个典型的例子,相当于标准之中又出标准,生态之外再造生态),造成了学习成本增加和惨重的编译器。

    • 共性 也是有的,都是 DSL,对底层而言,尽管两者采纳了不一样的形式实现,但最终都会被编译为 渲染函数 去执行。
    • 下图是 Jsx 语法示例:
    • 下图是 Template 语法示例:

SFC

    • HTML:React 是 Jsx,Vue 是默认的 Template,在这里不在赘述区别,同时须要指出的是,Vue3 相较 Vue2 而言,Template 下能够容许存在 多个根节点,能够缩小一些不必要的 DOM 层级。
    • JS:React 组件自身就是 JS 文件,模式采纳函数组件和类组件,编程范式上更贴近面向对象 + 官网推崇的函数式。Vue2 组件是 Options Api,通过一个个配置项去实现生命周期、状态申明和逻辑开发。Vue3 对于局部逻辑解决和 Vue2 有很大区别,setup 模式下,曾经和 React越来越趋同 了,编程范式是面向过程 + 函数式,官网命名为 Composition Api,能够使同一个性能逻辑更加集中。
    • CSS:React 的 CSS 应用形式是间接通过 Import 导入,Vue 文件中有专门解决款式的 Style 标签,值得一提的是,Vue3 内置状态驱动的动静 CSS,具体可查看官网文档 https://cn.vuejs.org/api/sfc-…。
    • 其余思考:React 的函数式组件和 Vue3Composition Api,在 ESM 模块标准下对Tree-shaking 更敌对,更容易缩小构建体积。

组件应用

    • React 组件仅需引入即可应用。
    • Vue 的组件引入后须要全局或部分注册,且组件内的 Props 的要显式申明。

逻辑复用

    • React 的复用次要体现在高阶组件、render props 以及 hooks,然而也有他们对应的有余。高阶组件层级过深时容易带来 props 的命名抵触、起源不明确的问题,并且额定的组件实例会有更多的内存耗费。hooks 的引入,使 React 的逻辑抽离更容易,齐全修复了命名抵触,起源精确,且无额定开销,能够贯彻函数式编程的理念。然而与此同时,因为 hooks 中可能保留着组件状态,也意味着每次 React 的更新,如果不进行手动优化,不管前后数据是否有变动,每个 hook 都会从新执行,这也是底层架构上额定带来的问题。
    • Vue 的组件复用次要是是用 Mixin、Extend、插槽和 Vue3 的 Function API。Mixin:它和 React 的高阶组件带来的问题非常相似,响应式数据命名抵触,以及逻辑起源不明确。插槽:次要性能点是组件复用,它解决了数据命名抵触的问题,同时数据起源精确,然而也存在着额定组件实例带来的内存耗费 Function API:目前看来是较为优良的一种逻辑复用形式,没有以上列出的所有问题,尽管和 React 的 hooks 非常相像,然而 实质不同,Vue 能够追踪到数据变动,也仅在组件实例化时执行一次。

款式隔离计划

    • React:CSS moduleCSS in JSBEM 命名标准
    • Vue:官网反对 Style scopedBEM 命名标准

TS 反对

    • React 自身就是 Js 和 Jsx,并且 TS 专门开了后门给做了反对(Jsx 其实一开始没有类型反对,Tsx 的开发体验齐全来自于 TS 专门针对 Jsx 制订的一整套推导机制),所以Tsx 的类型反对也很欠缺
    • Vue2.x 来自尤雨溪自己的答复是“因为当初 API 的设计基本就没有思考类型零碎”,2.x 跟 TS 的整合须要借助 vue-class-component 应用类组件进行开发,所以目前 2.x 版本的 Vue 对 TS 的反对度较 React 仍有差距,然而最近随着 Vue2.7 的公布,能够使 Vue2.x 用上大部分 Vue3 的写法,也使 Vue2.x 就具备了兼容 TS 的能力。
    • Vue3,依据来自官网的倡议,IDE 反对需用 <script setup lang=”ts”>+vscode+volar,一样能取得十分好的 TS 体验。

文档体验(这里仅指中文文档)

    • React:中规中距,案例依然不够丰盛,对于一些问题的答案须要借助社区,好在社区足够弱小,属于疑难杂症的问题也能找到解决方案。
    • Vue:文档体验 非常优良且全面,介绍具体,简直各种疑难均能找到答案。

5. 周边配套

React

    • 路由治理
    • React-router 实现了外围路由性能。React-router-dom 基于 React-router 开发,退出了在浏览器运行环境下的一些性能,如应用 Link 组件在浏览器中会渲染一个 a 标签,也反对 History 和 Hash 路由模式。React-router-native 同样基于 React-router 开发,次要是集成了 React-native 运行环境下的性能。
    • 状态治理
    • Redux 根底的状态治理库,引入了中间件,中间件位于视图层收回 action 后,到 reducer 之前触发,在中间件中能够执行比方日志打印、异步申请等操作。
      原流程 :view -> action -> reducer -> store
      中间件流程:view -> action -> middleware -> reducer -> store
    • React-Redux 是 Redux 的插件库,用来简化 Redux。
    • Redux-thunk 用来解决异步的中间件。
    • Redux-saga 外部基于 generator 实现,用于治理 Redux 利用异步操作的中间件,与 thunk 不同点在于:thunk 是在 action 创立时调用,saga 是在利用启动时调用。在 saga 中,工作都是通过 yield Effects 来实现的。
    • Mobx 不同于 Redux 状态治理计划,应用绝对简略,是以数据驱动视图,通过数据绑定,只批改数据自身即可实现视图的更新。
  • Vue

    • 路由治理 Vue router:官网反对
    • 状态治理 Vuex:官网反对

6. 跨端解决

React

  • App:
    在跨 App 界的一哥是 ReactNative,以下简称 RN,因为笔者没有亲自体验过,所以不做过多论述,然而鉴于 RN 是 2015 年 4 月问世,工夫不短,并且也有足够的团队应用,目前看来在前端跨端的畛域 成熟度曾经相当高 了。
  • 小程序:
    对 React 反对度最好的当然是 Taro 了,始终在继续迭代中,也有来自京东凹凸实验室的背书,领有较为稳固的产品和沉闷社区,开发者能够大胆尝试,在最近迭代的Taro3 里也增加了对 Vue3 的反对

Vue

  • App:
    的跨端尝试中没有占据相对位置的框架,Weex 火过一阵,然而近些年热度降落,并且在 Apache Incubator 也已退休,尽管有阿里的背书,然而随着参与者缩小,加上也一直据说阿里外部逐步放弃 Weex 的传言,Github 仓库最近一个更新也是 1 年前,前景未知,不举荐尝试。Vue 在最新的官网文档中举荐的跨端计划是 NativeScript 和 Capacitor,感兴趣的小伙伴能够自行查看。
  • 小程序:
    一种较为风行的跨端计划是 Uni-app,在 兼容多端小程序上有较好的体验 ,对 Vue2 和 Vue3 有着人造敌对的反对度,并且按照评测也提供着十分不多的性能(评测链接 https://juejin.cn/post/684490…),文档体验着实是一言难尽……同时也反对 App 利用的开发。
    另一种跨端形式是 Mpvue,来自美团,从 Github 的仓库看曾经很久未曾更新,也就不做举荐了。
  • 多说几句
    在这里还要多啰嗦一下对于框架的跨端的集体了解,框架如果想跨端,那么在设计之初就要做外围与平台拆散的设计,虚构 DOM 就是一个十分典型的例子,它能够存储所有与 UI 的所有信息和交互逻辑,而在它下层与平台强相干的局部负责具体平台的逻辑实现,这也是典型的分层设计。

7. 设计思路

  • React 推崇的是 单向数据流 (然而也提供了办法进行双向扭转),是数据不可变性,不可间接扭转数据自身,而是通过 hooks 或 setState 更新数据。
    每次更新调用渲染函数从根节点生成新的虚构 DOM 比照 旧虚构 DOM,找到扭转地位后进行 UI 的重渲染,这其中应用了基于链表数据结构的 Fiber 架构,在每帧渲染周期内的闲暇工夫进行 Diff 过程,具备可中断和可复原的个性,以这种 工夫切片的形式不会阻塞主线程 ,以便执行更高优先级的工作,避免页面卡顿。
    更新流程如下图(没有画出具体细节,只蕴含根本流程):
  • Vue 是借助 ES6 的 API拦挡数据操作 ,别离在数据读取、设置阶段进行依赖的收集和告诉,数据的依赖其实是一个个 Watcher 对象(Watcher 可能是组件、计算属性、或者 Watch 办法)。如果 Watcher 是组件的状况,则再调用组件的 render 函数生成虚构 DOM,与旧虚构 DOM 做比照,进行更细粒度的 UI 更新。在这里借助依赖收集和部分的 DOM Diff,均衡了全量 DOM Diff 带来的性能影响。
    更新机制如下图(来自 Vue 官网):

8. 性能比照

比照阐明

  • 抛开场景谈性能,就像抛开剂量谈毒性,全是瞎扯,所以本章节性能比照的数据皆有据可查,比照仅笼罩了一些常见场景,但未能笼罩全副场景:
  • 框架测试用例仓库(点击查看),截止到 2022 年 6 月 23 日,已有 4.6k Star,
  • 比照数据(点击查看),可依据条件筛选框架比照的后果
  • 测试中的比照对象:React v18.0.0 和 Vuev3.2.37,不蕴含旧版本框架,本着框架降级带来性能晋升的惯例认知(反优化的案例也不是没有,但不在这做思考),本章节默认最新版本的 React 和 Vue 在各自历史版本中领有着最优性能。
  • 测试应用设施配置:i7-8750H, 64 GB RAM, Fedora 36 (Linux 5.17.3, mitigations=off, Wayland)
  • 测试应用浏览器:Chrome 102.0.5005.61 (64-bit)
  • 其余:本章节的数据比照,是对已有后果的总结

比照内容
1)持续时间,这里进行的次要是数据量较大的列表操作,比照维度为:

    • 创立列表
    • 替换所有行
    • 部分更新
    • 抉择行
    • 替换行
    • 删除行
    • 创立多行
    • 追加多行
    • 删除多行
      论断:能够看到 Vue 在此场景中近乎完胜,尤其是替换行的状况下,Vue 更是大幅度当先。
      后果可查看下图,绿色示意操作所需工夫更短,红色示意操作所需工夫长
      vanillajs 那一列指的是原生 js 下的性能数据

2)启动指标,次要从以下几个方面比照:

    • 加载时长:次要指标是TTI(Time To Interactive),指从页面开始加载到页面可进行交互的时长,TTI 值越小,代表用户能够更早地操作页面,体验就越好
    • 主线程工作工夫:蕴含款式、布局、执行逻辑等
    • 网络传输字节数:指加载页面中所有资源的老本
    • 后果如下图,依然是 Vue 的问题较为优良:

3)以 MB 为单位的内存调配,比照维度为:

    • 页面加载后的内存应用状况
    • 运行内存,增加 1000 行后的内存应用状况
    • 每 10 行点击更新 5 次后的内存应用状况
    • 单击创立 1000 行 5 次后的内存应用状况
    • 创立和革除 1000 行 5 次后的内存应用状况
    • 后果如下图,Vue 仍然胜出了:
  • 4)聊些比照之外的话
    以上在 运行时 的比照都是以 1000 行数据为基准做参考,问各位小伙伴一个问题,如果数据量更宏大呢,5w 行或者 10w 行,再或者 50w 行?数据会有变动吗?各位能够再思考一下这个问题:那仅仅从以数据作为评测规范又是否可行呢?
    其实笔者不以为然,尽管 React 的数据落于上风,然而从 React 的 Fiber 架构上看,尤其波及到超过肯定数量级的虚构 DOM 比照上,React 是具备劣势的,此架构下的 Diff 不会阻塞主线程,用户对 UI 界面仍然有控制权,尽管页面数据没有更新,然而对于用户的感知是绝对敌对的。
    所以笔者认为以下比照 数据具备参考性,但并非是决定性的,在框架比照上还是心愿各位小伙伴有多方面更感性的思考。

9. 心智模型

对于心智累赘,有观点认为 React 重,也有观点认为 Vue 重,而笔者认为都有情理,起因是两方的关注点不同。

说 React 重,能够从两方面论述:

  • 乱花渐欲迷人眼 :React 官网只保护了的外围库,对于状态治理、CSS 隔离计划等均交给了社区,这样做能够很大水平上晋升开发者的参与度,也很容易诞生一些优良的想法,造成社区内俨然就是一副百花齐放的繁荣景象,然而这也恰好是缺点所在,在大型的 React 我的项目中,一旦短少强约定,甚至能呈现好几种状态治理和 Fetch 库,使开发者对我的项目保护、工具抉择都呈现困扰,于是“百花争鸣”也很容易变成“乱花渐欲迷人眼”了。
    而 Vue 则提供了外围库以外的状态治理、路由等,官网的库品质也有所保障,开发者只有无脑应用即可。
  • 在我的项目优化中,因为 React 的更新个性是自根节点开始一直递归比照虚构 dom 去查找变动,如果不进行手动优化,那么将导致每层组件都会从新调用 render,在大型项目中可能就是性能劫难,所以 React 官网提供了很多专门用于优化的 API,比方 shouldComponentUpdate、PureComponent、React.memo 等,以致在日常工作中,开发者在思考业务逻辑的同时,还要思考性能优化,无奈专一于业务自身。
    而 Vue 则因为天生具备依赖收集的劣势,对于数据的变动更敏感和精确,开发者即便不刻意关注优化,Vue 也能提供给你不错的性能。

说 Vue 重的,其实大多纠结在 API 数量,须要记忆的货色多,并且如果应用了 Vue3,那就又会发现 Vue3 里不论是 setup 写法,还是 API 的更新,都有了天翻地覆的变动,于是发现要记忆的货色就更多了

然而这几点对于有教训的纯熟框架使用者来说,罕用的 API 其实很固定,也往往就是那么几个,对于 新入门的小伙伴,千万不要产生劝退心理

10. 社区生态

  • 寰球开发者应用框架占比考察,数据来源于 Stackoverflow 的 58,743 名受访者,截图中未齐全列出所有看框架的排名,点击链接查看,React 相较 Vue 牢牢占据着第二把交椅。

截止到 2022 年 6 月 23 日 的一些数据

    • npm 周下载量:React:15,764,543 次 Vue:3,279,362 次
    • 在 Stackoverflow 上对于 #reactjs 标签的问题探讨有 396,378 个,而对于 #vue.js 的有 94709 个
    • 在 Github 上,Vue 的 Star 数为 197K,曾经超过 React 的 190K
    • 另一方面,通过来自 similartech 的数据显示,React 被利用在了 1,256,598 个网站中,并仍在以每月 0.59% 的速率增长,而应用 Vue 的网站有 296,047 个,每月增长速率为 0.87%。

11. 开源代码许可协定

也叫软件许可证,具体解释能够查看维基百科,上面说重点。

  • React 是 Facebook 的开源我的项目,Facebook 在 2016 年 11 月强化了 BSD 许可证和专利许可证的概念,在对许可证书受权方和被受权方而言,存在待遇上的不对等性,这就带来一个很要害的危险点:应用 React 的公司和 Facebook 一旦存在业务竞争,React 将成为 Facebook 取得诉讼胜利重要筹码,这无形之中将给竞争公司带来法务危险,尽管 React 起初把开源协定改成了 MIT,然而前事不忘; 后事之师,在某些重大项目的技术栈抉择上,尤其在以后国内环境的奋斗中还是要慎重考虑,并充沛告知本公司潜在的危险。
  • Vue 是由国人尤雨溪开发,软件协定为 MIT,目前在国内起码畅快应用是没问题的。
  • 对于开源协定的解释能够查看百度百科

三、总结:做个了断

终于到结尾了,对于 React 和 Vue 的选型,咱们来做个总(liǎo)结(duàn)吧。

  1. 在选型前,首先是要思考历史因素和团队现状,切换技术栈的前提是不要显著的减少上下游合作方的工夫老本。
  2. 充分考虑框架的兼容性,如果不满足业务需要,再优良也要 pass。
  3. 对于老手来说,React 过于灵便,尽管罕用 API 不多,然而外面有很多设计模式和概念,在具备肯定规模的我的项目中,老手的学习曲线一开始会比拟陡,并且须要代码手动优化,同时宏大的社区中有层出不穷的优良框架,然而在同类型库的抉择上也会绝对吃力,所以不举荐老手应用。然而对于具备几年教训的开发者来说,React 的灵便也恰好是劣势,再联合各种设计模式,很容易使我的项目更具创造性,对于保护具备肯定规模的我的项目很有好处,这也真正能体现开发者的编程能力。
  4. 而 Vue 则恰恰相反,对老手敌对,SFC 中 HTML、script、style 互相隔离的形式更合乎传统的前端开发逻辑,Vue 也已提供了根本的优化,且周边框架的选型也不须要过多关注。
  5. 对于是否适宜大型项目,有人说 Vue 不适宜大型项目,适宜大型项目的肯定是 React,笔者并不这么认为,如果 Vue3 还没出,那么受制于 Vue2 的 Option Api,Vue 在大型项目中多少会有影响,次要体现在逻辑复用和代码组织上,然而 Vue3 有 setup 模式下 Composition Api 的加持,Vue 也已足够灵便,笔者认为对于“Vue 不适宜大型项目”的论调能够休矣,在 Vue 和 React 个性越来越趋同的明天,如果仍然呈现这种想法,那可能更多还是 “人”的问题
    这里还有一个有意思的小插曲,笔者已经和敌人聊天聊到 Vue 和 React,谈到他对这俩框架的认识,过后他说的话令我印象很粗浅,他说“React 我的项目要想写好,会比同规模的 Vue 难一些,然而 React 要想写坏,那可太容易了”,截止到目前,我对这句话仍深认为然。
  6. 如果从性能上思考,在本文的数据比照中 Vue3 要优于 React,然而之前曾经说过,数据并非决定因素,尤其在带宽足够和设施性能越来越强悍的明天,很多 运行时 的性能问题其实在设施层面被抹平,一般业务中甚至曾经不须要过多关注运行时性能了(然而保持良好的优化习惯是每个开发者的低劣品质!),所以单单思考性能,React 和 Vue,翻哪个牌子,看你情绪咯。

最初,不管 React 还是 Vue,都是相当优良的框架,在实现层面同样都有虚构 DOM、申明式 UI 等个性,同时各自也都领有着沉闷的社区和周边,并且有来自各个公司中有数业务线的成熟产品背书,在跨端上也有着十分不错的反对。

作为前端开发者来说,其实曾经把握繁多技术栈,曾经远远不能满足集体的倒退须要了,来自待业、降职、考核的外力总会变为那个驱使你不断前进的内力,学习一门框架其实是要接收整个框架的生态,熵减过程总是令你不难受,而在这所有完结之后,笔者还是心愿你是有播种、并且愉悦的,毕竟——

当初再也不是那个间接应用 JQuery 梭哈的时代了,既要、也要、还要的大潮终将卷起每个前端 er

四、参考资料(包含但不限于)

https://www.rongsoft.com/arti…
https://www.zhihu.com/people/…
https://www.zhihu.com/questio…
https://zhuanlan.zhihu.com/p/…
https://zhuanlan.zhihu.com/p/…
https://mp.weixin.qq.com/s/KC…
https://mp.weixin.qq.com/s/II…

作者:孙凯

退出移动版