一周前（去年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说：“我们加入了很多魔法，但都是不错的魔法，换句话说，它们完全可以分解为常规的操作。”
分歧：基于字符串的模板与基于DOM的模板替代译法
（请参考上面的表格。）对基于字符串的模板，大家几乎都选择Handlebars.js作为模板引擎，它俨然成了这个领域的霸主，当然CanJS用的是EJS。对基于字符串的模板，支持的人认为“它更快”（不一定），而且“理论上，服务器也可以处理它”（也不一定，因为前提必须是在服务器上运行所有模型代码，而实践中根本没人那么做）。
而基于DOM的模板呢，意味着纯粹通过在实际标记中绑定来控制流程（each、if，等等），且不依赖任何外部模板库。支持的声音有“它更快”（不一定），另外“代码易读、易写，且标记与模板之间没有隔阂，CSS如何与之交互也一目了然。”
在我看来，最有吸引力的说法来自AngularJS那帮家伙，他们认为在不久的将来，基于DOM的模板会得到浏览器原生支持。所以我们最好现在就用，从而可以轻松应对未来。AngularJS来自Google，所以他们在开发Chromium时会考虑这一点，而且也会说服标准主体接纳这个建议。
分歧：服务器中立到什么程度Batman和Meteor明显依赖服务器：Batman是为Rails设计的，而Meteor本身就是服务器。其他大多数都追求服务器中立。但实际上，Ember的架构、强制性规定，以及某些工具都倾向于Rails开发者。当然，Ember绝对也能跟其他服务器技术搭配，只不过眼下还需要较多手工配置。
技术门派概览以下是所有JavaScript库/框架的基本技术细节。
Backbone3Backbone和Spine都是“脊椎”的意思。——译者注
Batman如果你正在考虑选型的问题，想知道上面这些框架/库中的哪一个最适合你的新项目，那我建议你重点关注以下两点。
尽管存在分歧，但我认为所有技术门派有一个重大的共性：它们都践行了模型与视图分离的思想。而这个思想早在Web诞生之前就已存在，到现在差不多有20年历史了。这么说吧，就算你只做一个基本的Web应用的UI，在客户端应用这一思想也永远是正确的。
| 欢迎光临 叶子网络bbs论坛 (https://fob0.com/) | Powered by Discuz! X3.3 |