为何咱们选择Vue，而不选React（译）

最近Qwintry团队积极地把Vue.js做为了他们的前端框架，而且在全部的新旧项目中使用它，包括:

• 过去qwintry.com的Drupal系统 (qwintry.com)

• 咱们的新项目，彻底重写了qwintry.com分支

• 一个用Yii2 构建的B2B系统 （logistics.qwintry.com）

• 咱们全部的小项目和外部拓展项目（大部分是php和node做为后台的）

世界上有大约被50W人使用Qwintry。咱们用咱们的软件经营着两个货仓（一个在美国，一个在德国）。在美国，咱们是最大的邮件代理之一，咱们的用户和货运通道主要集中在东欧和中东。其实，咱们主要是帮助人们节约一些航运的费用，让他们更方便的在网上购买美国的商品。而且咱们利用咱们的信息和物流系统，帮人们找到最好的性价比的商品。

这是咱们在用户门前的包裹。

咱们拥有庞大的代码库，基本都是用PHP和JS构建的。

在咱们分别用React、Vue.js、Angular 2这些现代框架来构建咱们的“用户计算器”以后，通过比较，咱们决定使用Vue.js。

我对React的见解

当咱们在讨论选择前端框架的时候，React在JS世界的膨胀，致使了它如今极可能已经成为JS开发者默认的选择。

我用React开发了一些SPA的应用，也作过一些动态的组件。我也在IOS下玩弄过RN + Redux。我以为React对JS来讲有一个伟大的出发点就是状态机，它给人们展示了函数式编程的优点。我以为RN的野心是庞大的，它改变了原生开发的世界。

对React的不足之处的我的看法

以一种纯净的、不变的、稳定的机制来控制状态

别误会，我很欣赏用纯函数和简单的render的方式控制状态，毫无疑问，这在真实环境的生命周期中是一个很好的形式。我要讨论的是其它的一些点。

我想，当你的团队有超过1000个开发人员的时候，这种纯净的、严格的模式多是颇有必要的。但也只有当你想把你本身的语法加入到你写的静态规范的代码的时候才是必要的，或者你是一个从Haskell转到JS的开发者。但大多数的开发团队通常都是比Facebook小得多的开发团队。

恶心的JSX

我懂我懂，它仅仅就只是一个特别的js语法。原本咱们的设计兼前端仔只须要去专一于每一行HTML的elements就好，然而他们如今写代码就像在吃shi。让设计师使用JSX写React组件是很是恶心的事情，由于JSX的可读性太差了。不能在html代码块里写一些简单的判断语句，请别相信那些盲目的React粉丝告诉你，你不会须要写这个，你只须要写三元就好。我敢保证，在实际开发过程当中，你仍然须要读写一堆HTML和JS的混合代码，即便他们后来被编译成纯JS。

 

       {items.map(item =>
         
{item.name}
       )}
复制代码

大量的开发者（曾经包括我）都以为这是一个由特定限制的语法，这将会帮助你写出更加模块化的代码，由于你不得不把你许多辅助方法也放入你的render函数里，就像这家伙的建议：
stackoverflow.com/a/38231866/…

也正是由于JSX的写法，因此你不得不把15行的html代码分割到三个组件中（每一个组件5行html）去。

不要以为这是可让你成为优秀开发者的一个好方法，由于其实你只是不得不像上面那样编码罢了。

这里有一些场景：

当你在写一个复杂组件（一个你可能并不会把它发布在你的github上的组件）的时候，你为了完成实际业务目标，你会拆分你的组件，而后组装成一个更完善的大组件，由于JSX的数据规范可能会让你的数据流溢出。但，个人意思不是说小组件很差或者效率不高。

你应该清晰的意识到你把你的代码分离到别的组件是为了保持代码的可读性和可复用性。但你也应该知道，把你的代码组件化是由于每一个组件他们有本身的逻辑实体，被分离后的组件有本身内部的属性，（并且建议若是只有两三个 if 的时候建议写三元表达式）。每次你建立了一个新的组件，都会消耗一些内存和一点点数据流（也可能更多），由于你须要从完成模块业务的思路（当你肯定你已经记住了当前组件的状态，而且你只须要添加一个html就能运行当前组件）切换到管理业务（管理组件）的思路上来。这样你就能够去分离组件，开始思考新组件的属性，新组件如何去适应状态，如何设计回调函数等等。

