导读：在最近的几个月中，作者一直在寻求哪种 MVC 框架最为完美：将目前能获取到的所有框架都粗略地试了试，然后在文章中列出了每一种框架的情况概要，在文末分享了作者经过对比之后最终的推荐产品。
首先要特别说明一下，以下四个 feature 作者认为是十分重要的：
● UI Bindings：[UI 绑定]作者想说的不仅仅是模板，而是想谈一种在底层模型出现变化时，视图层能够自动相应地更新的陈述性方法。一旦您用过了支持 UI Binding 的框架（例如 Flex）就很难放手回头了。
● Composed Views：[模块化视图]与所有的软件开发者 一样，作者也喜欢编写模块化、可重用的代码。基于这样的原因，当给 UI 编程的时候，作者喜欢使用视图的方法来创作（个人更偏好在模板层时使用），当然这样也就需要拥有足够丰富的视图组件来支持。关于这一点有一个可重用的页面 小工具的范例。
● Web Presentation Layer：[web 表示层]我们是在为 web 编写程序，最不想要的就是 Native 风格的小工具；但是也没有什么理由来为一个 web 框架来创建它自己的布局管理器。HTML 和 CSS 是目前解决样式与布局的最好的方法，他们被这样应用着，框架也应该以这一点为核心。
● Play Nicely With Others：[兼容，友好]不得不承认，jQuery 是十分犀利的。作者不喜欢那种绑定着一个 sub-par jQuery 副本的框架，而直接推荐使用 jQuery 的那种框架才是作者需要的。
竞品们
下面这个表格列出了 12 个框架对于上述几种特性的支持关系，在后面的部分会详细叙述，您也可以在之后的文章中点击相应的链接来获取更多的信息。
0. Backbone,js
Backbone.js 是 web 最火的框架，如果不了解它将寸步难行，众多知名品牌均支持该框架，令人印象深刻，自然地成为作者最先进行尝试的框架。作者用它来建造了一个 Group Talent 内部用行政管理方面功能的 feature 应用。
优点：强大的社区，还有大量的实力支持。例如它本身就较多地使用了 Underscore.js（也是一个强大的框架）。
缺点：抽象功能不够强，以及一些需要的功能还没实现。整个框架十分轻量级，产出的结果是一大堆引用文件和样板：而且应用的规模越大这一点就会越明显。
SproutCore 最开始是苹果公司用于其 iCloud 上面的。除了名字起得很不好之外，它实际上是一个非常优秀的框架，也是最大的框架之一。
优点：支持绑定，忠实的社区粉丝，优秀的 feature 很多。
缺点：过于死板，难以去除无用的 feature，强制使用一种 Native 风格的范例，严重的问题在于该框架不允许使用 HTML 来做布局。
2. Sammy.js
Sammy 是作者偶然发现的一个比较小的框架，因为它太简化了，基本不能占据列表的席位。其核心 feature 是一个路由系统，让应用与 AJAX 进行交换。
优点：简单的学习曲线，与服务器端的 app 集成更加容易。
缺点：太过于简单，对于大型应用就有些捉襟见肘。
3. Spine.js
器如其名，Spine 显然是受到 Backbone 的强烈影响，像 Backbone 一样也是一个非常轻量级的框架，遵循相似的模型。
优点：轻量级，文档做得很好。
缺点：从根本上就有缺陷。Spine 的一个核心概念是“一个坚果外壳中的一堆异步的 UI 集，这意味着 UI 应该是在理想化条件下永远不会阻塞的”。而做了一系列的非阻塞式实时应用之后，作者可以说这简直是不现实的，除非后端是像 Operational Transformation 之类的。
4. Cappuccino
Cappuccino 是一款更加独特的框架，自带编程语言 Objective-J，还能尝试着在浏览器中仿真 Cocoa。
优点：大型的构想出的框架，良好的社区环境，强大的继承模型。
缺点：在您所有能用 Javascript 仿真的语言之外，Objective-C是作者最不想选用的。它起源一位 iOS 开发人员，作者到现在还没想明白用浏览器编写 Objective-J是什么意思。
5. Knockout.js
K.O.是一个 MVVM 框架，受到其支持者的大量好评。它强调陈述式 UI 绑定和自动 UI 刷新。
优点：支持绑定，文档做得出色，引导系统超级赞。
缺点：绑定语法晦涩，缺乏坚实的视图组件层次结构。作者希望能够轻松地重用组件，也觉得定义成一个 MVVM 框架是有害的。这些框架中基本没有 MVC，但都是（MVP,MVVM 之类的）的变种。
作者的兴趣是充分地披露各种框架，对 Js MVC 并没有花太多时间来评估。
优点：坚实的社区基础和积累。
缺点：基于 Strings 的继承模型很尴尬，控制器太接近视图又缺乏绑定机制。命名方式太不受保护了，相当于这样的情况：如果 RoR 可以说是“Rudy web Framework”的简写。
GWT 是一系列的客户端工具包，除了框架之外还包含很多其他工具。它可以把 java 语言编译成 Javascript，支持标准 Java 库的一个子集，最初是 Google 公司使用在 Wave 上面的。
优点：综合宽泛的框架，拥有强大的社区支持。基于 Java 的坚实组件继承模型，在巨型客户端应用上表现出色。
缺点：除了 Google 说的之外，GWT 将经不住时间的检验。就好像最初 DART 那样，很明显 Java 不是 web 的未来。更严重的是，客户端对于 Java 的抽象有一点不合适。
如果说 Google Closure 仅仅是一个 js 框架，倒不如说更像是一个工具包。附带编译器和优化器。
优点：由 Google 用在其很多主流 app 上面。良好的基于组件的 UI 编写系统。
缺点：不支持 UI 绑定。
9. Ember.js
Ember（早起是 SproutCore 2.0）是竞争者中的新丁。它是一个尝试：从 SproutCore2.0 中抽取分离其核心 feature 并转变成为一个更加紧凑的模型框架，更加适合 web。
优点：特别丰富的模板系统，拥有可编写的视图和 UI 绑定。
缺点：由于太新，文档跟不上。
A. Angular.js
Angular 是在作者发布评估结果之后才发现的一个很好的框架，由 Googler 开发，包含了很多有趣的设计选择。
优点：关于模板的范围和控制器的设计考虑的很周到。具有依赖注入系统（作者本人是一个 iOS 粉丝）。支持丰富的 UI 绑定语法，从而使得过滤和转换这样的工作开销很小。
缺点：代码库很不健全，也不够模块化。视图也不够模块化（关于这点在 Batman.js 的缺陷中讨论的更加细致）
B. Batman.js
Batman 由 Shopify 创作，是另一款与 Knockout 和 Angular 具有相似脉络的框架。Batman 拥有良好的 UI 绑定系统，是基于 HTML 属性的。Batman 是唯一的一款使用惯用语法 Coffeescript 编写的框架，并且紧密地与 NODE.Js 集成在一起，甚至可以到拥有其（可选的）Node.js 服务器的程度。
优点：代码库十分清晰，绑定方法优良又简单，耐用，流程化。
缺点：作者非常不喜欢这种“独行侠”式的作风，更不用说这种加强单一控制器的主意了。与 Knockout 和 Angular 一样，在组件嵌套的时候遭受同样的折磨。作者需要的不仅仅是模板，还更想要陈述式的可重用的模板框架。相比，Ember 在框架之上拥有的是一个基于 EMBER 他们自己的逻辑（可能是在控制器层上的）的整套组件能陈述式重用的方法。
赢家
最终，Ember.js 是能满足作者全部需求的唯一一款框架。最近作者将一个小的 Backbone 应用转换成了 Ember 来实验，除了一些性能方面的小问题之外，作者对于产生的代码库更为欣慰。由 Yehuda Katz 支持，整个围绕 Ember.js 技术讨论社区也十分奇妙：这一定会是一个值得期待的好框架。
当然这个列表还是不够全面。几乎所有这些框架都被发现被人骂得臭名昭著体无完肤，或者口头传播，或者被 Kacker News 点名。作者本人并不是评估其框架的专利权问题（或者哪些使用令人不爽的 license 的框架）。
您用的 MVC 框架是哪一款呢？
1573
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
