你实际上问了不止一个问题。我目前正在为我们公司分析“我应该使用什么框架”的问题。这比你想象的要多得多。以下是我目前所拥有的，当我获得更多详细信息时，我将尝试更新此项目。
与此同时……
架构模式的问题不同于库或框架的问题。
ARCHITECTURAL DESIGN PATTERNS 之所以有用有很多原因。一个原因是在您的模块中实现松散耦合。 Mediator Pattern 中有一个很好的例子来说明如何实现松耦合。
使用哪个框架的问题有很多决策点：
速度测试：
这些是我认为的框架：
我决定将我的框架选择限制为：
-
Dojo：工具包、桌面、移动、图形和矢量
-
YUI：开发者工具、基础设施、实用程序、小部件、图库、项目
-
jQuery：核心、UI、Mobil、插件、图形、可视化
但是……还需要对 JavaScript LIBRARIES 进行细分：
MVC 是最常用的前端模式。但是，我这里的笔记还没有完成。甚至我也很难找到上面列出的项目的使用统计信息。
Backbone.js (MVC)
更倾向于使用 REST 数据。 Backbone 有自己的事件系统，因此可以与 jQuery 功能竞争。
Spine.js (MVC)
JavaScriptMVC (MVC)
MVC集成开发工具；与 jQuery 一起使用；高度模块化。还不知道它是否可以简单地被认为是一个图书馆......但爸爸喜欢！
AngularJS (MVC)
关注点分离、松散耦合和控制反转。双向数据绑定
SproutCore (MVC)
YUILibrary (MVC)
这确实是整个 YUI 框架的一部分……但在原始 source article 中列出。
Broke.js (MVC)
文档目前很差。
Fidel.js (MVC)
Sammy.js (MVC)
更倾向于使用 REST 数据。
KnockoutJS (MVVM)
问题：
- 为什么直接的 MVVM 实现这么少？
- 双向绑定与 MVVM 是一回事吗？
- 如果是这样，为什么其中一些库（进行双向绑定）认为自己是 MVC？
模块化 JAVASCRIPT： AMD、CommonJS 和基于承诺的实现：
我仍在概述这个领域。但是，以下是我用来获取灵感的一些领域。
问题：
- AMD 是否有不同的“风味”（各种文章似乎都说是）？
- “基于承诺”是什么意思？
创建小部件和插件：
一旦你决定了你的模块应该使用哪种类型的 AMD，你就可以开始写东西了。
问题：
一般说明：
我建议看看你的每个框架是如何实现各种模块的。查看完成某事所需的代码。感觉对吗？是不是感觉很笨重？
我的初步感受：
看看社区支持选项的趋势、使用、速度和广泛性……jQuery 遥遥领先。
目标：
最终目标是选择一个框架、任何/所有库并定义一个通用方法来加载和创建松散耦合的 JavaScript 模块。
按风险量化成本：
完全量化成本是困难的，但您可以解释风险。在您的最终决定中，您还应该考虑上面列出的趋势。但是，总的来说，我会将成本大致分为三个定义风险的领域：
-
熟悉度：您的团队现在最熟悉的是什么？
-
升级：在每个框架和库上“升级”需要付出多少额外的努力？
-
许可：这里有什么障碍吗？
风险：一旦评估完毕，您就可以正确地解释为什么您可能将一个选项列为低、中或高。
@ErezCohen
我们是一家 ASP.NET 商店，因此我们将 Web API 用于我们的 RESTFUL 后端。由于组件式 JavaScript 开发是未来，我们选择使用 jQuery 和 RequireJS 作为我们所有页面的标准基线。此外，我们在控制器中大量使用了 Deferred。
至于客户端 MVC，提到的太多“框架”比其他任何东西都更流行（而且许多已经在使用中减弱了）。此外，当需求决定时，将 MVC/MVVM 功能视为一次性附加组件而不是标准更有意义。而且，坦率地说，由于我们发现使 Ajax 调用变得容易，引入庞大的框架来进行简单的数据绑定似乎很愚蠢（唯一真正的好处是对某些复杂情况的双向绑定）。此外，想想一旦这些框架不再流行，将它们解耦是多么痛苦。
当然，我们有能力自己做到这一点……你可能没有。如果您的团队不太擅长 JavaScript，请尝试 Angular，因为它是为“设计师”而不是程序员开发的。或者，如果您的团队能够自己滚动并想要一个控制器框架，那么 jQuery Widget Factory 很有用。但是，对控制器简单地使用模块模式也很好（这就是我们所做的）。而且...效果很好...而且非常干净。