事实上，由于在一个没必要要的地方，强行权衡组件的模块化过大或是太小的时候，会减慢你的编码速度。在我看来，提早决定模块化的方案就至关于提早决定了最佳实践方案。

对于我和个人团队来讲，代码的可读性是最重要的，可是代码的趣味性也同样很重要。试想，当你想要生效你的计算器插件须要用到6个组件，这样的编码并不有趣。而且在不少状况下，一些插件代码的维护、拓展或可视化测试，都要在好几个文件或函数里跳来跳去，而且须要检查每一个被分离的html的小包是否正确运行。再次声明，我不支持写一个巨大的组件，我支持的是用组件去代替日复一日的微组件开发。这样比较符合常识。

用表单和Redux编码将会让你一成天都在归类

React是基于一个纯净的单向数据流的框架，记得吗？这就是为何 LinkedStateMixin 双向绑定变得流行。如今，你必须建立10个函数得到10个input里面的值。在这些函数中，有80%会包括一个this.setState() 的函数调用，或者若是是Redux的action回调（那样的话，你不得再也不建立另外10个常量来匹配这10个input）。我猜，你必定想若是能靠脑补就自动生成这些关联代码就行了，可是我目前尚未发现哪一个ide能够提供这样的插件。

为何咱们不得不归类这么多？由于双向绑定被一些大企业的大佬们认为是很危险的。我也认可使用双向绑定的数据流进行编码，有可能可读性不是那么好，可是这些担忧大部分都是由于Angular 1的双向绑定带来的负面影响，并且这可能也不是双向绑定最大的值得担心的地方。

如今让我为你展现一个快速编辑器组件，这个组件是我最近用Vue.js为咱们的Drupal网站构建的。

我没有贴出个人源码的缘由显而易见，可是用Vue编码的过程是有趣的，而且代码的可读性很强。

如今，我很确信，若是要我使用React完成上图中的操做，就须要为每个input建立一个单独的函数，来达到控制一个挂件的目的，这样作，并不会让我感到快乐。

Redux 听上去就像是冗余的同义词，如今也很容易的找到一些开发者，他们的职责是将React转型成Angular。这么作也只是由于想要让数据实现双向绑定。个人第一个要点是“1 关于纯净”。彷佛不少聪明的人会让他们的代码库变得比他们的工做更有价值（我猜，当你的工做没有截止日期的时候，必定很爽）。

过多的依赖

React须要被babel编译，若是没有一连串的npm包，你的react项目将会步履维艰，因此先用es5进行开发。最简单的应用开发也会须要基于一些官方的React依赖包，这些包在node_modules里面，大约有75MB。

这不是在批判，这些依赖这么多，更多缘由是因为js自己的缘由，而不是React的缘由。可是这些综合因素加起来，使得使用React开发变得很累。

Angular 1：太自由反而不是好事

ng1曾经也是一个伟大的框架它与React彻底相反，它的代码可阅读性更好，它容许你快速上手，在刚刚开始的1K行代码中，你的确感觉到了许多的乐趣，以后它就会让你一直写出糟糕的代码。你极可能在大量的指令，scope和双向数据流中迷失方向，它们贯穿于你全部的应用中难以维护。由于是难以维护的，因此让大家新加入的开发者去维护旧系统，更是让人拒绝的。

为何会这样呢？

ng1创造于2009年，那时候的前端应用都还很简单，没有人想到以后会有这么多状态管理的问题。你不该该去责备他们，他们只是想用一些新理念超越Backbone，而且写更少的代码。

Angular 2

为了构造一个hello world的应用，而后找到项目的入口文件，你须要使用Typescript而且编译它们才能够开始工做。这实际上仍是要在我真正开始工做以前，所作的一些规范。依我看来，开发ng2的人尝试去构建一个更优雅的框架战胜React，而不是尝试去构建一个能解决大多数用户问题的框架。可能我这个想法是错的，我对于ng2也尚未太多的经验，由于咱们仅仅是用它为咱们的货仓作了一套用户的计算器系统，用来测试它的框架性能。这有篇写的很好的对比其余框架的文章，ng2的确是很棒的框架，这篇文章里也与Vue进行了许多的对比。

Vue.js

简单的说，Vue.js 就是我等待已久的框架（我将会讨论Vue2，一个比初版改进了不少的框架，而且也在最近发布了稳定的版本）。对我来讲，Vue的优雅和简洁可以让我更加专一于业务代码。Vue能够说是2007年的jQuery以后，又一个给JS世界带了巨大改变的框架了。

