【JavaScript】对比12 款优秀的JavaScript MVC/MVVC框架 你最喜欢Backbone or Ember
http://codebrief.com/2012/01/the-top-10-javascript-mvc-frameworks-reviewed/
目前基本所以后台程序都是面向对象MVC模式开发,作为Web前端开发的人来说,也是很需要的,那么目前有没有可以借鉴的呢?
作者(Gordon L.Hempton)一直在寻求哪种MVC框架最为完美,他将目前能获取到的所有框架都粗略地试了试,然后在文章中列出了每一种框架的情况概要,在文末分享了作者经过对比之后最终的推荐产品。
首先要特别说明一下,作者认为以下四个功能是十分重要的:
- 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个框架对于上述几种特性的支持关系,在后面的部分会详细叙述,您也可以在之后的文章中点击相应的链接来获取更多的信息。
![](http://www.camnpr.com/upload/2013/5/201305161641048381.jpg)
1. Backbone.js
Backbone.js是web最火的框架,如果不了解它将寸步难行,众多知名品牌均支持该框架,令人印象深刻,自然地成为作者最先进行尝试的框架。作者用它来建造了一个Group Talent内部用行政管理方面功能的feature应用。
Backbone(也称为 Backbone.js)是由 Jeremy Ashkenas 创建的一个轻量级库,可用于创建 MVC 类应用程序。Backbone:
- 强制依赖于 Underscore.js,Underscore.js 是一个实用型库
- 非强制依赖于 jQuery/Zepto
- 根据模型的变更自动更新应用程序的 HTML,有助于代码维护
- 促进客户端模板使用,避免了在 JavaScript 中嵌入 HTML 代码
模型、视图、集合和路由器是 Backbone 框架中的主要组件。在 Backbone 中,模型会存储通过 RESTful JSON 接口从服务器检索到的数据。模型与视图密切关联,负责为特定 UI 组件渲染 HTML 并处理元素上触发的事件,这也是视图本身的一部分。
优点:强大的社区,还有大量的实力支持。例如它本身就较多地使用了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框架是哪一款呢?
原文:The Top 10 Javascript MVC Frameworks Reviewed
via