都是工具而已,需要什么就用什么,当然,精通一个也是必要的.

个人感觉 vue 是自动挡的车,最佳实践都是官方维护,不纠结,油门一踩就上路
react 是手动挡的车,啥都要自己来,油离配合,档位控制,有操控乐趣.
有人说手动挡的省油啊,但是对于大多数人来说,真不省油,因为技术不高.操控乐趣什么的,一上坡道就熄火也是有的,能跑起来就已经拼尽全力,谈什么乐趣.手动操控的乐趣大概只属于高手

从vue入react还是有不少阻力的,需要将原来自动处理的东西,自己手动设置一遍,虽然可以添加自己的黑科技代码在里面,但是大多数时候,感觉,真是好啰嗦,可能会被新的hooks功能吸引到,但是实际生产中,并不会用太多,因为大多数的数据都是业务的,根本也没有复用的需求,慢慢的,发现以前一个指令干的事情,到了react里面变成了一堆雷同的代码,直到有一天,在这堆雷同的代码中加入了自己的黑科技代码,处理了一个棘手的需求,才能自我安慰一下,还好用了react,要是vue,这个需求可就不好做了......

从react入vue,会发现vue真好用,一把梭.vuex真好用,条理清晰,redux什么的处理个异步还要加个 saga...,自动监听真简单,折腾半天mobx,不如直接上vue.事件监听也不错,不用bind来bind去,react里面的很多高级技巧,到了vue,变成了一个简单的语法糖,真的声明式编程,叫你干啥就干啥,油门一踩,风驰电掣.直到有一天,遇到了一个神奇的bug,然后不知道哪里错了,艾玛,这东西到底是怎么跑起来的,要是react就好了,至少这些逻辑都是我自己写的,还能看看,现在傻逼了,ε=(´ο｀*)))唉.......

对于大多数人来说,自己的代码性能并不会比vue提供的自动化逻辑优秀,所以vue省心又好用.但是涉及到高级的技巧,也是要深入研究的,也就是说 vue 简单用用也可以,复杂使用也可以,起步低,进阶知识可能等到你使用了几个月之后才可能会需要.
而react是就算你想简单用用,你也要学习一堆玩意,要不然根本跑不起来,起步高,进阶起来就天马行空了

等两个架子都用习惯了,发现,殊途同归,一种车开久了,总会厌倦的,换着开开,体会不同的乐趣吧

@lesonky 说的在理，两个框架都很不错，在有react的时候，vue能火起来，也说明vue在它的优势所在，而react不vue的反击下，仍然坚挺，也说明它仍有可取之处。

大佬有什么Vuecli3.0 + ts的文章推荐吗，遇到好多坑，以为官方都出了，这波稳了，没想到，，，，

或者是我有什么基础的东西没掌握到，，，

@xiaodun 首先说明一点，cli3和typescript没有关系，cli只是初始项目的工具，提供一些hello world模版。

然后我可以理解成你是在vue+ts使用上遇到问题而不是cli+ts。这个问题，其实我认为ts和vue的契合度不是很高，从vue+js转到vue+ts，并不能带来很大的质变，因为ts不擅长处理vue的模版，还有vue各种循环性，更改this，让ts很难自动做类型推断。导致在ts大行其道的情况下，vue+ts的组合才特别少见。这也是我转react的一个原因，毕竟ts是主动去支持jsx，而vue是在努力支持ts，太被动了。不过听说vue3采用hook，对ts的支持会更好，而且vue本身也要采用ts重写，到时候可能用ts写vue的人会更多。vue2+ts可以看看我的第一篇博客，有提到一些，最佳实践后并发现没有比写vue+js好用很多

说说ts，不知道你遇到什么坑，在我认为，ts就是增强提示，提高可维护性的，把类型设为any后，又和js一样，不会有任何类型错误，但这样也失去ts的价值。最近看到一篇不错的ts文章，可以看看。
https://juejin.im/post/5da048e2e51d4578477a671e

@xiaodun 首先说明一点，cli3和typescript没有关系，cli只是初始项目的工具，提供一些hello world模版。