若是你想看看Vue的人气，你会发现不只仅只有我是看好Vue的：www.timqian.com/star-histor…

Vue.js能成为2016年里高速发展的JS架构之一，我认为它的发展不只仅是靠粉丝的支持，更是由于一些权威组织的学术支持和确定。

Laravel也把Vue.js添加到它的核心思想中去，这是一个值得关注的事情。

Vue.js的特色

Vue.js在代码的可读性、可维护性和趣味性的方面的处理可谓是会心一击。若是你看过Vue的文档指南，你会立刻发现，这个框架将比React和Angular 1 带来更好的编程体验。

对比React，React是一个以组件为基础的框架，每一个组件实例有本身的方法、属性、顺着组件层级的单向数据流、函数调用、虚拟dom、和状态管理。

对比Angular 1，Angular 1 更像是一个有着优秀语法的模板，而且有你必定会须要的双向数据绑定（在单个组件内）。

Vue.js是一个很容易起步的框架，这在咱们的团队中已经获得了印证。它不须要强制的基于任何编译环境，因此它能很容易地和你的历史遗留代码结合，而且能立刻用Vue的代码改善历史用jQuery编码时的问题。

快速获得正确的结果

不管是在html，仍是在js中使用框架，Vue.js都是一个很容上手的框架。它让你在操做一个复杂的模板的时候，你能够专一你的业务。而且即便这个模板很是大，也能有很强的可读性。在这个时候，你就能更方便地根据你的业务逻辑处理好的你的代码逻辑。若是你想重构模板而且拆分它们成更小的组件，你也能够从刚开始的大模板中更清晰地看到整个应用的关联关系。

从个人开发经验来看，这种开发模式与我用React开发的时候有着巨大的差异：我能从中节约好多时间。在用React的时候，你不得不在第一次编码的时候就把你的组件拆分红一个个的小组件，或者你能够直接把你原来的代码直接删了。在使用React的过程当中，当你编程编到一半，不得不由于应用逻辑改变而去改变你的数据流的时候，你极可能会由于没法清晰的看到完整数据流，致使了你花费不少时间去一次次地修正你的属性和状态，而且还要一次次重构你那些超级小的组件（可能以后根本用不到的小组件）。

在Vue.js中操做表单也是垂手可得的。双向绑定的数据流是Vue的一大亮点。即便是在复杂的场景下也不会带来任何问题，虽然第一眼看到watcher可能会让人想起Angular 1。当你拆分你的组件时，你老是能经过回调来单向传输须要改变的数据。

若是你想要使用一些预处理的工具，好比PostCSS、ES6，能够点这里。在Vue2里面，写一个公共组件已经成为拓展Vue的默认方式了。顺便值得一提的是，在组件内编写css，是一种看起来很棒的体验，它可以减小传统css的命名的层级问题，就像BEM同样。

Vue.js有简单的、高效的状态管理机制，好比用data()和props()，他们能在实际场景的使用过程当中发挥很大的做用。而且可以经过Vuex更好的分离状态管理，帮助咱们更有效的管理状态（Vuex在我看来是一个和React中的Mobx差很少的状态管理工具，一款把状态操做和状态分离的管理工具）。

VueJS的一些问题

一、最大的问题就是：对运行过程的模板错误并无提示。这一点和Angular 1 很像。Vue.js会在你的开发过程当中提供不少有用的警告，好比，当你错误的修改props或错误定义data()的时候，会有警告提示。但模板运行过程当中的错误是Vue的一个弱点，特别是屡次的堆栈处理并无什么用，这和Vue的内部方法有关。

二、Vue.js 2 还很新，它尚未稳定的组件社区，现有的不少组件也都是基于Vue.js 1 构建的。而且对刚入门的人来讲，可能很难从github的一些组件仓库里看出，这个库使用的是Vue的哪一个版本。但其实，这个问题也好解决，由于你几乎能够不用使用任何的附加库，就可以完成一个复杂的Vue的项目。你可能只会须要一些ajax请求的库。若是你并不关心同构应用的话，vue-resource是一个不错的选择，不然请选择axios。而且vue-router也是一个常常被使用的库，一个可以提供路由的很棒的库。

三、中文文档也在不少社区上都能找到，这很正常，由于Vue.js在中国也很流行（做者也可以说中文）。

