JavaScript/web 应用框架并不太好总结 我们该用什么样的框架？

　　是该读些评论和做一些总结的时候了。当我们开始写这个 系列博客 的时候，我们知道 Javascript/web 应用框架并不太好总结。我们努力对这个不可回答的问题作出回答： 我该用什么样的框架?

　　在这篇文章中，我们将对这个系列中所提到的每款框架做一个总结，包括我们所认为的强项和弱项。另外，我们为你留下了一些值得思考的问题。

　　我是否需要使用框架?

　　如果不尝试回答这个问题就是我们的失职，这越来越成为社会上某些人的口头禅，在网络平台上的争论也已经发展到犹如不需要额外编写 API 能更简单创建 Web 应用那样的地步。就像本系列中所有的内容一样，我们的回答也大都是依据这些内容。

　　虽然无框架也能正常工作，但是，这也是有代价的。那些主张无框架手写 Javascript 的人，那些通常会被我们认为是斯德哥尔摩综合症(情感上会依赖他人且容易受感动的人)的人，忘记了网络平台上有多套快速发展的 API ，至少有三种不同的技术，三种截然不同的语法。web 平台规范并确定了超过 12000 个 API，事实上浏览器中的维恩图也显示了这些巨大差距。

　　如果你是一个有着深厚技术和经验的人，确实可以坦诚的不使用框架。但你团队的其他成员呢?你手下的那些人呢?或者当你的决定把你自己陷入困境的时候呢?这种情况下，我们将会看到一个不用框架的团队在展开冒险，最后他们会发现自己创建了一个需要自己着手维护的框架。接着就会出现寻找人才的问题，他们不需要知道框架是如何工作的，只需要寻找会调用网络平台 API 的高级技能人才或者一些自称有经验的人才，最后却发现缺少利于团队发展的技能深度和经验。

　　团队应该避免虚假等价( false equivalence )的陷阱，很显然，在 web 技术的应用方面具有创新性的公司在不断提高他们的市场价值和竞争力，Google、Facebook 和 Netflix 公司都是很好的例子。但是大多数公司不是这样，他们应该承认这一点。

　　Angular 2+

　　有什么优势?

　　Angular 2+ 的最大优势在于它的流行程度。也有人认为它和 Google 密切相关的名字，会影响团队使用它。Angular 1 的迅速流行是因为那些来自其他交互式应用程序开发环境的人会发现对于开发单页面 web 应用程序具有相似的模型-视图模式。通过对 Angular 1 进行现代化演变和重新构建框架的某些部分，Angular 2+ 已经真正的爆发了，大量的正式的和非正式培训机构数量都让人印象深刻，开发者有很强的市场竞争力。对于用户来说它有一套用于构建用户界面的丰富组件，这也是本系列中少有的几个框架能够做到这点。

　　有什么弱点和挑战?

　　我们觉得 Angular 框架着重于在单个页面应用程序中创建用户界面并没有处理构建完整的 web 应用这个更大的关注点，如果不及早确定下来，这将会导致整个项目难以维护，在实际项目中，运行时提供不属于核心框架的技术往往让人觉得不可思议，这大大降低了 TypeScript 对最终开发者的价值。

　　未来将何去何从?

　　Angular 5 刚刚发布，这看来是 Angular 已经成功的印证了快速发布版本的承诺，在 Google 的持续支持下，Angular 会越来越成熟。

　　像许多的大型组织一样，Google 具有多重(分裂)的人格，从外表上看，Angular 团队和那些专注于浏览器标准的团队之间显得很和谐。但我们的观点是，和谐只是一层薄薄的窗户纸。Angular 团队对于 web 组件和渐进式 web 应用没有一个真正解决方案。我们认为，业界普遍认可的标准将会在 Angular 框架中会逐步实现，这将会影响到如何更好的构建 Angular 应用将成为一个中/长期的风险。

　　何时选择 Angular 2+

