前端框架技术选型

刚开始学习前端的时候，SPA（单页面应用）还没有现在这么流行，可以选择的框架也很少。现在，随便打开一个与该技术相关的网站或应用，只需要简单地看几页，就可以看到丰富的与前端框架相关的文章Angular、 React、Vue。

当你还是一个新手程序员时，可能从不考虑技术选型的问题，因为不需要做技术选型和更换架构，觉得框架丰富和自己没关系，反正还是用现在的技术栈。等到真正需要技术选型和更换架构的时候，依靠之前的基础知识，仍能很轻松地上手。

可是到了需要考虑选型的时候，就会发现存在各种各样的问题。如果选择A框架，则使用过B框架的人可能会有些不满。如果选用B框架，则使用A框架的人会有些不满。选择一个过时的框架，则大部分人都会不满。技术选型考虑的一系列因素如图所示。

技术选型的影响因素

选定一个前端框架时，我们还要考虑的因素有：

• 框架是否能满足大部分应用的需求？如果不能，那么需要使用哪个框架？
• 框架是否有丰富的组件库？如果没有，我们的团队和组织是否有独立开发的能力？
• 框架的社区支持怎样？在遇到问题时能否快速方便地找到人解答？
• 框架的替换成本如何？假如我们的新项目将使用B框架，那么我们还需要额外学习什么内容？

每个问题都不是一个简单、独立的问题，它们都值得我们深入地探索一番。

如果需要选择一个新的框架，而你作为一个前端的技术负责人，那么需要评估哪个框架更适合我们。

恐怕不是一句话或者几句话就能解决这个问题的，我们需要组织讨论会，进行各种框架的对比分享等。待讨论的事项如下：

• 团队成员能否快速掌握该框架。框架拥有自己的设计思想，它可能有更适合的用户群。如Angular其总体的架构思想依赖注入、强类型等，更适合那些有后端经验的开发者。如Vue框架更容易上手，适合初学者进行Web开发。而对于一个没有经验的新手，直接使用Angular框架，则需要较长的学习时间。

• 框架的生态是否丰富？是否拥有我们所需要的功能组件？技术选型要考虑的一个因素是生态系统，即是否有对应的可选择的组件、库是否足够丰富。

• 不同框架对于不同浏览器的支持程度如何？由于实现机制的不同，框架会对浏览器有一定的要求。

• 框架的后期维护成本和难度怎样？项目的维护难度与其花费的时间和代码量是成正比的，即时间越长、代码量越大，维护成本也就越高。越是大型的项目，到后期也就越难维护；而小型的项目，则不存在这样

的问题。因此在选择框架的时候，可以考虑项目的规模，越有可能变大的项目，选择一个大而全的框架，往往会更容易维护。

• 是否能以最小的代价迁移现有的应用？当我们选定A框架时，往往后面编写的代码都难以迁移到B框架。比如我们使用React编写的组件，无法直接在Angular或者Vue中使用。尽管随着Web Components技术的发展，跨框架使用变得越来越有希望，但是这也意味着我们需要做大量的适配。

此外，还有一个场景是，当一个框架的API不断变化并且向下不兼容的时候，就会带来额外的维护成本。一个典型的例子就是React Native，在笔者使用React Native开发一个应用的过程中，中途更新了版本，由于API的变更影响了第三方组件，并且额外带来几天时间的升级成本。在这个应用的生命周期里，我们还需要不断地追随这部分变化。

框架的大而全还是小而美

大而全，顾名思义框架大、功能又全，开箱即用。相对于小而美的框架而言，它可以提供给开发者一个完整应用的所有要素。也因此，在提供大量功能的同时，体积上也比较大，所需要了解的知识也比较多。另外，大而全的框架还有着集中统一的详细文档，能提供与编程、架构相关的规范。这种框架带来的明显问题是：上手成本高、框架限制高。比如Angular是一个大而全的框架。

小而美的框架灵活性比较高，可定制度也比较高。我们可以寻找合适的组件，使用到我们的系统上，使它更加灵活。哪怕某天，一个组件不好用，也可以进行相应的修改，或者重写。即使是核心的前端框架出现问题，如出现版权问题，也能切换到一个合适的替代框架上。相应的组件部分，也可以复用，而不需要重写。但是对于一个大而全的框架来说，则相对比较困难，一旦出现问题只能尝试使用新的框架。

在了解了大而全或是小而美之后，让我们继续了解一下Angular、React、Vue三个前端框架，以及笔者认为的一些合适的使用场景。

React

