我们公司有自己的情况，除了我以外，没人用过 react/vue 之类的，jquery 还是 1.12.4，sementic ui 似乎是某个 beta 版本。当初选 vue 是综合各种因素考虑的结果，今年整出来要用 composition api 替换掉老 api 的幺蛾子的时候，我也是忐忑了好一阵子的。

选 vue 主要是有以下几个因素：
首先，就算是 single file component，html/css/js 也依然是分开的写的。这样就少了一个阻力，不然第一眼没看懂 jsx，就很可能因为认为需要学一套新语法而遭到抵制。

其次，vue 的入门门槛更低，哪怕不会搭 node 的架子，也能用传统方式写代码。而相对来说 react 就必须得先把 webpack 那套东西搭起来。

第三，react 是非常明确的 fp 思维，单向数据流需要彻底改变思维习惯，这是一个非常巨大的思维习惯的转变，不然会觉得它难用的要死。vue 虽然从数量上来看，核心概念更多，但除了 computed 不能有 side effect 以外，并没有太难理解的东西。数据的双向绑定虽然从实现上来看是 magic，但对于用户来说却非常自然。

第四，vue 的文档写的非常非常好，不但组织的有层次，而且连各种常遇见的坑也都连原理带最佳实践都给出了。相比之下 react 的文档组织就显得不咋样了，必须得翻 blog，才能找到常见的坑，以及官方推荐的最佳实践。

另外，vue 自带了 vuex 和 router，这样也避免了选择困难。vuex 只有4个核心概念，但在实际使用中，官方推荐外部用3个就够了，而它们又对应着 data/computed/methods，剩下一个 mutation 只从 action 调用就够了。反观 react，是选 redux、mobx 还是其它？如果 redux 需要再学一堆概念，然后处理异步又要面临选择，自己笨写呢，还是 thunk 或者 saga？redux-thunk 跟 redux-saga 比起来就不算啥了，然而也是一堆的概念。所以虽然 react 自己的核心概念不多，但想用出最佳实践来，需要理解的概念就太多了。vue 用官方的东西搭个架子，按照文档来就基本不太会出错。虽然在后来的实践中，还是有同事掉过官方提醒过的坑里好几遍，不过随着 vue3 的到来，很多坑自然随着 Proxy 消失了。

最后跟我们自己的项目也有关，原本计划是先在一个全新的小项目里试水，如果可以的话再在主项目里应用。老项目由于种种原因，锁在了7年前的 rails 4.2 升不上去，所以用一个不需要 webpack 也能用的新技术也在考虑之内。

前端的市场极其巨大，除了 react 也完全再容得下几个大户。目前来看，vue 也已经达到选它不会有错的影响力，新手也不会有找不到工作的担忧。按照 yyx 的估算方式，刚才瞅了一眼 chrome web store，react devtools 有 2M+ 用户，vue devtools 是 1M+，跟几年前一样，还是 2:1。而且由于 vue 的设计，对于有 angular.js、react 经验的人来说，都是极容易上手的，因此也并不太需要担心招人的问题。除非 vue 再自己作死，要整什么废掉老 api 的幺蛾子，应该是能和 react 长期共存一直到下一代革新的技术

【 在 keygen (失落灵魂之囚) 的大作中提到: 】
: 为什么选择 vue 而不是最保险的 react 呢？
--
修改:eGust FROM 115.188.162.*
FROM 115.188.162.*