　　如果你需要在一个大型的框架内获取技术资源，框架内的技术通常很容易移植;或者你需要在框架中训练开发人员，并且还要有一定的信心，他们会在短期内获得一定的开发能力，这样的话你可以考虑 Angular 2+ 。需要注意的是 Angular1(angular.js)与 Angular2+ 是截然不同的，其中的应用、技术和经验不能直接移植到 Angular2+ 的开发中去。

　　如果你的 web 应用能够很好的转化为标准的模型-视图模式，那么你也可以忽略其他直接考虑使用 Angular2+ 。

　　如果你对 Google Material UX 设计模式满意，那么 Material Angular 是遵循该模式的一种快速、简单且可靠的方式。

　　React + Redux

　　有什么优势?

　　React 和 Redux 的最大优势在于它们相对简单和专注。 做一件事情并把它做好 是非常困难的，但这两个库都很有效地完成了它们的目标。虽然对于某些状态容器方法可能是外部的，但大多数开发人员还是可以轻松掌握概念，并了解单向数据体系结构的好处，简化大量的用户界面应用程序。

　　有什么弱点和挑战?

　　React 和 Redux 最大的弱点不是它们是什么，而是它们不是什么。要构建一个功能丰富的 Web 应用程序，你需要许多功能，一旦脱离 React 和 Redux 和其他一些库的核心，你将发现一个非常分散的社区，拥有无数的解决方案和模式，不容易整合在一起。

　　因此，虽然 React 和 Redux 都是非常专注的库，但缺乏经验的团队还是会很容易地生成不可维护的解决方案，而不是意识到他们所做的选择会导致性能不佳或错误。 即使有经验的开发人员也可能意识到，一个松散的架构或惯例可能会在未来困扰他们。

　　假省钱 是一种对自己的欺骗，组织范围内采用 React 和 Redux 将轻松降低无效率问题。 没有其他库和模式的广泛约定和标准化，标准化 React + Redux 比较于我们正在采用的 JavaScript 来编写我们的应用程序效率要高。

　　未来将何去何从?

　　Facebook 和 React 最近从繁琐的 附加专利 纠纷中抽离，他们认识到，就像其他项目一样，更广泛的社区能够提高自己的声音。 我觉得这有助于 Facebook 意识到他们还不能 更好地了解我们， 相信我们 来引导项目。 希望这将继续贯穿项目的特点和技术方向。

　　很难预测 React 和 Redux 的未来。 但是，将库集中在一起，确实会显着提高适应性，大多数React + Redux 模式都会促进一个分离的体系结构，从而可以轻松地进行重构和迭代。 两年前，大家喜欢的还是React + Flux，但整个社区很快就拥抱了Redux。 思维或模式的其他重大转变可能很容易被采纳。 这种关键能力可能会持续到未来。

　　何时选择 React + Redux ?

　　如果你很少需要 手把手指导 ，并且正在寻找更好的库而不是全面的框架，那么 React + Redux 可能是正确的。 在这一过程中，你不仅需要对你的团队和组织的能力保持诚实，还要在你的初始开发过程中，以及在整个应用程序的长期维护过程中保持诚实。

　　Vue.js

　　有什么优势?

　　渐进式构建能力是 vue.js 最大的优势，vue 有一个简洁而且合理的架构，使得它易于理解和构建。

　　vue 有一个强大的充满激情人群的社区，这为 vue.js 增加了巨大的价值，使得为一个空白项目创建一个综合的解决方案变得十分容易。

　　有什么弱点和挑战?

　　在模型-视图应用程序和状态容器类型的应用程序之间的互相转换可能会令人感到困惑，即使没有完美包含一个模式到另一个模式的完美转换，但让人感觉希望能维持两个模式的相关性。对于那些期待 vue.js 完美解决方案，并可能导致难以维护不一致的应用程序的人来说，这至少是令人困惑的。

　　一个更大的挑战是 vue.js 依赖于一个单独的人，很明显，其他的项目基本是由一个组织提供支持，但这让人感觉更加有意义，虽然它有一个强大文件的社区和许多有创新的新增项目，但是 vue 核心的开发基本落在一个人身上。

　　我们很高兴看到 vue 更加容易接受新兴的标准方法，但是它的类似于 web 组件的模式，而不是真正的 web 组件，这可能是 vue 所得不偿失的地方。