然后我可以理解成你是在vue+ts使用上遇到问题而不是cli+ts。这个问题，其实我认为ts和vue的契合度不是很高，从vue+js转到vue+ts，并不能带来很大的质变，因为ts不擅长处理vue的模版，还有vue各种循环性，更改this，让ts很难自动做类型推断。导致在ts大行其道的情况下，vue+ts的组合才特别少见。这也是我转react的一个原因，毕竟ts是主动去支持jsx，而vue是在努力支持ts，太被动了。不过听说vue3采用hook，对ts的支持会更好，而且vue本身也要采用ts重写，到时候可能用ts写vue的人会更多。vue2+ts可以看看我的第一篇博客，有提到一些，最佳实践后并发现没有比写vue+js好用很多

说说ts，不知道你遇到什么坑，在我认为，ts就是增强提示，提高可维护性的，把类型设为any后，又和js一样，不会有任何类型错误，但这样也失去ts的价值。最近看到一篇不错的ts文章，可以看看。
https://juejin.im/post/5da048e2e51d4578477a671e

@coppyC 主要是配置和代码提示这些，并不影响代码运行，但是影响编程体验，
即便是不加ts，在你文章提到的诸如 "加后缀后有什么好处？"这种也未曾体验过

cli3 之后我在vue文件中使用原生的事件类型得不到提示，但是在ts的文件中却可以，

还有我想全局提供lodash，不必要每次都import一下，但是打包的时候却不能只打包使用过的函数，
类似这样的问题令我困扰，我感觉自己用早了。

@xiaodun 可能是我太菜了，不太能理解你在说什么。如果是vue的提示消失的话，我倒是遇到过几种情况，一次是添加原生vue没有的选项，导致提示消失，有的时候是没注意，在一个文件写了两个script，其中一个就会没有提示，这种可能是你说的第二个问题。这些主要是vue的提示全由一个对象开始，且类型十分复杂，稍微解析出现错误，可能整个vue文件的智能提示就没了。

至于最后一个问题也和ts没关系啊，完全是webpack的按需加载依赖，全局引入自然就会全部被打包，按需引入自然要写多点代码。
不巧的是，vue提供了原型链，还推荐把全局的东西挂上去，而且很多ui库用vue加载插件的方式，帮你把全部组件全局加载，这导致在vue按需加载很难，这不是vue的错，但vue至少是帮凶。

@xiaodun 可能是我太菜了，不太能理解你在说什么。如果是vue的提示消失的话，我倒是遇到过几种情况，一次是添加原生vue没有的选项，导致提示消失，有的时候是没注意，在一个文件写了两个script，其中一个就会没有提示，这种可能是你说的第二个问题。这些主要是vue的提示全由一个对象开始，且类型十分复杂，稍微解析出现错误，可能整个vue文件的智能提示就没了。

至于最后一个问题也和ts没关系啊，完全是webpack的按需加载依赖，全局引入自然就会全部被打包，按需引入自然要写多点代码。
不巧的是，vue提供了原型链，还推荐把全局的东西挂上去，而且很多ui库用vue加载插件的方式，帮你把全部组件全局加载，这导致在vue按需加载很难，这不是vue的错，但vue至少是帮凶。

今天早上有折腾了一通，不知道折腾了什么，提示、跳转竟然有了 现在只能把插件 配置啥的复制一遍，回家里试试 果然需要多多于其他人交流！

关于按需导入的问题，我不是很理解你说的，即便是在开发时候全局提供了，但是在打包的时候，插件在分析语法树的时候只打包用到的api应该能做到，何况lodash本身也提供了模块化的功能，我认为是插件之间的配置没有搞对，过些日子在研究下。

webpack 的 Tree Shaking (按需引入) 其实借鉴了 rollup (应该是最早能按需引入的打包工具) 的tree shaking

rollup的tree shaking规则 是这样的，可以参考一下，
https://www.rollupjs.com/guide/introduction/#tree-shaking

另外，还要检查你的webpack有没有开启Tree Shaking，一般都开启了。

webpack 的是这样介绍的
https://www.webpackjs.com/guides/tree-shaking/

