为什么我们从Angular 2迁移到Vue.js（为什么我们没有选择React）

在Rever（www.reverscore.com），我们刚刚使用Vue.js发布了我们的Web客户端的新版本。经过641次提交和16周的紧张开发，我们非常自豪之前做出的决定。
8个月前，我们的前端在使用Angular 2.确切地说，它使用的是Angular 2 beta 9.这是一个由外包公司编写的产品，我们从很多层面上都没有完全满意，从UX / UI到架构，在某种程度上，与Angular 2本身有很大的关系。

在之前，我承认Angular 2 beta 9是与Angular 2.0不同的产品，但这正是其中一个问题。从beta9到2.0.0，有8个beta版本，8个RC和2.0.0版本，总共有17个版本需要升级。我们确实尝试从beta 9升级到2.0.0但是太多的api更改了使升级变得非常困难。此外，大约在同一时间我们质疑Angular 2作为我们选择的框架，Angular团队决定开始研究Angular 4.虽然他们承诺版本改变不会太大，这意味着当我们完成升级到Angular时2.0.0我们需要另一次升级。多么浪费时间和仅有的资源。
我们不喜欢的主要原因是不喜欢Angular 2是Typescript开发的。我知道Angular 2可以和Javascript一起使用但是同样，使用Typescript的决定已经被内部使用了，根据我的理解，使用纯Javascript和Angular 2并不是你应该使用Angular 2的理想方式。无论如何，摆脱Typescript意味着完全重写项目。

我没有觉得Typescript增加了实质性的价值，更糟糕的是，我们注意到我们的编码速度降低了。使用Typescript在Javascript上很容易做的事情就像定义一个简单的对象一样在Typescript上更复杂。我强烈建议您在开始使用Typescript之前阅读以下文章。这对每个人来说都不一定是正确的解决方案。
我还记得使用Angular 1是多么容易，它有自己的不足，但与其他框架相比，Angular 2在途中失去了某些东西。关于Angular 2的结论很简单，Angular 1和2的唯一共同点是名称，它们是完全不同的框架。
因此，考虑到我们在未经测试的系统上有17个版本进行升级，来自业务的很多压力来编写新功能，大量错误和编写得不好的代码，原始开发人员不再在团队中，只有一个开发人员（我）当时有许多其他职责，自从我使用测试版以来找到正确文档的问题，以及Angular 2转移到版本4.他的负面消息开始迅速地积累。
我们做了一个决议，如果我们要花费那么多时间升级，那还不如看看别的框架。

应对

第一个显而易见的选择是React，因为大部分公司都在使用它，而那些没用的人正在谈论它。所以这是一个选择，当然知道Facebook支持它是很有帮助。但是，React本身不是一个简简单单框架，你需要添加额外的组件才能让它绽放光芒。

Vue.js

Vue.js是一个新玩家，我以前从未听说过它，虽然他们刚刚发布版本2时我们开始考虑不同的框架。起初它引起了我们的注意，但是还是有一定风险的。

决策过程

我们首先开始定义我们的决策点。我们知道框架需要具备以下条件：

• 它应该是稳定的
• 由强大的社区或一些大玩家支持
• StackOverflow上有很好的文档或很多问题被解决了
• 简单易学
• 与Bootstrap集成
• 小巧
• 理想情况下，它允许我们重用代码
• 应该增加编码速度
• 基于组件

我们列出所有需求点以后，我不得不开始动手了，所以我给了React和Vue.js几天，分别审查了Google无法回答的每个决策点。由于我对它们中的任何一个都一无所知，所以在两天结束时，我会重新评估我在多大程度上重写了我们要迁移的实际项目的某些部分。
我选择重写的部分是：

• 一些基本的API调用
• 两个不同页面的两个布局
• 用户相关内容的兼容性
• 登录表单和一些内容表单
• 一个bootstrap模式