　　未来将何去何从?

　　虽然 vue.js 有相当广泛的应用，但也很难预测在中期发展中这个势头能持续多久，它不是由一个商业组织直接支持并维护，因此，这很大程度上依赖于维护者的生存能力和继续维护下去的愿望来决定。

　　它也表现出了一定程度的语言适应能力，并且随着某些模式的落伍和失宠而继续保持自身语言的现代化和时代性，目前没有迹象表明 vue.js 架构将来无法适应进一步发展。

　　何时选择 Vue.js?

　　如果你有一个传统的 web 应用程序，并需要一个强壮稳健的应用程序层，那么 vue.js 可能是一个很好的选择，它有清晰的模式，即使没有经验的团队也能正确或者错误的使用它。尽管 vue UX 框架没有开箱即用的功能，但在 vue.js 上也能大量持续性构建应用，这将有利于你的项目。

　　Dojo 2

　　有什么优势?

　　Dojo2 专注于带来更多构建在状态容器体系之上的动态组件的体验模式，填补了 react+redux 等框架的许多空白。

　　Dojo2 也知道它不单单只是在自己的生态圈发展，通过包含 web 组件导入和导出功能，也意识到需要支持不同的应用实例，但它依旧提供了一个结构化和固有的框架价值，Dojo2 的核心基础仍然是专注于提供交互性。

　　Dojo2 觉得它提供了大量重要的功能和解决方案，这对于构建完整的 web 应用是十分重要的，对于其他大多数框架而言这并不是重点。提供一个国际化系统和广泛的易接入性的模式也是其中之一，同时也提供一个主题系统和演进模式，用以确保不仅能为 Typescript/JavaScript 提供良好的代码开发，也能像 css 那样管理资源。

　　Dojo2 专注于提供一个结构化和符合人体工程学的开发环境，通过使用 typescript 和其他开发模式，它试图提供安全的防护机制去引导新手开发人员，通过专注于提高框架开发效率和开发安全性，旨在让开发团队能够快速交付更好的 web 应用程序。

　　有什么弱点和挑战?

　　有争论的是，通过进一步延长 Dojo2 的发布时间的做法是否是在阻碍框架的发展，反观其他项目由于其资源的扩大能够继续发展和快速迭代，导致 Dojo2 目前明确的处在一个拥挤的竞争环境之中。

　　这也许是一个潜在的发展机遇和挑战，同时希望能够在灵活性和交互性上而不是别的特殊理由去使用 Dojo2 。

　　未来将何去何从?

　　Dojo2 将是未来优秀 web 框架之一，它将继续努力为构建可扩展性的 web 应用程序提供清晰的模式和指导。随着新标准的不断出现，Dojo2 将进一步努力去在框架中实现新的标准方法，继续尝试扩大框架的开放性和交互性，创造适合更多人使用的解决方案。

　　何时选择 Dojo2?

　　如果你想采用一个灵活的、现代的、响应式的 web 应用程序架构，并且你需要很多智能化的默认设置，那么 Dojo2 将是一个不错的选择。不用去拼凑和构建一个管道，并且为你提供更高阶的命令模式让你可以更加专注的开发项目，更加确认它是直接为你可以直接生产开发所准备的。另外，如果你了解 typescript 的优势，Dojo2 会十分严谨的使用 typescript 来管理并提供一个稳健的开发者开发环境。

　　Ember

　　有什么优势?

　　ember.js 可能是最顽固的主流框架了，这是它的最大的优势。不仅有而且只有一种正确方法创建 ember.js 应用程序。ember.js 更像一个用户期望提供商长期提供技术支持和技术维护的产品或者平台。ember.js 自身提供了自家平台全面的版本管理、升级更新工具和强大的技术指导和摒弃依赖 API 的工具。总的来说， ember.js 很成熟。

　　ember.js 多年来已经证明了自身框架发展与现代标准发展基本保持一致，同时也不会过早的放弃对传统浏览器的兼容。

　　ember.js 有一个清晰合理的架构来全面构建一个 web 应用程序。