主要是 import 写法，不知道你是怎么写，可以参考一下这个例子

// 按需引入 lodash 的 concat
import {concat} from 'lodash'
concat(array, 2, [3], [[4]])

// 引入整个 lodash
import _ from 'lodash'
_.concat(array, 2, [3], [[4]])

所以我才说按需引入会麻烦一点

本来都想开喷了哈哈，结果看下来发现写的真的很透彻，双方的优缺点都写的很清楚。
我本身也是写vue的，但是我真的很羡慕react的生态啊，很多好东西vue生态上虽然有，但是质量上还是有差距。
可是我是真的受不了jsx啊哈哈，还有className这个属性命名。再者vue的css解决方案真的很棒，react上面的css方案还是有所欠缺啊。
不过呢学还是要学的，不多学点怎么涨工资呢哈哈

@Mrcxt 表现出我极强的求生欲 [#滑稽]

博主你好，因为新项目用 antd 的缘故，我也正在从 vue 转到 react
想问下博主新项目的话用 hook + mobx 的是否是用 mobx-react-lite 这个库，或者说还有别的方式？
另外有没必要一并使用 mobx-state-tree ，不清楚 mobx-state-tree 除了时间旅行还提供了别什么？

@jerry000lin
你好，如果用mobx，装mobx和mobx-react就可以了，mobx-react已经包含了mobx-react-lite，当然，你如果全部用hook，不用class 组件，装 mobx-react-lite 也行。
值得一提的是，mobx-react-lite 的 README 文档内容有些落后，示例还写着废弃的api useObservable，而现在官方推荐使用的是 useLocalStore，文档的话，建议看这个比较新，不要看 README.md 的

至于mobx-state-tree ，我没有使用过，不好意思，不能帮到你，mobx-state-tree 虽然提供了更加牛逼的功能，但我用mobx本来就是图个简单快捷，结果 mobx-state-tree 把它搞复杂了，而且大部分人实际开发都用不到这些功能，如果你真的需要很复杂的功能，可以试试redux-saga，这货能提供了很多很似很牛逼，但一般都用不上的功能。不过可以得出结论，mobx-state-tree 不是一定要搭配 mobx 使用的。

另外我新react 项目不怎么使用 mobx 了，因为 mobx，又要写 observable，而且每次还要在外部包裹一个observer，其中，只要少做一步，就出bug，特别是 observer 总是忘记写。所以我自己写了个简单的状态管理，https://github.com/coppyC/mobx-hook， 如果你从vue过来的话，这个写法可能会比较亲切，把 useData 想像成 vue 的data，然后什么都信里面塞，完事。不过，我这个包在局部状态写着舒服，在全局状态管理方面功能就不及前面提的那些了，也没有提供什么牛逼的功能。个人维护的小包，小项目还可以试试水，大项目慎用哟。
ps: 虽然包名叫mobx-hook，但和mobx一点关系也没有，只是因为最初的 0.x 版本和 mobx 有点关系。

另外，为什么这些 全局状态管理都提供了这么多复杂的功能呢? 我觉得主要的原因就是，全局变量都是魔鬼，一但出bug，就很难调试，所以，我的做法是，尽量少写全局变量，而不是去使用很复杂的全局状态管理。

哦对了，antd也有vue版本，虽然不是官方维护的，但如果你真的很喜欢vue，没有必要专门为了antd而去使用react呀。

vue3: react最佳实践 逃);

我和楼主一样差不多14年先接触Vue，然后一直到现在，期间也经历了非常相似的事情。

不过我现在相当于是第三个阶段的选择期

第二个阶段选择期就是Vue@2.x和React相比，Vue确实不太好维护，各种黑盒处理，导致了其他很多不好的影响。

然后也是同样的学习了React然后使用过Taro，但内心还是更喜欢Vue，而不是React。因为我的优先顺序是利用UI框架 + 加上自己的设计思路 = 一个成熟的解决方案
而UI框架上，如果使用React，那前期的路确实很长，而且强迫症我会想要真正熟练使用，那就真的时间不够。