四、是一我的写了一个项目吗？这实际上算不上是一个问题，可是也有人会在乎。尤小右是一个曾在Google和Meteor工做的男人，是他创造了Vue。Laravel曾经也是只有一我的在写的项目，但如今也已经取得了巨大的成就，因此你无从得知一我的写出来的项目有多强大。

使用Vue.js开发Drupal

免责声明：咱们没有打算很快的在Qwintry中使用Drupal 8，当咱们切换到更快更便捷的PHP和NODE框架的时候，咱们的历史遗留代码仍然使用Drupal 7。

由于咱们是用Drupal 7 构建咱们的历史系统（qwintry.com），所以对新框架的测试对咱们来讲很重要。我一点也不为咱们冗余的历史代码感到自豪，可是它确实稳定运行着，并为咱们盈利。因此咱们维护它，改善它，并为它增长功能。在这里我罗列了一些我已经用Vue + Drupal构建好的功能：

为复杂的订单业务设计的系统。包括给用户生成订单、对购买项的快速编辑。包括在加载的时候加载一些基本的JSON数据和保存一些数据结点。这些都没什么特别的，只是一些简单的数据回调。

两套REST的系统。咱们的用户不用在不一样的网站上重复登陆，咱们为特殊用户快速检查身份信息。这些操做都是基于咱们的用户管理系统。

我知道有不少后端开发者仍然停留在2010年的时代，而且也知道Drupal 7 的核心就是Ajax请求系统。

我可以想象，尝试利用多步Ajax请求来重构核心功能，是多么的复杂。以后想要去维护这些代码更是难上加难。没错，就是Drupal里面的ctools_wizard_multistep_form() 这个函数，你能够看看它的ajax是如何操做的。

而且，这些Drupal开发者都在抓紧时间学习不少流行的UI框架，可是他们可能比较惧怕学习流行的JS框架。我一年前也是这样。如今让我来告诉你，你很难找到更好的方式来改善你的接口，可是如今使用了Vue.js就不同了。你能够根据drupal_add_js把你的请求地址加入到模板中，而后就能够去放松了。你必定会震惊，客户端可以在你设置的钩子的回调里，这么容易的就拿到了纯净的JSON，表单也是同样的，这么方便的操做都是由于使用了Vue。

配合Yii2使用Vue.js

一个有趣的事，Yii也是一个中国boy作的 -- 薛强。因此你可能会发现Yii + Vue这样的技术栈的发音并非很难，由于这也是一个中国人创造的技术 :)

在咱们新版本的网站Qwintry.com（还没上线）的项目里，咱们选择使用Yii2，我相信它是PHP框架里最好最快之一。虽然它不像Laravel那样流行，毕竟Laravel如今已经席卷了PHP世界了，可是咱们在使用Yii2开发的过程当中仍然很开心（虽然咱们也时不时的去看看Laravel的发展，毕竟这个框架仍是至关不错的）。

咱们在逐渐减小使用Yii2来生成html 模板，后台把注意力集中在REST上，生成JSON给咱们用Vue构建的客户端使用。咱们的动态记录模型几乎都是先肯定好API，而后再构造数据。

相应的，咱们也有很规范接口设计，这就是咱们为何要花费大量的时间去构建好咱们的接口文档，即便这些文档只是咱们内部使用。

咱们的后端是用PHP7和最新的MySQL进行开发的，使用Yii2返回数据的响应时间和使用Node返回数据的响应时间没什么差异（我是说15-20ms左右的差异）。因此Yii2是符合咱们要求的。咱们能够想象用户使用咱们的Drupal项目的时候，速度会比原来提高10-20倍。同时，它也支持全部老版本的PHP库，可以让咱们很方便地利用人工去更好的维护咱们的代码库。

因此，Yii2 + Vue.js的开发搭配可以发挥出很大效用，而且可以让你的工做变得更愉悦。

咱们也在咱们的不少其余项目上使用Vue.js。

结论

这三个月以来咱们天天都在各类项目中写着Vue.js，让咱们受益不浅。三个月不用写后端代码，却全是JS的世界。让咱们对这个世界拭目以待 :)

我但愿在将来的16-24个月内，Vue能成为一个不可替代的JS框架。若是小右能让这个框架向着正确的方向发展，Vue至少能够成为一些前、后端团队核心框架。我认为，即便到了2017年，React依然还会是JS世界的主要框架，特别是，若是RN可以更好地管理本身，并保持它以往的节奏去改善本身的话。

原文地址： Why we chose Vue.js over React

---

本文对你有帮助？欢迎扫码加入前端学习小组微信群：