京东云开发者｜关于“React 和 Vue 该用哪个”我真的栓Q _生活百科

一、前言：我全都要面对当今前端界两座大山一样的主流框架，React和Vue，相信很多小伙伴都或多或少都产生过这样疑问，而这样的问题也往往很让人头疼和犹豫不决：

业务场景中是不是团队用什么我就用什么？
如果选择了其中一个使用，那为什么不用另一个？
这两个框架各有什么优点和无法解决的问题？
最新版本的Vue3已经出了一段时间了，我要不要做组内第一个吃螃蟹的勇士？
我该依据什么样的因素决定使用哪个技术栈？

【京东云开发者｜关于“React 和 Vue 该用哪个”我真的栓Q】以上问题如果想不明白，很容易产生一个“算了不想了真麻烦，还是随大流好了，至少不会出错”的答案，其实种种疑问都指向了一个终极问题，那就是关于技术栈的选型。而技术栈选择的合适与否，往往对项目后续的开发有着极大的影响，甚至关系到业务落地的效率和效果。仅仅掌握业务逻辑的开发，已经完全不能满足个人发展了，就好比一门武林绝学，招式用的再熟，也需要心法辅佐，所以也就引出了本文的主题：

旨在帮助那些对技术栈选择困难症的同学，并对React和Vue产生一定的认知
同时也适合那些只了解单一技术栈的小伙伴，可以拓展一下对不同框架的理解

二、正文：到底要啥本文不会从正面回答上面列出的问题，技术栈的选择往往要依据现实情况从多方面考虑，所以我也将从以下几个方面分别阐述观点，各位读者可以结合自身情况和以下观点，决定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 有兼容需求的情况下，就不要尝试了。