项目的框架级技术选型类似于为篮球队裁缝战术，选择适合开发团队和团队成员规模的技术栈和能力，并有针对性业务和项目能够帮助团队赢得更多的技术，这是每一个软件项目顺利进行的前提，也是业务长青的有效保障。这里说说选择一个新的前端项目合适的技术模型，对比一下Angular2和Vue2，这两个都是去年发布的release版本（下面没有特别说明的，Angular就是Angular2，Vue就是Vue2），而不要做鱼和熊掌之间更好的选择，而是从技术本身、对应的项目和开发者的角度，帮助工程师选择最适合自己业务场景的利器。技术开发Developer/Team2016年发布，核心由谷歌开发，部分周边生态环境组件由Netflix、Babel社区、微软等相关开发者开发。参与人数比较多，后期谷歌不维护这个项目的可能性比较小，但不排除部分框架用到的第三方组件（如zone.js）可能缺失后期维护。2016年版本由YouYuxi开发。目前作者已经全职开发Vue，但不能完全排除后期作者停止维护的可能，目前问题很少，上报的bug都已经在业界得到修复。目前国内推广情况不明。国外比国内强，物资比国内多。国内推广情况较好。滴滴、阿里等很多团队都在用，对外推广也不错。文档资料提供中文文档（翻译质量一般），YouTube提供很多中文资料，资料比Angular少。目前还无法准确评估这两个框架未来的维护情况，但基本上可以确定的是，框架的生命周期不会短于我们大部分业务的生命周期。Angular的缺点是，除了核心，生产环境依赖的系统如core-js、rxjs、zone.js都不是谷歌主导，可能存在质量问题，Angular已经发布了rc的Angular4版本（主版本跳过Angular3），预计每六个月更新一次主版本。虽然相关开发者承诺尽可能向下兼容，但后续频繁升级主版本对项目的影响还不得而知；Vue由于作者是中国人，在国内推广得很好，口碑很好。作者对GitHubissues的清理也很快，坑的也会相对少一些。后来还和阿里合作，成为Weex的官方框架，Angular目前在国内。情况不是很清楚，主要原因可能是中文资料量远小于英文资料。从国内使用和社区发展来看，Vue更胜一筹。语言官方使用Typescript语言，官方提供compiler-cli直接将Typescript的框架代码编译成Javascript的AST语法树，属于深度支持TypescriptES6+语言的开发者微软（AndersHejlsberg，领导Typescript开发的，也是C#语言项目负责人）ECMAScript标准委员会制定标准，各浏览器厂商实现语言特性静态类型，提供静态检查，是现有ES6+的超集。官方编译器可以支持编译到ES5、ES6，贴合工程团队的需求，适合团队使用，学习成本低动态类型，更灵活，目前标准委员会每年更新一次标准，增加新特性，通常使用Babel和插件编译成ES5IDE/editor支持主流IDE/编辑器支持，官方推荐主流IDE/编辑器支持VSCode。IDE的新语言特性优于文本编辑器。其他开发语言能不能也支持Javascript和Dart，这两种语言的官方文档也都支持Typescript，但是文档比较少为了避免前端组件缺乏一致的管理方式，重新发明wheel，解决快速迭代中多人协同开发导致代码逐渐混乱的问题。Javascript的动态类型增加了重构的难度。我们希望引入静态语言。通过类型检查让数据更清晰，通过接口规范开发行为。Angular通过默认引入Typescript比Vue做得更好。虽然Typescript本身是微软的产品，但是无论是编译效率还是用户体验，都比现在的Javascript要好。在编写ES6+代码时，可以避免很多因Babel插件质量问题而经常出现的陷阱。ng-cli工具提供了开发阶段搭建前端服务器服务、代码生成、查阅文档、测试、构建部署流程等一系列说明。与vue-cli只提供基本的项目初始化和构建功能相比，ng-cli更好用。在调试工具层面，Vue做得更好。vue-devtools集成了Vue的状态管理工具vuex，在使用Angular的状态管理方案ngrx时，需要配合ReduxDevToolsExtension。除了ng-cli，angular2-webpack-starter还提供了完整的Angular+Webpack种子工程。我们也可以根据业务调整具体的建设流程。设计从设计的角度来看，Angular提供了一个不可动摇的全面解决方案，基本上照顾到了开发过程中的每个节点。其Form支持、DI、测试过程在开发体验上都优于Vue，但Angular为了追求全面性，也无法回避构建后的体量问题和整个框架的侵入性。Vue作为一个渐进增强的框架，一开始并没有在使用场景和模式上限制用户，而是通过官方扩展和第三方扩展逐步提供更复杂的需求场景的解决方案，同时也为用户提供了选择的余地。性能我们在Vue官方文档上截取了两个框架的性能对比报告。比较去年8月份发布的Angularrc版本和同期Vuebeta版本不同操作的性能。可以看到两个框架都非常快，Angular和Vue在大部分操作上处于同一个数量级，Vue在一些指标上略胜一筹。在内存使用上，Vue优于Angular，但Angular框架本身提供了很多特性，Vue在开发过程中引入了vue-router、vuex、vue-class-component。在逐渐发展成Vue全家桶的过程中，会逐渐增加对内存的需求。开发模式从学习曲线来看，Angular比较陡峭，Vue相对平缓。在WebComponent、PWA上，Angular比Vue走得更远，更适合未来的标准，面向谷歌自己的技术栈。在可以开发的应用的全面性上，Angular和Vue相差无几。弹性在业务发展中，技术选择不仅要满足当前业务需求，还要考虑业务的现状，是刚刚起步，持续发展，还是稳定维护。考虑到业务后期可能出现的增长，这就要求我们选择的技术具有一定的灵活性，能够随着业务的发展而规模化，避免后期维护成本高、扩展困难。这里截取了前端框架的选择和迁移统计。y轴代表迁移前的选择，x轴代表迁移后的选择。表中颜色越深，从选项A迁移到选项B的情况越多。可以发现，最流行的迁移目标是React。迁移到Angular的案例比Vue多。选择迁移到Vue的大部分是React用户（相反，从Vue迁移到React的用户也有一定数量）；并且很少有从Angular或者Vue迁移到其他框架的案例，证明这两个框架在当前行业中有足够灵活的业务场景。这里我们以review和order的内部数据系统为例。我们针对不同的前端使用场景对系统的使用频率和要求进行打分，从0到10分。分数越高，对应场景的要求越高，反之亦然。我们发现我们的需求集中在图表绘制、组件管理和表单提交验证上。大量的组件对我们的组件管理方式提出了更高的要求；在现有系统中，我们同时依赖highcharts和echarts，但是我们会逐步将图表组件迁移到echarts。echarts目前有vue-echarts，highcharts有人做了angular2-highcharts。开发人员目前每天有1个人力用于食品订购数据系统。多人协同开发的要求比较低，对开发效率的要求比较高。目标是尽量减少人为瓶颈的发生。结语首先，从技术上对比Angular和Vue，两者都是值得长期投资的技术。Angular提供了一个统一的解决方案，它涉及浏览器、服务器和客户端。这种统一的解决方案的优势在于，框架提供了几乎任何场景下的标准化行为，而Angular使用一种侵入性强的编程范式标准化了所有使用该框架的开发人员的开发行为。更偏向于工程化，更适合大型项目中的多人协作。同时，框架本身包含标准并面向新功能。未来有很大的发展空间。缺点是这个统一的解决方案不能由谷歌单独提供。除了开发Angular的核心模块外，Google在异步处理、状态管理、外围工具等方面使用了大量的第三方库或组件。这些库和组件的行为是否会出现问题，后续的开发很难预测，潜在地增加了风险。这些第三方库和组件也可能会降低应用程序性能。Vue的切入点是这个框架可以不同程度的使用，核心组件可以单独使用，还可以加入状态管理，路由管理。从部分使用Vue到全站使用Vue开发，为开发者提供了更多的选择，也借鉴了不同的框架，增强了自己对Vue独有的优势。这种简单灵巧的做法非常适合项目前期的快速迭代。性能上无重大缺陷。随着项目的发展，性能不会成为明显的问题。Vue的潜在问题在于，由于提供的开发选项不同，在多人协作开发的情况下，不同的开发人员可能会以不同的方式处理Vue的使用和场景，并且随着项目的增长，“快速”特性可能会在工程和代码管理，但是和Angular提供的DI等功能一样，Vue需要程序员手动控制才能实现类似的功能，这就带来了潜在的代码管理问题。目前，虽然业界使用Vue的场景很多，但在稳定发展期几乎没有大规模上线业务。使用Vue后，项目规模变大后，我们需要考虑如何处理Vue在项目中的地位，如何组织代码。在我们的业务和人力资源方面，我们对数据平台架构的规划是多端、多层次的。架构层为应用层服务，应用层为用户服务。对于用户层，新项目面临频繁逻辑调整的可能。也就是说，对于应用层，我们需要一个灵活的框架，能够适应快速迭代，而应用层的各种设备和环境，也要求我们至少要考虑性能。目前已有的组件和库也希望新框架能够更好的兼容，提供现成的解决方案。这种情况下推荐Vue。随着后面应用端的发展，Vue可以保证没有性能瓶颈，也让我们后面可以引入更多的Vue解决方案，形成Vue全家桶或者去掉Vue，使用其他解决方案的空间。至于架构层，其开发速度可能没有应用层快。它对业务的需求是稳定的，可以增量开发。尽量避免推翻和重新发明应用层。同时，它对性能的要求也明显没有应用层那么高。这种情况下，我们需要单独区分。比如我们需要为应用层做一个通用的配置系统，配置应用层的UI组件，那么显然这个系统的组件框架应该和应用层保持一致。对于自助查询平台或者其他项目，我们可以利用Angular为后期的技术栈做技术储备。
