本人长期使用Vue和React，两个框架上的实际代码量都在10万行以上。不得不说都非常好，帮助开发者减少了很多工作量。某个框架就是一个现代化。Vue和React之间的选择并不像选择苹果或香蕉那么简单。两者的工程实践差异让我们逐渐放弃了Vue。在这里，我们从不同的角度对彼此进行深度比较。常见的挥杆问题、观点首先，我将谈谈常见的比较项目和观点。这些部分可以通过一些文章或者Vue官方对比文档找到。主要目的是帮助小白解决入门问题。如有异议，欢迎在评论区留言Battle，反正我不会回答你的问题。Vue或React文档更丰富？两者都有丰富的文档（包括中文文档），Vue文档，React中文，不用担心过不了4级，看不懂文档。都是眼力问题~当然如果你提前了解javascript方面的知识也很好，ES6语法更好，可以在这里向阮老师学习，免费电子书。文档和持续改进不是您在两个框架之间进行选择的原因。对于Vue，你需要记住各种指令和属性细节，所以你不可避免地会经常查看文档。React比较简单，记住：“函数入口是props，出口是html”。React学习门槛高？这不是你选择框架的原因。如果这也能成为原因，我想是因为你懒惰，给自己找借口。根据自己的学习和实践总结，这两个框架都很简单。如果你有手，你可以做到，但如果你有大脑，你也可以做到。它并不一定意味着你可以做出反应，所以它比Vue.js好得多。都提供了相应的脚手架供用户使用：vuenpminstall-g@vue/clivuecreatemy-projectreactnpxcreate-react-appmy-appcdmy-appnpmstart傻瓜式使用，无限div就大功告成了。React用于大型项目，Vue用于小型项目。我在华为的时候，经常在内部讨论两个框架的对比。你是什??么意思？这是万精油的标签，没有参考意义。你如何定义一个项目是一个大项目？超过xx万行代码？超过xxx个后端API？无论什么样的项目，都有变“大”的可能。只要它在正常运作，你就得继续维持和补充补充需求。框架的可替换性更为重要。当然我可以告诉你，我不知道适度响应不适合“小”项目，但是Vue不适合“大”项目。业务代码超过5万行后，问题就很明显了。稍后我将对此进行详细解释。XX大公司也在用Vue，我们就跟着。很多新手都是从一些框架或者选择组件入手。做方案的时候，他们会看看有哪些大公司已经用过了，以免踩到自己的脚。当然，我也可以。但大公司可能只是将其用作“尝鲜”和“实验”。这些项目彼此无关。如果选型失败，压力将交给开发工程师。996个批改就够了，还有你，╮(╯▽╰)╭项目还得跟狗屎一样维护。举个选型错误的例子，看看大公司如何挽救。华为做硬件项目的时候，用的原理图软件堪称热鸡。我想砸电脑。历史问题，选型错误，但是很多项目，基础库就在上面，只能硬着头皮，迁移成本太高，软件厂商水平太差，不过华为给力，放该软件发生了重大变化和特殊变化。上面集成了各种内部数据库，各种自研的辅助工具，还是可以开发出非常强大的产品的。该部门制造的单板已连续11年位居世界第一。（PS：之前用tcl写脚本，也可以试试蛋芽痛）-如果你觉得选错了导致的问题你能解决，或者你是华为的，那我们再说吧。Vue模板简单，Reactjsx有学习成本同上。两者都很简单，学会了就可以学会。连这玩意都叫学习成本，我只能说：“我不是针对你，我是说在座的各位……”（Vue模板工程实践问题很多，后面会详细讲）为了性能对比一下，可以看看这个第三方benchmark测试，都挺快的。但是在实践过程中我们发现了差异，比如大列表渲染，大量数据加载，没有进一步优化的Vue明显比React慢。我们之前都是用Vue写TaskHub网站，然后直接迁移到React。想到之前写了这么多，╮(╯▽╰)╭，下面是重头戏，写一下实践过程中发现的问题，以及两个框架的解决思路。如果你还是新手，下面的一些东西可能不会接触，可以看看这篇文章：【翻译】通过创建同样的APP，比较React和Vue，实现它，了解基础知识。市场份额相关的npm下载量见上图，市场已经用脚投票了。看这里，如果你只是想了解评选代表，可以去。如果你还说xx大公司在用vue，跟着走。可以说大公司用React比较多，使用Vue的目的就是为了保留相关的技术栈能力，多一种选择，避免React授权事件的再次发生。React的许可协议到底怎么了？Facebook承认了React专利，但问题还是没有解决？当然游达这里也说了，看npm的下载量是没有用的，实际使用还是要参考devTool的下载量。但是……为什么我打开的很多网站下面这个标记都是亮的？开发生态客观来说，作为核心团队成员，我们意识到自己会更喜欢Vue，认为用Vue来解决一些问题会更好。没有这个信念，我们就不会整天忙得不可开交。但在那之后，我们要调整以公平准确地描述一切。其他框架也有显着的优势。比如React庞大的生态系统，与官方的Vue生态有明显的区别。Vue官方承认了这一点。很多人因为生态迁移到React，但我不太关心，Vue生态还不错。你说你用React生态，你会觉得牛逼，你的core也会用。这不会给你的产品带来多少附加值。竞争力还是要看自己的代码。好的。下面简单介绍一下：这两个UI组件的周边UI库都挺丰富的，反应稍微多一点，但这不是选型的关键。自己写UI库并不难。偶尔封装原生标签也很简单。.以前用Vue的时候，没有UI库。自己手动写了一个功能比较齐全的UI库，打包了一个总结，也就两万行左右的代码。Dom相关的第三方库Vue和React都有可以操作dom的refs，自己封装起来也不难。可以看看别人有没有打包，用来学说。Vue：访问子组件实例或子元素React：Refs和DOM小程序（重点补充）有小程序开发经验的同学都知道，小程序的原生开发是非常痛苦的，通常需要串行框架封装和代码转换。常用框架有几种：taro（React技术栈，推荐）wepy（Vue技术栈，强烈不推荐）uni-app（Vue技术栈，可用）这些小程序开发框架都是基于Vue或React二次封装，简化开发的小程序。Vue的一些外围库是和Vue强绑定的，而不是以一个独立的js库的形式存在。导致代码难以理解，相关的bug和问题也被带入二次开发的框架中。这种强依赖带来的问题会给以后的项目升级和迁移带来很多问题。比如vuex，作为Vue官方推荐的状态管理方案，只能在Vue上使用，不能在camp上使用。redux的状态管理在camp中用的比较多，但是这个在vue中可以用。类似的问题还有很多，你会发现React周围的东西在Vue里可以用，Vue里的东西在React里用不了。如果你觉得这个问题不严重，当你将Vue代码迁移到小程序wepy框架时，你会发现wepy不支持Vuex（bug异常多），只能使用redux进行状态管理。同样的问题，如果使用React相关的技术栈，将React迁移到Taro小程序框架非常简单，一次性生成微信小程序、支付宝小程序、字节跳动小程序等，代码占用率高的。我对APP生态weex、rn没有很好的实战经验，有些生产计划要慎重考虑。很明显rn比weex更成熟。总编译代码组Vue三种组件写法对比（Js部分）对比API29行importVue,{PropOptions}from'vue'interfaceUser{firstName:stringlastName:number}exportdefaultVue.extend({name:'YourComponent',props:{user:{type:Object,required:true}asPropOptions},data(){return{message:'Thisisamessage'}},computed:{fullName():string{返回`${this.user.firstName}${this.user.lastName}`}}})API类17行import{Vue,Component,Prop}from'vue-property-decorator'interfaceUser{firstName:stringlastName:number}@ComponentexportdefaultclassYourComponentextendsVue{@Prop({type:Object,required:true})readonlyuser!:Usermessage:string='Thisisamessage'getfullName():string{返回`${this.user.firstName}${this.user.lastName}`}}功能API25行importVuefrom'vue'import{computed,value}from'vue-function-api'interfaceUser{firstName:stringlastName:number}interface你rProps{user?:User}exportdefaultVue.extend({name:'YourComponent',setup({user}:YourProps){constfullName=computed(()=>`${user.firstName}${user.lastName}`)constmessage=value('Thisisamessage')return{fullName,message}}})React两个组件写法比较（Js部分）classcomponent34行importReact,{Component}from'react';interfaceP{}interfaceS{}classIndexextendsComponent{constructor(props:Readonly){super(props);this.state={};}staticdefaultProps={};componentDidMount(){}componentDidUpdate(prevProps:Readonly
){}componentWillUnmount(){}render(){return(
);}}导出默认索引；functioncomponentline15importReact,{FC}from"react";interfaceProps{}constIndex:FC=(props)=>{//js代码return();};Index.defaultProps={};导出默认索引；injs逻辑部分没有错，需要用到框架特有的生命周期钩子，vue类写法方法最简洁（3种比较），响应函数的写法最清晰（所有写法比较）。这部分不是选择的重点，怎么写是个人喜好。组件内状态管理Vue使用数据对象（data），响应使用状态对象（immutablestate）。在这方面，两个框架的设计不同，下面的解题思路也不同。如何修改数据？Vue直接直接修改这个引用数据对象。React如何使用setState方法修改框架发现数据被修改了？Vue使用es5新方法Object.defineProperty劫持setters和getters来实现数据监控。React，你用setState，它通过这个函数知道一些数据的变化。我如何知道数据已被修改？Vue：使用观察者，或者计算属性来发现反应：componentWillUpdate，componentDidUpdate可以监听变化，或者一个函数组件的依赖部分被插入到框架中。渲染修改后的数据时，我怎么知道它已经被渲染了？Vue：适时渲染，可以通过watcher，或者computedproperties找到反应：调用setState后适时重新渲染，并调用相关的生命周期钩子。它们在组件状态管理功能上都没有太多槽点。要说Vuewatcher写了一大堆代码，一堆缩进，更严重，反响也好不到哪去。Vue的写法比较简单，但是组件状态比较多。当需要清晰的数据更新逻辑时，简单的响应setState({},callback)将完成它。Vue有点混乱。Vue项目解决bug和疑难杂症的三大定理。没有什么是深度观察解决不了的。如果有，添加immediateeventrelated,domrelated。请记住nextTick确实不起作用，因此在应用程序复杂时使用setTimeout（来自高级）React的不可变（immutable）状态透明度和更好的可测试性。对比上面的内容，我觉得都还可以，功能也还行。Vue的生态没那么好，但是你可以自己做。这就是我们真正弃用Vue的原因。VasuedBuyabuyode说：同样的问题，在语言层面的解决方案是最好的解决方案。语言生命周期比框架生命周期长。模板语法VSJSX部分缺少Vue的单文件组件。直接使用和//eslint-disable-next-lineno-unused-varsimport{isNickname}来自'../fn/filter'；exportdefault{name:'HelloWorld',props:{msg:String},data:()=>{return{a:false,b:1,c:1,}},方法：{isNickname1(){returnisNickname('abc');}}}以上代码会报错：[Vuewarn]:Propertyormethod"isNickname"isnotdefinedontheinstancebutreferencedduringrender,所以只能定义方法中的方法，然后引用它。模板语法不知道你有isNickname函数，简单的操作加了3行代码。模板语法不是图灵完备的，必须转成js代码（渲染函数）放在组件上下文中。类似的例子还有很多。你会发现你写的代码和Vue是强绑定的。当Vue核心库升级时，你的代码也会崩溃。Vue核心库升级了，外围依赖库也要相应升级。模板拆分良好的代码组织可以拆分常量和常量部分DevariableVue的模板严重限制了这一点。比如前端有个拖拽菜单，功能在不断增加，需要针对不同的人显示不同的菜单（权限管理）。在Vue中，要想实现html代码的划分（绑定在模板中），只能多做一个组件。在React中，可以直接这样写：constmenu=abc
;它可以作为一个单独的组件（低开销功能组件）使用，也可以作为一个变量放在当前代码中。比较灵活。JSX手写渲染渲染功能自带以下优点完整的js功能构建视图页面，可以使用js自带的临时变量，控制流，直接引用当前js范围内的值开发工具对jsx的支持优于现有的vue高级模板（linting、typescript、编译器自动完成）JSX可用于Vue可用于React，就像Redux一样。该语言与框架一起解压缩。“虽然模板语法有这么多问题，但Vue也支持JSX。”我猜你会这么说，但正如上面所说，既然我必须使用JSX/TSX，Redux，为什么我不用React呢？“基于HTML的模板可以更容易地逐步将现有应用程序迁移到Vue”不会更容易，只会更麻烦。首先，下面提到的模板不能很好地lint，类型说明，过去代码迁移的很多bug不能及时发现。其次代码迁移很大一部分是js逻辑的迁移（这个比较重要）。迁移到vue的时候，需要通过强行把原来的代码进行细分，放到计算和心态上。工作量不小，代码与Vue强绑定。.最后，原来的代码类，比如@click，有了现代编辑器，用className批量替换，onClick不是很简单的事情吗？Typescript，lint支持更是致命，Typescript已经成为我们前端开发的必需品。之前可以发现大量的错误。但是Vue的模板不支持typescript（官方还在加强），需要在模板上进行很多“hack”操作才能支持，原有框架比较复杂。很难在Vue.extend对象中写代码有更好的ts，从而更好的支持Typescript。我们以前都是用Vue类写的（见上文）。前端配合后台放置界面，模板代码中出现了很多事先没有检查出来的错误。可测试性，重构Vue需要新建一个.vue文件
{{hello}}
React操作全部在jsx环境下执行，位置任意，写法比模板更容易测试。继承：functionTest(props:{hello:string}){console.log(props);return{props.hello}
}Vue和React测试成本的区别是显而易见的。React运行起来，一个功能就做好了，测试什么内容一目了然。类型、属性修正就行了，编辑器自动化。复杂的状态和动作管理整体状态管理方案的选择非常重要。毕竟95%以上的API对接代码都在这里了。这部分代码占了很大一部分代码，可以互换替换。测试成为选择的关键。Vue唯一推荐的解决方案是转换后的Vuex（Redux到Vue的迁移不算内部）。React的周边解决方案包括Redux、Mobx等，这些库不会对React产生强有力的替代（可以独立存在）。两个框架的状态管理思路相似，都是单向数据流和单例模式（Vuex&Redux）。WicksVuex的源码不多，可以看这里。可以看到代码中有很多东西是和Vue强绑定的。没有Vue，这个东西是行不通的。你可能会说我就用Vue，为什么不用React？考虑以下场景：项目经理突然要迁移Vue代码以支持小程序！有些框架不支持Vuex，项目经理脑子里嗡嗡的说要配置APP端，突然！一群臭虫！项目经理脑子嗡嗡作响，他想把React项目迁移到Vue，一下子！还原！我还在用saga！头部嗡嗡声状态管理的静态问题！写了一堆烂代码来解决。新来者读懂了他们的头脑并嗡嗡作响。这部分代码比Vuex源码还多？这些问题是由于状态管理库和框架的强绑定导致的，框架上的问题也会影响到周边的库。if(version>=2){Vue.mixin({beforeCreate:vuexInit})}else{//覆盖init并注入vuexinit过程//以实现1.x向后兼容性。const_init=Vue.prototype._initVue.prototype._init=function(options={}){options.init=options.init?[vuexInit].concat(options.init):vuexInit_init.call(this,options)}}可以看到，Vue核心升级，这些附带的库也要升级测试。在非浏览器环境下运行时，由于Vue（或类Vue框架）的初始化机制的大小，会导致Vuex等相关库不可用，会多出一个代码分支，相关代码无法替换、测试和重构。重的。ReduxRedux是React中常用的状态管理方案。它的设计思路非常简单（见上图），可以独立使用，相关代码也可以方便的移植到不同的平台。衍生出来的周边也有很多替代品：重磅的redux-promiseRedux-Saga可观察选择可以参考here&here。我们用saga比较多，处理静态问题比较简单。您可以从阅读更多文档开始。不难。下图可以帮助大家理解几种方案之间的关系和优劣权衡。相关插件也很丰富，参考：Redux中间件。你会发现很多你想要的东西在Vuex中是没有的！“这样的话，我就直接用Vue上的Redux就好了”，毕竟以后迁移到React上会更容易一些。万恶之源，this指针，写过React函数组件的同学都知道，在引用类组件时，函数组件缺少this指针，代码精简、清晰、冗余。而这个问题在Vue上更加严重。有人认为这是一个优点，易于使用。等你的代码量变大了再说吧。多人合作一个项目，或者继承别人祖传代码，不分段搜索，不知道是羊头还是狗头。这个.ajax，这个.http，这个信息这个.wtf...就像有网友评论的那样：那个东西就是全局范围。如果以“方便把东西放在划分的范围内”为优点，那和“方便让你随处大小便”有什么区别……写C语言的新手都知道类别变量不应该随便用，这是满天飞，张三看不懂，李四看不懂，IDE也不会。而这是官方推荐的写法，╮(╯▽╰)╭（说大规模不准确，应该说是组件范围）。想起之前自己写的VueUI库，叫SUE-UI，sue~很快。为了避免以后和其他插件冲突，所有插件都使用：this。$su_messagethis.$su_modal这个。$su_toast往事不堪！最后，在框架功能方面，我还没有发现Vue能做到而React不能做到的，反之亦然，两种框架都能满足功能需求。在工程实践中，由于转换、代码组织、粗略升级、测试、开发，最终放弃了Vue。在Vue中你操作一个定义好的对象，在React中你操作一个函数。所谓前端开发，本质上就是写下面的函数。S=async(A1)S=sync(A2)UI=f(S)显然camp把这个抽象的更透彻。
