【转】12 款优秀的 JavaScript MVC 框架评估

JavaScript MVC 框架有很多，不同框架适合于不同项目需求。了解各种框架的性能及优劣有利于我们更加快捷的开发。作者（Gordon L.Hempton）一直在寻求哪种MVC框架最为完美，他将目前能获取到的所有框架都粗略地试了试，然后在文章中列出了每一种框架的情况概要，在文末分享了作者经过对比之后最终的推荐产品。

首先要特别说明一下，作者认为以下四个功能是十分重要的： 

候选方案 

下面这个表格列出了12个框架对于上述几种特性的支持关系，在后面的部分会详细叙述，您也可以在之后的文章中点击相应的链接来获取更多的信息。 

1.  Backbone.js 

Backbone.js是web最火的框架，如果不了解它将寸步难行，众多知名品牌均支持该框架，令人印象深刻，自然地成为作者最先进行尝试的框架。作者用它来建造了一个Group Talent内部用行政管理方面功能的feature应用。 

优点：强大的社区，还有大量的实力支持。例如它本身就较多地使用了Underscore.js（也是一个强大的框架）。 

缺点：抽象功能不够强，以及一些需要的功能还没实现。整个框架十分轻量级，产出的结果是一大堆引用文件和样板：而且应用的规模越大这一点就会越明显。 

2.  SproutCore 1.x 

SproutCore最开始是苹果公司用于其iCloud上面的。除了名字起得很不好之外，它实际上是一个非常优秀的框架，也是最大的框架之一。 

优点：支持绑定，忠实的社区粉丝，优秀的feature很多。 

缺点：过于死板，难以去除无用的feature，强制使用一种Native风格的范例，严重的问题在于该框架不允许使用HTML来做布局。 

3.  Sammy.js 

Sammy是作者偶然发现的一个比较小的框架，因为它太简化了，基本不能占据列表的席位。其核心feature是一个路由系统，让应用与AJAX进行交换。 

优点：简单的学习曲线，与服务器端的app集成更加容易。 

缺点：太过于简单，对于大型应用就有些捉襟见肘。 

4.  Spine.js 

器如其名，Spine显然是受到Backbone的强烈影响，像Backbone一样也是一个非常轻量级的框架，遵循相似的模型。 

优点：轻量级，文档做得很好。 

缺点：从根本上就有缺陷。Spine的一个核心概念是“一个坚果外壳中的一堆异步的UI集，这意味着UI应该是在理想化条件下永远不会阻塞的”。而做了一系列的非阻塞式实时应用之后，作者可以说这简直是不现实的，除非后端是像Operational Transformation之类的。 

5.  Cappuccino 

Cappuccino是一款更加独特的框架，自带编程语言Objective-J，还能尝试着在浏览器中仿真Cocoa。 

优点：大型的构想出的框架，良好的社区环境，强大的继承模型。 

缺点：在您所有能用Javascript仿真的语言之外，Objective-C是作者最不想选用的。它起源一位iOS开发人员，作者到现在还没想明白用浏览器编写Objective-J是什么意思。 

6.  Knockout.js 

K.O.是一个MVVM框架，受到其支持者的大量好评。它强调陈述式UI绑定和自动UI刷新。 

优点：支持绑定，文档做得出色，引导系统超级赞。 

缺点：绑定语法晦涩，缺乏坚实的视图组件层次结构。作者希望能够轻松地重用组件，也觉得定义成一个MVVM框架是有害的。这些框架中基本没有MVC，但都是（MVP,MVVM之类的）的变种。 

7.  Javascript MVC 

作者的兴趣是充分地披露各种框架，对Js MVC并没有花太多时间来评估。 

优点：坚实的社区基础和积累。 

缺点：基于Strings的继承模型很尴尬，控制器太接近视图又缺乏绑定机制。命名方式太不受保护了，相当于这样的情况：如果RoR可以说是“Rudy web Framework”的简写。 

8.  Google Web Toolkit 

GWT是一系列的客户端工具包，除了框架之外还包含很多其他工具。它可以把java语言编译成Javascript，支持标准Java库的一个子集，最初是Google公司使用在Wave上面的。 

优点：综合宽泛的框架，拥有强大的社区支持。基于Java的坚实组件继承模型，在巨型客户端应用上表现出色。 

缺点：除了Google说的之外，GWT将经不住时间的检验。就好像最初DART那样，很明显Java不是web的未来。更严重的是，客户端对于Java的抽象有一点不合适。 

9.  Google Closure 

如果说Google Closure仅仅是一个js框架，倒不如说更像是一个工具包。附带编译器和优化器。 

优点：由Google用在其很多主流app上面。良好的基于组件的UI编写系统。 

缺点：不支持UI绑定。 

10.  Ember.js 

Ember（之前是SproutCore 2.0）是竞争者中的新丁。它是一个尝试：从SproutCore2.0中抽取分离其核心feature并转变成为一个更加紧凑的模型框架，更加适合web。 

优点：特别丰富的模板系统，拥有可编写的视图和UI绑定。 

缺点：由于太新，文档跟不上。 

11.  Angular.js 

Angular是在作者发布评估结果之后才发现的一个很好的框架，由Googler开发，包含了很多有趣的设计选择。 

优点：关于模板的范围和控制器的设计考虑的很周到。具有依赖注入系统（作者本人是一个iOS粉丝）。支持丰富的UI绑定语法，从而使得过滤和转换这样的工作开销很小。 

缺点：代码库很不健全，也不够模块化。视图也不够模块化（关于这点在Batman.js的缺陷中讨论的更加细致） 

12.  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技术讨论社区也十分奇妙：这一定会是一个值得期待的好框架。 

当然这个列表还是不够全面。几乎所有这些框架都被发现被人骂得臭名昭著体无完肤，或者被Hacker News点名。 

你用的MVC框架是哪一款呢？ 

原文地址：http://codebrief.com/2012/01/the-top-10-javascript-mvc-frameworks-reviewed  

转载于:https://www.cnblogs.com/xbcq/p/3668064.html