一、市场因素

市场供需会直接影响到我们的招人成本，不只是金钱上的成本，也包括时间上的成本。我们一起来粗略地看下Vue、React、Angular三者的市场需求——用他们的名字作为关键词在招聘网站（前程无忧）上看搜索结果数量如何。

• 不限制月薪，搜索结果数分别为Vue（31651条）> React（17327条）> Angular（7054条）。
• 月薪范围限定在0~9k，搜索结果数分别为Vue（12206条）> React（5623条）> Angular（2356条）。
• 月薪范围限定在10~19k，搜索结果数分别为Vue（23094条）> React（12853条）> Angular（5245条）。
• 月薪范围限定在20~29k，搜索结果数分别为Vue（5776条）> React（4407条）> Angular（1632条）。
• 月薪范围限定在30k以上，搜索结果数分别为Vue（1663条）> React（1616条）> Angular（536条）。

整体的国内市场（全国）对这三者在需求数量上的倾向是Vue > React > Angular。Angular的需求量最低，Vue和React在月薪20k以上的招聘需求中数量相当，但是在月薪20k以下招聘需求中，Vue比React要多一倍。这几个框架出来都很长时间了，其需求量和供应量是处在动态平衡中的，所以招人的时间/金钱成本上有下面的规律（这个结论基本和我们的认知相符）。

• 在0~20k月薪范围内，招人的时间/金钱成本：Vue < React < Angular。
• 在20k以上的月薪范围内，招人的时间/金钱成本：Vue = React < Angular。

结论：一般不建议考虑Angular。公司钱多的话Vue和React可以随便选。但是对预算有限的初创团队，建议用Vue。

二、团队因素

2.1、团队现有的技术积累

团队现有的技术积累在哪个框架一般就可以继续用哪一个，比如React没必要换Vue。但是如果是多框架混用的，可以内部讨论下做个统一，这样不仅减少了人员在项目间切换的成本，也方便团队内部的技术积累（比如封装一个列表组件，混用时团队可能要封装2个，统一后只用封装1个）。

这里不局限于本团队，也要考虑公司层面的其他团队，比如架构部门（如果有）。

2.2、团队的技术能力

如果团队成员平均水平比较高，平均P6起步，还带几个技术牛人，技术风格就可以比以初中级开发为主的团队要适度激进一些。当然这个激进需要是一个权衡后的结果，不能为了新而新，而是你判断这个新的东西确实能给你们带来很多好处，然后预期能解决早期遇到的坑。

2.3、团队的技术倾向

如果团队现在用的是Angular，然后团队成员出于职业考虑都想用Vue，后面上新项目的时候就可以考虑换成Vue。这样就是一个双赢，后期招新人会比较容易，团队成员也能积累热门框架的工作经验。

如果团队成员都比较喜欢jsx那种写法，那就上默认jsx的React，虽然Vue也支持用JSX，但毕竟不是默认用这个的。

三、产品因素

3.1、产品周期

对于短平快、上线几天就下线的项目，比如专题各种活动页，啥顺手就用啥。大可不必考虑技术选型。

对比较简单的项目：在设施比较完善的公司，如果此类项目比较多，对其中比较有规律的项目可能直接会有对应的可视化搭建系统；如果没有的话，直接一个html里加几个图片，写个按钮跳转产品页，也很香。

对稍微有些交互的项目：html里script标签引下Vue和zepto，也很香（在不想引入webpack、gulp等构建工具的时候，script标签直接引用vue的使用方式是很方便的）。如果涉及多页面，用vue/react对应的cli搞一个直接用也不过分。

3.2、SEO

这种时候其实vue（含nuxt.js）和react（含next.js）都行，它们搭配webpack时，都有现成的库可以做预渲染的，也是有一定的SEO效果的。但是一般我们会用nuxt.js和next.js，尤其是在你的数据并不是那么固定的情况下。

3.3、跨端

如果要跨多个终端，uniapp是个不错的选择。但是如果公司成本上允许的话，各端写各端的，能少很多坑。

四、技术因素

4.1、产品对技术的限制

如果新公司要上的项目是一个微信公众号项目和一个微信小程序项目，假设此时微信小程序刚出来，Taro这种类React的第三方框架还未出现，由于微信小程序这块是天然类Vue的，公众号项目多半就也会选择Vue了。

4.2、性能因素

如果你要写的项目是个H5小游戏，那Vue、React这些肯定不适合，考虑适合做这块的框架/库。

由于Vue的依赖收集处理的比较细，React组件一般人也不会去写shouldComponentUpdate，所以更新UI时我觉得Vue做的会比React的要好一些。