讲到这里，我的建议就是开始的时候还是学习React好，因为你的目标是实现一个成熟的方案去服务业务，而不是仅仅提高了自己的开发舒适度和速度

经历第二个阶段确实非常迷茫，因为那时候已经看到头了，就是以后肯定要换成React，但是现在实在没有时间。
特别其中一点也是文中说的关于维护，团队开发最麻烦的就是你不一定能看懂别人到底在写什么？特别是在使用Vue的过程，各种Mixin，this啥的，你根本不知道这些是啥，会有什么影响，能不能改。就算是自己写得，以后回过头可能都忘记这是什么了？

而另外一个原因就是跨端开发，也是开始接触小程序的时候，mpVue也好uni-APP也好这种野路子团队做出来的东西，能跑起来已经万幸了，更别说加了更多的黑盒处理...而市面上也没有更好的方案。

所以那时候我决定web端和小程序端分离，小程序端单独写构建，然后参考Taro加入了JSX的支持。当然TypeScript肯定少不了。
这样在小程序端确确实实实现了和Vue一样的开发舒适和项目管理。

但面临的坑更多了，特别是JSX要实现编译成小程序的代码，不仅限制多还容易出问题。而且还不能进一步优化。

而且这始终不是个好办法... 只是临时补救一下，当然并不只是Vue这样，Taro@2.x的版本也一样，只是社区比较活跃而已。

直到运行时编译的方案被用到了小程序上，就是kbone和Taro@3.x的方案。这个方案用上以后，解决一个大问题就是小程序端+web端真跨端开发。再也没有什么限制，也不要求一定要Vue或者React。

然后看到这，实际上问题就剩下一个那就是Vue本身的问题，黑盒太多的问题。

然后奇迹又发生了... vue@3.x版本发布了

我的天，vue@3.x的特性直接解决了剩下的所有问题。我们团队用了半年了，目前来说没有任何问题，开发速度快，代码review可行，写得代码可维护也清晰可以说没有任何管理上的问题。所以再大的项目都能处理。而且写起来还是很快，但这次的快没有任何黑盒的代价。而且从设计模式上，实现起来很快

在这个阶段，Vue@3.x可以说确确实实做得非常好，而且已经没有什么之前说的问题了。

所以我们讨论的是 vue@3.x + 运行时编译跨端方案 与 React的对比了，因为Vue@2.x的方案确确实实问题很多。

看到这，其实也告诉Vue开发者柳暗花明了。Vue的方案完完全全和可以和React旗鼓相当，比不过的只是生态和社区（当然差距并不是大到赶不上）

第三个阶段

而第三个阶段是真移动端全覆盖问题

iOS和Android端其实都是属于客户端，而且以后肯定都是前端范畴。

而iOS和Android端最好的方案还是Flutter，那这样代码又分开了。。。又要维护多处代码

而目前的全平台方案其实上和小程序端早期阶段一样。还是使用编译时方案，所以开发体验很差。
并且Vue也有全平台方案，但React相关的工具比较成熟，特别还有React-Native这种别人已经填了很久的坑。所以首选还是React

这时候又陷入了选择，就是又要等到运行时方案出来，还是就现在放弃Vue。和第二个阶段简直一模一样。

事实上，阿里的Rax已经做出来了真全平台的解决方案，web + 小程序（同时支持运行时和编译时） + iOS/Android（基于Flutter实现，自己多了一层胶水代码）

在这个阶段，我们考虑选择的因素就剩下时间成本了。
Rax方案全部开源以后，Rax + Vue肯定很快就有了。但这个时间点不得而知。

最后如果是初学者还是建议先学自己一步一步来，到UI框架阶段先选着React，然后选择Vue@3.x（仅学习实现方案）。这样的话一劳永逸。

我最先接触的是aurelia, aurelia的作者曾经是angualr的作者之一， 后来在学的angular， 学完了以后， 发现vue和react使用很不习惯， 尤其是用起来rxjs在vue和react中并不如angualr流畅。

我还在楼主的第一个阶段，真的是绝对react难用，但是他一定好，因为大厂都在用，下定决心重新再学习。