原文链接:Rich JavaScript Applications – the Seven Frameworks 作者:Steven Sanderson
翻译:@李松峰 感谢 @温谦-此昵称太受欢迎 老师推荐。

一周前,Throne of JS大会在多伦多召开,这应该是我参加过的最有料也最不一样的一次大会。大会官网如是说:

加载整个页面,然后再“渐进增强”以添加动态行为,这种构建Web应用的方式已经不够好了。要想让应用加载快,反应灵敏,而且又引领潮流,必须彻底检讨你的开发手段。

这次大会邀请了七大JavaScript框架/库的创建人,他们济济一堂,面对面交流各自的技术理念。所谓七大框架/库分别是:AngularJS、Backbone、Batman、CanJS、Ember、Meteor、Knockout、Spine。1

声明:我在会上讲Knockout,因此我的观点显然不是中立的。在这篇文章中,我重点讨论这些创建人的思路和技术理念,尽量不提我赞成或反对什么。

1 没错,是8个框架,不是7个。但到底怎么回事儿,会议主办方也没有明确给我们解释过……

enter image description here

文章可长啦,先概述一下:

  • 对许多Web开发人员来说,要构建富Web应用,使用客户端框架是理所当然的。如果你什么框架也没用,那要么你不是在做应用,要么就会错过很多好东西。
  • 在使用方法上,这些框架很多地方都是一致的(模型-视图-*架构、声明绑定,等等——详见下文) ,因此从某种意义上讲,无论你选择哪一个,都能得到同样的好处。
  • 理念上还是有不少差异,特别是在对框架和库的看法上,分歧格外大。你的选择会深刻影响你的架构。
  • 会议本身活泼,新颖,技术小组之间有很多交流和对话。我希望能有更多类似的会议。

技术:共识与分歧

随着每个SPA(Single Page Application,单页应用)技术的逐一展示,一些相当明显的相似性和差异性浮出了水面。

共识:渐进增强不能建立真正的应用

各技术门派一致认为,真正的JavaScript应用必须有适当的数据模型,并具备客户端渲染能力,而绝不仅仅是服务器处理数据再加上一些Ajax和jQuery代码那么简单。

用Backbone创建人Jeremy Ashkenas的话说:“现如今,你说‘单页应用’,都跟说‘不用马拉的车’差不多了”(意思是,早已经没那么新鲜了)2

2 “不用马拉的车”(horseless carriage)是汽车刚刚发明的时候,人们对它的称呼。——译者注

共识:模型-视图-某某

所有技术门派都坚持模型-视图分离。有的强调MVC(Model View Control),有的提到MVVM(Model View ViewModel),甚至有人拒绝明确说出第三个词儿(只提模型、视图,然后加上让它们协调运作的东西)。对各门派而言,最终结果其实是相似的。

共识:推崇数据绑定

除了Backbone和Spine之外,其他框架都在自己的视图里内置了声明数据绑定的机制(Backbone的设计理念强调让用户“自选视图技术”)。

共识:IE6已死

在小组讨论中,大多数框架的创建者说,他们对IE浏览器的支持只限于7+(事实上,Ember和AngularJS的起点是IE8,Batman需要ES5“垫片”才能在IE9之前的IE版本中使用)。这也是大势所趋:jQuery 2已经不打算支持IE9以下的旧版本IE了

只有Backbone和Knockout还坚定支持IE6+(我不清楚Backbone的内部实现,但Knockout会把IE6/7那些令人抓狂的渲染及事件方面的怪异行为屏蔽掉)。

共识:许可和源代码控制

大家都使用MIT许可,并且托管在GitHub上。

分歧:库,还是框架

这是目前最大的分歧。下表对JavaScript库和框架进行了归类:

JavaScript库JavaScript框架
Backbone(9552)Ember(3993)
Knockout(2357)AngularJS(2925)
Spine(2017)Batman(958)
CanJS(321)Meteor(4172)——了不起,见下文

**括号中的数字是最近某个时间点GitHub上的关注者数量,粗略地代表各自的影响力。*