我对Vue.js的实力感到惊讶，在几天之内我实际上有了一个概念证明，以展示给团队的其他成员和我的CTO。我对Vue.js的基本概念有了很好的理解，定义了一个良好的，可扩展的架构，但最重要的是我非常喜欢用它编写代码的经验，我觉得比React上手更快一些。
React比我想象的要难得多，在Redux和MobX之间进行选择比有一个与Vue.js和Vuex这样的框架完全集成的选项更有问题。这很简单，因为当没有框架经验时，它会让你更自信，而不是一个框架有一个正式的库来做某事。顺便说一句，我觉得Vuex的适用性比Redux更容易，但可能这只是个人的一种感知，就像所有的学习曲线一样。
JSX也是一个问题，因为我们无法重用HTML代码，而Vue.js确实允许我们在某种程度上这样做。Vue文件实际上非常适合使用，因为我不喜欢内联模板。React将JSX / HTML与JS代码混合在一起，我只是不喜欢，因为我坚信分离关注点，看起来很丑。
编码速度
编码速度是Vue.js擅长的领域，不需要学习JSX是一个巨大的帮助。当另一位开发人员加入该项目并在大约1小时的培训课程后的几个小时之后就开始项目开发。
这对我们来说非常重要，您可以通过打开vue文件立即看到它。它包含一个带有HTML和标签的模板部分，看起来类似于Angular 1，所以如果你做了一些Angular 1，它将非常熟悉。一个vue文件也有一个样式和纯javascript部分，你实际上使用javascript，你只需要学习一些关于Vue.js的东西来完全理解它们。理解Vue.js属性（如方法，计算，属性，数据和创建）将使您了解开始编码所需的大约90％，非常简单。
文档
为了获得适当的速度，我们需要良好的文档和Vue.js文档是一流的。指南，示例，问题和API都记录得非常好，涵盖了我们在开发过程中发现的所有疑问。我们害怕找到我们会遇到的许多问题的中文文档，但事实并非如此，一切都以英文提供。
问答
经过一个多星期的考虑后，Vue.js表现非常好，但令我惊讶的是，周围的问题都迎刃而解，因为之前没有人使用过Vue.js，我得到的唯一评论是“ 看起来很酷，但我还没有”用它“。React得到了最多的提及，Angular 2排在第二位。
我开始寻找具有Vue.js经验的本地人才，我确实找到了一些非常好的人，所以我开始认为我并不孤单，我的社交技术圈可能太小而且我不应该对事实上，我不认识任何人与Vue.js合作进行制作。
移动端
在我们考虑Vue.js vs React的时候，我们也在考虑重写我们的移动应用程序，React Native看起来是一个非常好的选择。这对React来说是一个很大的优势，因为Vue.js没有任何类似于React Native试图做的长远稳定的开发，所以在网络和应用程序客户端之间重用代码的可能性是一个巨大的优势，但我决定我不会考虑。毕竟，根据我的经验，使用Node.js，我在浏览器和服务器之间重用了非常少量的代码。
许可
在我写这篇文章时，有很多讨论，因为Facebook将React许可证更改为BSD +专利。根据Facebook，这个许可证旨在保护他们免受专利巨魔的侵害。这在我们的决策过程中并不是最原始的，但我很高兴我们没有采用React的方式，因为任何与许可相关的噪音都不是你想听的噪音。
最终，Facebook落后于React可能会成为项目的责任而不是实力，这就是为什么拥有独立基金会或组织负责成功的开源软件项目通常会更好。Facebook应该做正确的事情，以IBM为例，当IBM收购Strongloop时，他们将Express.js捐赠给Node.js这样一个重要软件所属的基金会。社区的压力和IBM的意愿确保了软件的连续性。Twitter是另一个很好的例子，他们在非常宽松的MIT许可下发布了Bootstrap，没有人在谈论Bootstrap的License问题。
最后的话
在我做出决定之前研究的许多网页中，有一个图表引起了我的注意，开发人员对Sacha Greif @sachagreif每年进行的Javascript调查状态的满意度。我承认，正如作者所做的那样，这不是科学调查，但确实提供了大量信息，后来当我们有更清晰的图片时，我们的决策点证实了这一点，特别是关于Vue.js，因为我们对它一无所知我们研究的开始。您可以通过以下链接阅读Javascript状态。
总体而言，Vue.js是我们评估的赢家，它在Stack Overflow上有很多问题，最简单的三个选项的官方文档，最小的代码库，与Bootstrap很好地集成，并且学习它是有强大的项目支持的Laravel和像阿里巴巴这样的大公司是一个很大的优势。没有像React这样大的社区并不是影响我去用它的一个真正的因素，因为它本身足够大。
选择Vue.js是正确的选择，我花了一段时间来说服我的首席技术官，我非常感激他总是问正确和棘手的问题并100％肯定我的所做出的决定。如果我弄错了，我会后悔的。
最后整个决策过程真的很有帮助，但是我能够快速学习的事实产生了巨大的变化，如果你喜欢就称之为直觉，但是学习一些东西真的快的时候让我对更复杂的问题有了很大的信心。我知道在实际开发过程中我会面对。
我不是说React是一个糟糕的选择，我对社区如此之大感到惊讶，并且有充分的理由，虽然jQuery也有很多人使用，并没有使它成为我们想要的项目的良好框架/库去做。
Vue.js正在获得更多开发者的支持，我们在开发过程中看到了这一点，让我们更加相信，我们的选择是对的。