叶子网络bbs论坛

标题: JavaScript宝座:8大框架 ngularJS、Backbone、Batman、CanJS、Ember、Meteor、Kno... [打印本页]

作者: admin    时间: 2014-12-11 17:31
标题: JavaScript宝座:8大框架 ngularJS、Backbone、Batman、CanJS、Ember、Meteor、Kno...

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

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

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

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

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

随着每个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的设计理念强调让用户“自选视图技术”)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

加载整个页面,然后再“渐进增强”以添加动态行为,这种构建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上的关注者数量,粗略地代表各自的影响力。

什么意思呢?

目前来看,鼓吹框架模型最卖力气的是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库/框架的基本技术细节。

BackboneMeteorEmberAngularJSKnockoutSpine

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

BatmanCanJS总结

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

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







欢迎光临 叶子网络bbs论坛 (https://fob0.com/) Powered by Discuz! X3.3