什么意思呢?

  • JavaScript库,插到既有架构中,补充特定功能。
  • JavaScript框架,提供一个架构(文件结构啊,等等),你必须遵守它,只要你遵守,那剩下的就全都是处理通用需求了。

目前来看,鼓吹框架模型最卖力气的是Ember,其创建人Yehuda Katz之前是(理念相似的)Rails和SproutCore项目的开发者。他的观点是,缺少任何组件都不够给力,都不能说是真正在推动技术进步。相反的观点说,库的目的更明确,因而更容易掌握、采用、定制,也有助于把项目风险降到最低,毕竟你的架构不会严重依赖任何一个外部项目。根据我参加对话的情况看,现场观众也分成了两派,有支持框架的,也有支持库的。

请注意,AngularJS可以说是介于库和框架之间一种形态:它不要求开发时遵守特定的文件组织方式(与库类似),但在运行时,它提供一个“应用生命周期”,可以对号入座地把代码安排进去(与框架类似)。之所以把它归入框架之列,是因为AngularJS团队乐于接受这个说法。

分歧:灵活,还是整合

每个技术门派都有不同程度的强制性规定:

 视图URL路由数据存储
AngularJS内置基于DOM的模板(必选)内置(可选)内置系统(可选)
Backbone自选(最常用的是基于字符串的模板库handlebars.js)内置(可选)内置(可重写)
Batman内置基于DOM的模板(必选)内置(必选)内置系统(必选)
CanJS内置基于字符串的模板(必选)内置(可选)内置(可选)
Ember内置基于字符串的模板(必选)内置(必选)内置(可重写)
Knockout内置基于DOM的模板(可选,也可以用基于字符串的模板)自选(大都使用sammy.js或history.js)自选(如knockout.mapping或只用$.ajax)
Meteor内置基于字符串的模板(必选)内置(必选?不确定)内置(Mongo,必选)
Spine自选基于字符串的模板内置(可选)内置(可选?不确定)

不难想见,只要某个库在某方面是开放的,他们的人就会强调只有这样才能从总体上确保跟第三方库兼容。同样,显而易见的反对意见则是,只有内置才能保证无缝整合。再次,根据我参加的对话,现场观众也各持己见,说什么的都有,基本上可以看出每个人对其他技术组合的了解程度。

Ember的Tom Dale说:“我们加入了很多魔法,但都是不错的魔法,换句话说,它们完全可以分解为常规的操作。”

替代译法

@时蝇喜箭 我们用了很多“法术”,但都是好的“法术”,意味着可以分解成合理的基本组件。
@连城404 我们的代码技巧性比较高,但绝非旁门左道,都是些由常规的基本语义元素构成的东西。
@玉伯也叫射雕 我们实现了很多巧妙的整合,真的非常巧妙,这些整合都可以分解成普通操作。

分歧:基于字符串的模板与基于DOM的模板

(请参考上面的表格。)对基于字符串的模板,大家几乎都选择Handlebars.js作为模板引擎,它俨然成了这个领域的霸主,当然CanJS用的是EJS。对基于字符串的模板,支持的人认为“它更快”(不一定),而且“理论上,服务器也可以处理它”(也不一定,因为前提必须是在服务器上运行所有模型代码,而实践中根本没人那么做)。

而基于DOM的模板呢,意味着纯粹通过在实际标记中绑定来控制流程(each、if,等等),且不依赖任何外部模板库。支持的声音有“它更快”(不一定),另外“代码易读、易写,且标记与模板之间没有隔阂,CSS如何与之交互也一目了然。”

在我看来,最有吸引力的说法来自AngularJS那帮家伙,他们认为在不久的将来,基于DOM的模板会得到浏览器原生支持。所以我们最好现在就用,从而可以轻松应对未来。AngularJS来自Google,所以他们在开发Chromium时会考虑这一点,而且也会说服标准主体接纳这个建议。

分歧:服务器中立到什么程度

Batman和Meteor明显依赖服务器:Batman是为Rails设计的,而Meteor本身就是服务器。其他大多数都追求服务器中立。但实际上,Ember的架构、强制性规定,以及某些工具都倾向于Rails开发者。当然,Ember绝对也能跟其他服务器技术搭配,只不过眼下还需要较多手工配置。

