作者：SweetFlake Valorm
译者：百度外卖FE - 艾文
译者前言：最近前端框架大撕逼刚刚结束，我蹭蹭热度。抛开你抄我还是我抄你的这种在开源界who他妈cares的问题，一个团队究竟应该如何选择前端框架？作者结尾对于框架的总结不代表本人观点，实际上他说的有的东西我也没用过，不过作者对于技术选型的一些思路是我觉得值得一看的地方。
作者前言：Angular、React和Vue是如今最流行的三个JS框架，这篇文章我们只讨论Angular 1.x，Angular 2/4，React 15+（Redux）和Vue 2+。
前端是战场
在过去的6到8年里，Restful API（使用HTTP URL的接口）早就一统天下，它已经被大部分开发者接受并用于各种web应用，系统设计师们可以简单的在已存在的web或者业务层添加REST API去支持多种客户端设备，以便用户从服务器获取页面所需的数据。所以后端开发者们可以使用它们最喜欢的编程语言、框架或者技术栈去开发和维护他们的系统。
相反的，在前端这边则是完全不同的一副光景。在过去的10年里海量的JS框架被开发出来，虽然说简单的来看有更多的选择是一件好事，但是对于在这个“框架的战场”中工作的web前端开发者们来讲这简直是噩梦，因为他们需要做很多尝试才能决定究竟使用哪种框架，特别是当项目排期紧张的时候，技术leader或架构师通常会有很大的压力。尤其是当一个团队在发起新的项目时，他们也许打算尝试使用一些从来没用过的框架，这时候如何去选择往往会变得更加艰难。
如果团队的成员没有足够的经验和技术，那么使用新框架们通常会给项目带来一些比较大的风险，尤其是使用这些新框架往往还意味着使用ES6或者Typescript这种新语言。所以项目的领导者在做技术选型的时候需要为开发团队考虑，想想自己的团队成员能否很快的驾驭这些新技术和新语言，而这也就是为什么我们在这里决定比较这些框架的原因。
性能不一定至上
也许你看过很多框架之间的比较文章，这些文章通常会涉及到性能、编写语言、设计模式等等。实际上，很多web应用只是小型或者中型的应用，我们并不想要去做一个Google、Facebook或者Twitter。在我的观点里，当我们为一个团队选择自己的框架的时候，框架的性能并不是最关键的选择标准，至少不是第一优先级的。除去性能，我们还需要考虑框架的技术栈和社区生态发展，而这些才对一个团队的开发效率及其开发的系统的可维护性有更深远的影响。
框架的区别
说了这么多，让我们看看这些框架的区别。
使用的技术栈
酷的不一定是最好的
我们抛弃过很多第一眼看上去很酷的技术，Silverlight就是其中一个例子。我们不应该仅仅因为一个框架听起来很玄学、很厉害或者因为它是最新的就选择它。我们选择一个新框架应该是因为他确实能够解决我们的问题，或者让我们的效率更高，并且能够在长时间内保证质量。不要忘了接受新鲜事物是要付出成本的，我们需要权衡在新技术调研上花费的开销是否和其产出相匹配，还需要确定我们是不是在一个正确的时机在做这件事。
语言是障碍
当我们想要使用一个新的编程语言时，我们会在开发团队内部对其进行评估。尽管ES6和Typescript宣称与Vanilla JS兼容，但是当你阅读一段使用ES6或者Typescript的代码的时候，你仍然会对其中某些语法感到困惑，而这很明显的将会影响你学习新框架的效率。所以当我们使用新语言来编程的时候，一道不可忽视的学习曲线就摆在那里。
一些人抱怨说，就是因为这些使用新语言的JS框架的出现才会让现在写个网页比过去还麻烦。这里我们不去过多的讨论这些新语言带来什么不好的地方，不可否认的是这确实会对团队内的开发者们造成影响。如果你的团队成员有做.NET或者JAVA MVC的背景，选择使用ES6或者TS进行组件化开发的前端框架对于这些人来讲会有一个陡峭的学习曲线，而这还没有包括让人眼花缭乱的构建和测试工具。
难怪没有多少.NET团队会选择在Visual Studio上和Node较劲儿，特别是如果他们的团队成员没有Node.js经验的时候。使用新技术和新框架需要在整个团队范围内讨论其难点并找到相应的解决办法，这对于让团队员工能够心平气和的工作有重要帮助（戳我去看因为技术栈之争导致leader离职的事件）。
从哪儿开始
对于那些曾经使用web表单或原生JS写代码的团队，可以从Angular 1.x入手，开发一些小项目，因为某种意义上来讲，Angular和他们之前的MVC编程经历是十分相似的。
另一件事是，我不得不说使用Angular 1.x的web应用可以不接触任何Node.js相关的工具，如Gulp、Grunt或者Webpack等等。这会让没有相关经验的团队写起项目来感觉更舒服。而当你用Angular 1.x应付当前项目的同时，也算是给团队一个缓冲，让他们能够慢慢适应在未来使用Node.js工具。
对于那些有过Angular 1.2-1.4经验的开发团队，他们可以选择后期版本的Angular 1.x，比如Angular 1.5+，并且他们可以开始尝试让代码的风格从MVC转变到组件化的形式。在这之后，如果团队计划转向Angular 2/4，那么最好再做一些Typescript的训练。不过我的个人观点里，Angular 2/4的社区生态仍然稍显乏力。如果你想要用Angular 2/4去开发一些产品，这可能导致一些风险，因为这里面可能有很多的坑需要你亲自去解决。
对于那些有Typescript或者ES6经验的团队来讲，他们可以选择他们擅长的。他们可以花更多的时间在UI交互上，现在的这些前端框架有非常多的自定义UI，下个话题我们就讨论这些UI。
响应式UI库的支持
当我们开发一个实际中的项目的时候，我们需要使用一些流行的UI库，而非自己完成全部的样式。让我们看看支持Bootstrap或者扁平化设计的框架都有哪些。
如我们所见，Bootstrap 4和扁平化设计的情况比较接近。所以对于开发者们来讲这是个好事情，他们只要去选择他们喜欢的就好了。
实际上，Github上有海量的UI库或CSS框架，其中很多都是平台中立的，也就是说，不论Angular还是React或者Vue使用它们都没问题。然而现实中，整合其他的库进你的项目中，总是会耗费一些功夫。记住，整合那些平台中立的框架时，你需要注意他们的依赖以及构建和测试工具，比如webpack或者yarn。
稳定的API
和Angular 1.x完全不同，Angular 2简直是彻底改头换面了。Angular 4也带来的一些破坏性的改变，这导致过去的一些Angular 2的第三方依赖不能用了。对于我们来讲，由于Angular 4的API还处于频发而积极的发展阶段，所以我们不会用它来在实际中开发代码。Angular团队宣称说，他们想要修复Angular 4中所有Angular 2的bug和问题，并将Angular 2中所有的内置库都同步到Angular 4中，这是一件工程量浩大的工作，需要很长时间来完成。如果你的项目在使用Angular 1.2-1.4，我建议你继续使用它而不要升级，直到Angular 4彻底完工再考虑。
另一方面，近期React-Redux比React-Flux更流行，但是这不意味着前者比后者更好。我的个人观点是，React-Flux更接近React的设计思想。如果你准备使用React-Flux，你可以一直使用它。
对比Vue 1，Vue 2有一些破坏性的改变，从Vue 1升级到Vue 2需要根据官方指导做一些操作，看上去好像不是那么简单。而Vue 2现在的状态比较稳定，可以用来实际开发。
如何比较
为了更好的比较这些框架，我使用它们制作了一个小型的真实的web应用，包括了需要身份认证的后端API服务，并使用了一些Bootstrap或扁平化的UI库。
你会发现其中没有使用Angular 1.x写的项目，这是因为我的团队和我已经使用Angular 1.x做了太多的项目。我们已经非常了解Angular 1.x，包括它值得信赖的社区生态。
另外，Angular 1.x使用原生JS，这意味着你不需要使用任何工具去编译Angular 1.x的应用，所以这对于使用ES6和Typescript的框架来讲有点不公平，因为在构建工具和步骤上Angular 1.x要比其他的都简单。我这里再一次提到Angular 1.x是想说，这个框架对于那些从传统MVC过来的团队来讲是一个非常不错的选择，它能够让团队平滑的接受新时代的前端代码编写方式。
我们做的项目和它们的截图
不同框架做的项目的比较
让我们来看看这些做好的项目，基本上他们的功能是类似的。
功能
- 使用Restful API的身份验证和Token
- 用户信息的创建、读取、更新、删除
- 订单的创建、读取、更新、删除
- 包含两个图表的信息统计页面
- 使用扁平化设计（Angular的项目包含了Bootstrap）
通过表中的依赖项（Dependencies，不包含测试及发布工具），代码大小（Code Size，包含了一些自定义CSS代码，但没有图片）以及开发时间（Effort，不包含学习时间），我们可以发现基于Vue 2框架的项目比另外两个要简单非常多。
实际上我的观点是这样，如果要开启一个新的项目，我最喜欢使用的是Vue 2。这个框架有Angular和React两家的优点，同时它还解决一些两家都有的问题。
Vue.js使用虚拟DOM，这避免了Angular 1.x中的脏检查，以及Angular 2/4中复杂的编码模式（Observale和RxJS等）。
Vue.js在处理数据绑定和消息传递上比React要容易得多。它的模板方便直接，看上去好像一个传统的HTML。将HTML转变成Vue模板是一件非常容易的事情，特别是你需要定制一些自己的样式的时候。Vue的模板和指令类似于Angular。
Vue.js不只是酷，而且优雅、简单。我十分确定如果你有Angular或者React的经验，你只需要花几个小时就可以上手。一旦你开始使用这个框架，你就不会放下它再用别的。它的官方路由系统也很易用且稳定，比Angular和React的Router可靠的多。
总的来讲，React的扁平化UI库不是像Angular或者Vue的那么便利。JSX的编码风格需要将CSS和HTML都转换成JSX。实话讲对于React的JSX我不是很信服，因为这不是最终的HTML和CSS。和其他的框架比起来，这有点麻烦。我们不能简单地从浏览器的开发者工具中调试好样式代码然后直接复制过来就用，所以你可能需要更多的时间去美化你的页面。
Angular的扁平化库只有比较有限的一些组件。如果是做一些实际的项目，你可能会需要添加一些其他的UI库。
最后我想说，Vuetify是我目前用过的最好用的扁平化UI库。
项目地址
Angular 4 CRM — https://github.com/harryho/ng4crm
React Redux CRM — https://github.com/harryho/react-crm
Vue 2 CRM — https://github.com/harryho/vue2crm
总结
在总结之前，我们不得不注意到这个世界在一直发生变化。也许当我在写这篇文章的时候，一些框架的问题被修复了，一些问题更严重了。我们必须时刻审视着我们当初的选择并尽可能快的调整它们，尤其是当我们发现这些技术框架带给我们的负担大于收益的时候。
- 从表单时代过来的团队，建议你们使用Angular 1.4并且花点时间熟悉一下Node.js相关的工具。
- 熟悉原生JS的团队应该开始学习ES6或者Typescript，因为早晚所有的浏览器，包括移动端的设备都会支持ES6和Typescript。
- 熟悉ES6或者Typescript的团队可以选择任何一个你们喜欢的框架，你们需要花更多的时间去考虑使用什么UI库。
- 使用React-Flux可以继续用下去，或者换成React-Redux试试，这可能会减少一些代码复用，不过我不认为这是个大问题。
- 对于React的新手来讲，我建议你使用React-Redux，因为它有更好的社区支持。
- 个人观点，别在Angular 2上浪费时间，因为Angular团队希望大家尽快地使用Angular 4，而且他们正在计划在Angular 4中修复Angular 2的问题。
- Angular 4和及其生态仍在发展，不过如果你想在实际开发中使用它们，还是需要多加小心一些。
- Vue 2非常赞，你可以在下个项目中使用它。
