乐趣区

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

jiezi

一、前言：我全都要

面对当今前端界两座大山一样的支流框架，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…

作者：孙凯

退出移动版