技术门派概览

以下是所有JavaScript库/框架的基本技术细节。

Backbone

  • Who: Jeremy Ashkenas和DocumentCloud。
  • What:
    + 用JavaScript实现模型-视图,MIT许可。
    + 只有一个文件,1000行代码,在所有库中最小!
    + 功能极其专一,只提供REST可持久模型及简单路由和回调(以便你知道何时渲染视图,但视图渲染机制由你自己选择)。
    + 名气最大,很多大牌站点都在用(也许是因为它最小,容易部署)。
  • Why:
    + 非常小,使用它之前,你完全可以通读并理解它的源代码。
    + 不会影响你的服务器架构或文件组织方式。可以在页面的某一部分内运行——不需要控制整个页面。
    + Jeremy好像进入了一种禅宗所谓的入定的状态,对一切都能坦然接受。他就像一个大人,看着一群孩子在那里辩论。
  • Where: GitHub自有站点
  • When: 至今已诞生近两年了。

Meteor

  • Who: Meteor 开发团队(他们刚募集到1120万美元投资,因此可以全职开发)。
  • What:
    + 前瞻性极强的一个框架,想不出有谁那么激进过(也许Derby算一个)。
    + 将一个服务器端运行时环境(用Node+Mongo搭建)和一个客户端运行时环境衔接起来,让你的代码在两端都能运行,还包含数据库。利用WebSockets实现所有客户端和服务器之间的同步。
    + 在修改代码时就“实时部署”——客户端运行时可以即时更新而不丢失状态。
    + 可以看看这个视频,对它的认识就会更全面。
    + 跟会上与我有过交流的所有人一样,我也衷心希望这个框架获得成功——Web开发就需要这种激进的改革才能真正进步。
  • Why: 你实在觉得做常规Web开发太无聊了,想找点刺激。
  • Where: GitHub自有站点
  • When: 诞生时间不长;除了其核心团队在用,不知道还有没有其他站点实际在用Meteor。不过,这个团队真是在严肃地做着一件前无古人的事。

Ember

  • Who: Yehuda Katz (之前开发过jQuery和Rails)、Ember团队和Yehuda的公司Tilde
  • What:
    + 构建“超级Web应用”所需的一切,MIT许可。
    + 功能最多,体积最大。
    + 融入了很多设计理念,涉及如何分解并对页面进行层次控制,以及如何利用一个状态机驱动的系统联结各个层次。
    + 正在开发一个功能非常完善的数据访问库(Ember.Data)。
    + 要在运行时控制整个页面,因此不适合开发大页面上的“富应用区”。
    + 对文件、URL等都有相当严格的一套约束,不过要是不喜欢,你可以重写,只要你知道怎么做就OK。
    + 设计灵感来自Rails和Cocoa。
    + 工具:为Rails提供项目模板(但如果你手工编写代码,也可以使用其他服务器端平台)。
  • Why: 常见的问题应该有通用的解决方案——Ember提供了所有通用解决方案。
  • Where: GitHub自有站点
  • When: 尚未发布1.0版,但也快了。然后,API基本就能稳定下来。

AngularJS

  • Who: Google(他们内部在使用)。
  • What:
    + 用JavaScript实现模型-视图-其他,MIT许可。
    + 基于DOM的模板,具备可观察能力、声明绑定机制,还有准MVVM式的代码风格(他们自己说是Model-View-Whatever)
    + 内置基本URL路由和数据持久化能力
    + 工具:附带一个Chrome调试器插件,让你在调试的时候能够查看模型;还附带一个Jasmine测试框架。
  • Why:
    + 从概念上讲,他们说这个框架相当于一个“填料层”,盖在当前浏览器上,以实现未来的浏览器将可能原生具备的能力(即声明绑定和可观察能力)。因此,我们现在就应该着手这么来写代码了。
    + 对服务器架构或文件组织方式没有影响。可以用在页面的某一小部分中——不需要控制整个页面。
  • Where: GitHub自有站点
  • When: 成品级框架,Google已经搞出来有一段时间了。