React是第一个采用VirtualDOM的、流行的前端框架。传统的DOM操作是直接在DOM上操作的，当需要修改一系列元素中的值时，就会直接对DOM进行操作。而采用VirtualDOM则会对需要修改的
DOM进行比较（DIFF），从而只选择需要修改的部分。因此，对于不需要大量修改DOM的应用来说，采用VirtualDOM并不会有优势。除了在编写应用时不需要对DOM进行直接操作、提高了应用的性能，React还有一个重要的思想即组件化，即U1中的每个组件都是独立封装的。并且，由于这些组件独立于HTML，所以它们不仅可以运行在浏览器里，还能作为原生应用的组件来运行。组件之间可通过属性和事件来进行通信。同时，在React中还引入了JSX模板，即在JS中编写模板，而且还需要使用ES6。

令人遗憾的是，如我们在6.4.2节所述，React只是一个View层，它是为了优化DOM的操作而诞生的。为了完成一个完整的应用，我们还需要路由库、执行单向流库、webAPI调用库、测试库、依赖管理库等，这
简直是一场噩梦。因此为了搭建出一个完整的React工程，我们还需要做大量的额外工作。

选择React而不是别的框架还有一个重要的原因：React的思想不局限于前端领域，它还有React Native、React VR等，它们可以在不同的平台之上运行类React的View层。使用与React语法类似的React Native，我们可以编写出原生的移动应用。此外，我们还可以在Web应用程序与iOS、Android应用程序之间，共享大部分业务逻辑。

Angular

Angular是一个大而全的框架，它提供了开发一个完整应用所需的所有要素。同时，作为背后的开发公司，Google有一个适用于Angular框架的Material Design Ul库。我们结合Angular框架及UI库就能完成大部分的前端开发工作。

Angular官方还提供了开发应用所需的脚手架，包含测试、运行服务、打包等部分。前端开发人员使用官方的命令行工具就可以快速生成Angular应用：ngnewmy-dream-app。在这个官方生成的项目里，可以直接运行和构建Angular框架，而不需要像React或者Vue一样，寻找一个合适的脚手架。

在最开始的两三年的时间里，使用Angular来作为项目的前端框架的企业较多，原因主要是Angular的规范性。Angular不仅提供了一个前端框架所需要的开发要素，还提供了一系列开发规范和指南。这些规范有些被写在官方的文档上，有些以配置代码的形式存在于项目中，有些则存在于CLI（命令行工具）中。这些严格的规范更适合于大公司的规模化运作，尤其在非互联网行业的传统公司里，比如金融、保险等。Angular大而全的体系方便进行项目管理，既能降低风险，又不会在制定开发规范上花费太多时间。尤其是那些后端出身的部门经理，更容易上手Angular的框架。

Vue

对于没有Angular和React经验的团队来说，Vue是一个非常好的选择。Vue借鉴了Angular和React的一些思想，在其基础上开发了一套更易上手的框架。它既不像Angular需要理解大量的基础知识，也不像
React在使用VirtualDOM的同时需要学习JSX及其相关的语法。

当然，使用Vue也需要学习基于Template的语法。两者有颇大的区别，但是很显然，使用React需要重写之前的业务逻辑，而不能嵌入使
用。正是这一点区别，决定了Vue在针对传统多页面应用的时候更有优势
我们可以将Vue嵌入应用中，而使用React或者Angular基本意味着
重写整个应用。
Vue对比于Angular和React框架的一个优势是，对于传统的多页面应用，直接引入vue.min.js就可以使用了。直接拿代码库就可以发布了，不需要打包。对于那些需要迁移前端框架的项目来说，它可以以一种渐近式的方式来进行，在成熟后便可作为单页面应用框架来开发前端应用。

Vue的开发者尤雨溪是中国人，框架本身提供了大量丰富的中文文档，这也为Vue的发展和使用带来巨大的优势。Vue框架适合于需要快速上手、上线的应用，还适用于迁移传统的多单面应用。Vue框架，它可以满足快速上线的需求，同时在后期也可以演进成单页面应用。

选型总结

在这么多框架中，到底如何选择呢？如果是一个大中型的企业级应用，那么基本上会选择使用 Angular 或 React。统一的规范和设计模式对于大型团队来说可代替无数的沟通成本，并且不需要花费大量的时间进行讨论一使用哪个基础的路由、状态管理器等。就像康威定律一样，它也更符合大型组织内部的架构设计。

对于移动应用项目来说，如果采用React Native，那么React在当前是一个更好的选择。对于一个中小型项目来说，如果团队的新人比较多，并且基础比较薄弱，那么Vue就很适合开发人员使用。并且，它也可以使用Vue语法的Weex来开发移动应用，只是这个Weex框架并不像React Native那样被大量地采用。