JavaScript宝座:七大框架论剑javascript
一周前,Throne of JS大会在多伦多召开,这应该是我参加过的最有料也最不同的一次大会。大会官网如是说:html
加载整个页面,而后再“渐进加强”以添加动态行为,这种构建Web应用的方式已经不够好了。要想让应用加载快,反应灵敏,并且又引领潮流,必须完全反省你的开发手段。java
此次大会邀请了七大JavaScript框架/库的建立人,他们济济一堂,面对面交流各自的技术理念。所谓七大框架/库分别是:AngularJS、Backbone、Batman、CanJS、Ember、Meteor、Knockout、Spine。1jquery
声明:我在会上讲Knockout,所以个人观点显然不是中立的。在这篇文章中,我重点讨论这些建立人的思路和技术理念,尽可能不提我同意或反对什么。git
1 没错,是8个框架,不是7个。但到底怎么回事儿,会议主办方也没有明确给咱们解释过……angularjs

文章可长啦,先概述一下:
- 对许多Web开发人员来讲,要构建富Web应用,使用客户端框架是理所固然的。若是你什么框架也没用,那要么你不是在作应用,要么就会错过不少好东西。
- 在使用方法上,这些框架不少地方都是一致的(模型-视图-*架构、声明绑定,等等——详见下文) ,所以从某种意义上讲,不管你选择哪个,都能获得一样的好处。
- 理念上仍是有很多差别,特别是在对框架和库的见解上,分歧格外大。你的选择会深入影响你的架构。
- 会议自己活泼,新颖,技术小组之间有不少交流和对话。我但愿能有更多相似的会议。
技术:共识与分歧
随着每一个SPA(Single Page Application,单页应用)技术的逐一展现,一些至关明显的类似性和差别性浮出了水面。github
共识:渐进加强不能创建真正的应用
各技术门派一致认为,真正的JavaScript应用必须有适当的数据模型,并具有客户端渲染能力,而毫不仅仅是服务器处理数据再加上一些Ajax和jQuery代码那么简单。ajax
用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,在客户端应用这一思想也永远是正确的。
(完)
http://www.ituring.com.cn/article/8108