Knockout

  • Who: Knockout 团队和社区(核心团队目前有三个人,包括我)。
  • What:
    + 用JavaScript实现模型-视图-视图模型(MVVM,Model-View-ViewModel),MIT许可。
    + 功能集中在富用户界面元素:基于DOM的声明绑定模板,可观察的模型加自动依赖检测。
    + 没有限定URL路由或数据访问——可组合任意第三方库(例如,用Sammy.js做路由,用纯Ajax实现存储)。
    + 在降低使用门槛方面下了很大工夫,提供详尽的文档和交互式示例
  • Why:
    + 只做好一件事(UI),向后兼容到IE6。
    + 对服务器架构或文件组织方式没有影响。可以用在页面的某一小部分中——不需要控制整个页面。
  • Where: GitHub自有站点
  • When: 到现在已经正式发布近两年了。

Spine

  • Who: Alex MacCaw。
  • What:
    + 用JavaScript实现MVC,MIT许可证。
    + 由最早为O'Reilly一本书写的示例代码发展而来,已成为一个OSS(Open Source Software,开源软件)项目。
    + 是Backbone的一个衍生版(看名字就知道3)。
  • Why: 你喜欢Backbone,但又想要点不一样的东西
  • Where: GitHub自有站点
  • When: v1.0.0已经发布。

3 Backbone和Spine都是“脊椎”的意思。——译者注

Batman

  • Who: Shopify (一家电子商务平台公司)的团队。
  • What:
    + 在JavaScript中实现MVC,几乎是专门为Rails+CoffeeScript开发者定制的,MIT许可。
    + 是所有框架中强制性规定最多的。你必须遵守其约定(例如,怎么组织文件和URL)。否则,就像他们幻灯片中说的,“你还是用其他框架吧”。
    + 非常完善的框架,具有相当丰富的模型、视图和控制器,还有路由。当然,还有可观察机制。
    + 基于DOM的模板。
  • Why: 如果你使用Rails和CoffeeScript,你找到亲人了。
  • Where: GitHub自有站点
  • When: 当前版本 0.9,几个月内将发布1.0版。

CanJS

  • Who: Bitovi(一家JavaScript咨询/培训公司)的团队。
  • What:
    + 用JavaScript实现MVC,MIT许可。
    + REST可持久模型、基本的路由、基于字符串的模板。
    + 知名度不高(我也是上周才听说它的),但它的前身却是原来的JavaScriptMVC项目
  • Why: 旨在集上述各技术门派之所长,提供与它们类似的功能,同时又保持体积小巧。
  • Where: GitHub自有站点
  • When: 1.0 版已经发布了。

总结

如果你正在考虑选型的问题,想知道上面这些框架/库中的哪一个最适合你的新项目,那我建议你重点关注以下两点。

  • 功能范围。你想让这个框架或库为你做多少事儿?你的项目是从头做起,因而需要一个能贯穿始终的完整的各项功能齐备的架构吗?或者,你其实更喜欢自己来挑选模式和库?对不同的项目,不同的团队,任何选择都有价值,都是正确的。
  • 设计美学。你看过它们的代码吗,用没用过自己选择的框架构建出了一些小巧的应用?你喜欢这样做吗?不要只看它们的说明或者功能列表就作出选择:那些信息有价值,但不全面。打个比方,如果你置自己主观的编码经验于不顾,那就像在选择小说时只看它有几章几节,或者在找对象时只看其简历或个人描述。

尽管存在分歧,但我认为所有技术门派有一个重大的共性:它们都践行了模型与视图分离的思想。而这个思想早在Web诞生之前就已存在,到现在差不多有20年历史了。这么说吧,就算你只做一个基本的Web应用的UI,在客户端应用这一思想也永远是正确的。

(完)


相关阅读:

评论