　　有什么劣势和挑战?

　　ember.js 可能是最顽固的主流框架这一点上，也是它的最大的劣势，虽然社区十分开放并且容易吸纳，但是它的发展也逐渐偏离了正确轨道已经成为一个挑战性的急需解决的问题。

　　拥有丰富的第三方库也是一个很大的挑战，但是由于官方没有开箱即用的 UX 组件，用户很大可能会使用第三方组件，但同时你也会发现，这些第三方组件往往集成不完善，你又要去自己构建或寻找更合适的组件。这些都是因为 ember.js 没有对 DOM 的交互和管理增加扩展，所以你自己发现会有组件冲突而没有提供易用的 UI 管理。

　　未来将何去何从?

　　ember.js 的主要贡献者是 JavaScript 语言标准委员会 TC39 的核心参与者，在过去几年中，ember.js 对 JavaScript 的发展方向比其他框架都产生更加直接的影响，我们认为，这在将来会继续帮助和促进 JavaScript 改进其功能和模式，同时也意味着 ember.js 将继续保持与未来标准的制定紧密的结合在一起。

　　ember.js 应该不会出现消失的情况，尽管它们的创新点是在与其他项目紧密结合的情况之上实现的，比如 Glimmer，它为 ember.js 应用程序提供一个基于 TypeScript 新的 UI 框架。

　　何时选择 ember.js?

　　如果你想寻找成熟的框架，那么 ember.js 的容错率是很高的，另外，由于 ember.js 官方提供的学习内容很容易理解，并且也有着广泛的官方认可的培训机构和严格的人才认证结构，因此，相比于其他框架而言更容易建立基于 ember.js 的技术团队，也可以培训大型团队如何构建应用，用以确保团队之间的沟通和理解。

　　如果你想对自己的团队保持信心并能够良心批判团队发展和变化的好坏，那么 ember.js 将是一个很好的考量因素。你可以花很少的时间关心框架的技术的先进性，能够把更多的时间投入到应用开发之中。

　　Aurelia

　　有什么优势?

　　Aurelia 有许多构建 web 应用程序的方法、结构，这个框架在编写上有许多技术上的优点，它是十分现代化的并且使用了许多现代化的技术。

　　有什么劣势和挑战?

　　我们认为最大的挑战在于缺少大量具有决定性的核心发展，给我们的感觉是许多想法和概念都是正确的并且着手处理其他框架大量关注的点上，但是现在这些想法都没有完全实现。它和 dojo2 一样正在持续进行着，但是目前它也是一个已经发布了的框架。

　　Aurelia 的大部分开发和维护工作也同样落在一个人的肩膀上，如果他个人的关注点和可用性上发生了变化，那么将又会是一个巨大的挑战。

　　未来将何去何从?

　　Aurelia 有许多可以把握住的机遇，如果能得偿所愿，那么将会保留 angular 建立 web 应用程序时所应用的构建模式，与此同时也要更加完善和符合标准的方式。我们不确定 Aurelia 是否能够抓住这个机遇。

　　何时选择 Aurelia ?

　　如果你致力于使用 web 模型-视图这样的程序应用模式，并且你的团队还想能够希望将来能够持续改进架构，那么 Aurelia 将是你可以考虑使用的框架，它就像是一个依托于寻找巨大的社区来助其发展和迭代的框架。

　　最后的思考

　　真心希望这一系列的帖子至少给了你一点思考，你应该很容易有这样的想法那就是不可能有可验证的正确决定。同时，希望你也意识到没有普遍的错误决定，你应该用一些问题和思考来武装自己，帮助你选择框架。

　　一个框架仅仅是一些模式的体现，一些科技的集成，源码帮助我们更加容易去构建和维护网站应用，如果你是个体开发者，我们能提供的最好的建议是花费尽可能多的时间使用那些你认为可以为你所用的框架。如果你是公司的管理者或骨干领导要去做决定，请记住特点列表只是决定的一方面，有时候并不是越多越好。挑战你自己活着你的团队使用一个整体的框架，但是首先，列出对你和你的组织重要的列表，尤其是那些技术之外特点。