推荐 2
不过,好象他们只说了下各自的特点,但是讲得太粗了,而且没有一些示例,很难进行比较。至少从我用过的angularjs和了解过backbone,我觉得angularjs功能更强大,特别是双向数据绑定,DOM模板,DI(Dependency Injection), Directive, Dirty-checking(这里有一个讨论 http://stackoverflow.com/questions/9682092/databinding-in-angularjs)还是挺吸引人的。而backbone则给我的感觉只提供了一个架子,许多工作其实还是要自已去做。

推荐 2
原文有点错误:Backbone只有一个文件,800行代码。
Backbone依赖与underscore,underscore现在已有1100行了,Backbone也有1400多行。
Backbone的1400行代码是包含近400行(大约377行)注释。文中改成了1000吧。 –  李松峰 2012-08-05 08:21

推荐 2
括号中的数字是最近某个时间点GitHub上的浏览量,粗略地象征各自的影响力。

github的watch指的是用户对一个项目的follow关系,而不是浏览项目页面。觉得watcher译成“关注者”更准确些。
谢谢,我看错了。 –  李松峰 2012-08-04 12:02
话音刚落,github就用star替代了原来的watch功能,哈…… –  米粽 2012-08-08 01:24

推荐 2
SPA=> Single Page Application 吧?
噢,应该是啊,谢谢。 –  李松峰 2012-08-04 08:37

推荐 1
这文章角度挺好的,要是能持续更新就更好了,有些信息旧了。

推荐 1
一个也没有用,看好angularjs,大家都在用什么啊

推荐 1
刚看了文章,感觉Backbone和angularJS第一印象挺好的

推荐 1
为啥我用到mv的地方很少

推荐 1
感觉能成气候的是Backbone。Angular反正Google会用。Meteor做成云服务不错。

推荐 1
只对Backbone有些了解,简单说说:
用了大半年Backbone了,在做一个大型的SPA应用(小型ERP,单据界面很多),Backbone就是个空架子,几乎所有东西都需要自己去扩展,比如最有用的视图与模型之间的双向绑定机制、模型的嵌套机制、View的生命周期管理机制、View的布局拆分等等。因为Backbone提供的东西实在是太少了,我也一直在思考Backbone的价值到底在哪里?(我深信它非常有价值,但是还没彻底想明白,嘿嘿!)对于那些刚开始并不知道自己到底需要什么东西的开发者,也许从Backbone开始是对的,因为Backbone对扩展比较开放(因为它压根就没提供什么,所以也没什么好限制的)。

通过这篇文章,让我对“模型-视图-*架构” 这方面有了进一步的整体的了解,但是并没有能够解答我很多一直没想明白的东西。感觉此文大部分内容还只是点到为止,不够过瘾,有点遗憾!

btw:李老师的翻译绝对一流!非常感谢辛苦的付出!(“操作原语”这个词第一次听说,感觉有点怪怪的?!)
我感觉backbone的价值是把Model分成了Model和Collection两个对象,这两个对象面向关系数据库更友好,把服务端对象和前端对象的映射变的直接了当。 这一点抽象的很不错,至少KissyMVC 和 YUI MVC模块都直言不讳的讲,这个是来自backbone的。 而Router和View做的都不多,做大一点的应用肯定不够的,所以按各自需要扩展。而做的少的好处,在PC浏览器里的应用和在移动浏览器的应用可以分别扩展适合自己View管理机制,而大家都在用backbone呢。 –  limu 2012-08-07 17:09
@limu 赞!关于“把Model分成了Model和Collection两个对象”,我还没理解到这个深度呢。我用Collection的地方不多,因为我们的列表数据量都比较大,不太适合再把单行作为一个model来处理的模式。 我感觉Backbone最大的价值就是它的轻量级,容易上手,就那几行源代码,一会儿就看完了,从而使“模型-视图-*架构”这种开发模式能够迅速普及开来。未来一定有比Backbone更好的类库或框架出像,但是它们肯定或多或少的都要留下Backbone的影子!另外我很喜欢Backbone.Events,基于Backbone.Events扩展出自己的视图间低耦合的消息传递机制,用起来很爽。 –  fejustin 2012-08-07 18:20
说实话,那句话太抽象了,我又不了解Ember。Tom到底想说把魔法分解成什么,我也是猜的,可能是一个比喻。 –  李松峰 2012-08-08 14:25
又加入了几个替代译法,供参考。另见:http://weibo.com/1639621773/ywcPMBMg6 –  李松峰 2012-08-08 15:29

我要评论

需要登录后才能发言
登录未成功,请修改提交。