共识：IE6已死
在小组讨论中，大多数框架的创建者说，他们对IE浏览器的支持只限于7+（事实上，灰烬和AngularJS的起点是IE8，蝙蝠侠需要ES5“垫片”才能在IE9之前的IE版本中使用）。这也是大势所想：jQuery 2已经不打算支持IE9以下的旧版本IE了。
只有骨干和敲除还坚定支持IE6 +（我不清楚骨干的内部实现，但敲除会把IE6 / 7那些令人抓狂的渲染及事件方面的怪异行为屏蔽掉）。
共识：许可和源代码控制
大家都使用MIT许可，并且托管在GitHub上上。
分歧：库，还是框架
。这是目前最大的分歧下表对JavaScript的库和框架进行了归类：
| 的JavaScript库 | JavaScript的框架 |
|---|---|
| 骨干（9552） | 灰烬（3993） |
| 敲除（2357） | AngularJS（2925） |
| 脊柱（2017） | 蝙蝠侠（958） |
| CanJS（321） | 流星（4172） - 了不起，见下文 |
**括号中的数字是最近某个时间点的GitHub上的关注者数量，粗略地代表各自的影响力。*
什么意思呢？
- 的JavaScript库，插到既有架构中，补充特定功能。
- JavaScript的框架，提供一个架构（文件结构啊，等等），你必须遵守它，只要你遵守，那剩下的就全都是处理通用需求了。
请注意，AngularJS可以说是介于库和框架之间一种形态：它不要求开发时遵守特定的文件组织方式（与库类似），但在运行时，它提供一个“应用生命周期”，可以对号入座地把代码安排进去（与框架类似）。之所以把它归入框架之列，是因为AngularJS团队乐于接受这个说法。
分歧：灵活，还是整合
每个技术门派都有不同程度的强制性规定：
| 视图 | URL路由 | 数据存储 | |
|---|---|---|---|
| AngularJS | 内置基于DOM的模板（必选） | 内置（可选） | 内置系统（可选） |
| 骨干 | 自选（最常用的是基于字符串的模板库handlebars.js） | 内置（可选） | 内置（可重写） |
| 蝙蝠侠 | 内置基于DOM的模板（必选） | 内置（必选） | 内置系统（必选） |
| CanJS | 内置基于字符串的模板（必选） | 内置（可选） | 内置（可选） |
| 余烬 | 内置基于字符串的模板（必选） | 内置（必选） | 内置（可重写） |
| 击倒 | 内置基于DOM的模板（可选，也可以用基于字符串的模板） | 自选（大都使用sammy.js或history.js） | 自选（如knockout.mapping或只用$阿贾克斯） |
| 流星 | 内置基于字符串的模板（必选） | 内置（必选？不确定） | 内置（蒙戈，必选） |
| 脊柱 | 自选基于字符串的模板 | 内置（可选） | 内置（可选？不确定） |
不难想见，只要某个库在某方面是开放的，他们的人就会强调只有这样才能从总体上确保跟第三方库兼容。同样，显而易见的反对意见则是，只有内置才能保证无缝整合。再次，根据我参加的对话，现场观众也各持己见，说什么的都有，基本上可以看出每个人对其他技术组合的了解程度。
分歧：基于字符串的模板与基于DOM的模板
（请参考上面的表格。）对基于字符串的模板，大家几乎都选择Handlebars.js作为模板引擎，它俨然成了这个领域的霸主，当然CanJS用的是EJS。对基于字符串的模板，支持的人认为“它更快”（不一定），而且“理论上，服务器也可以处理它”（也不一定，因为前提必须是在服务器上运行所有模型代码，而实践中根本没人那么做） 。
而基于DOM的模板呢，意味着纯粹通过在实际标记中绑定来控制流程（每个，如果，等等），且不依赖任何外部模板库。支持的声音有“它更快”（不一定） ，另外“代码易读，易写，且标记与模板之间没有隔阂，CSS如何与之交互也一目了然。”
在我看来，最有吸引力的说法来自AngularJS那帮家伙，他们认为在不久的将来，基于DOM的模板会得到浏览器原生支持。所以我们最好现在就用，从而可以轻松应对未来.AngularJS来自谷歌，所以他们在开发的Chromium时会考虑这一点，而且也会说服标准主体接纳这个建议。
分歧：服务器中立到什么程度
蝙蝠侠和流星明显依赖服务器：蝙蝠侠是为Rails的设计的，而流星本身就是服务器其他大多数都追求服务器中立但实际上，Ember公司的架构，强制性规定，以及某些工具都倾向于Rails的开发者。当然，灰烬绝对也能跟其他服务器技术搭配，只不过眼下还需要较多手工配置。
技术门派概览
以下是所有的JavaScript库/框架的基本技术细节。
骨干
- 谁： Jeremy Ashkenas和DocumentCloud。
- 什么：
+用JavaScript实现模型 - 视图，MIT许可。
+只有一个文件，1000行代码，在所有库中最小！
+功能极其专一，只提供REST可持久模型及简单路由和回调（以便你知道何时渲染视图，但视图渲染机制由你自己选择）。
+名气最大，很多大牌站点都在用（也许是因为它最小，容易部署）。 - 为什么：
+非常小，使用它之前，你完全可以通读并理解它的源代码。
+不会影响你的服务器架构或文件组织方式。可以在页面的某一部分内运行 - 不需要控制整个页面。
+ Jeremy好像进入了一种禅宗所谓的入定的状态，对一切都能坦然接受。他就像一个大人，看着一群孩子在那里辩论。 - 地点： GitHub 及 自有站点。
- 当： 至今已诞生近两年了。
流星
- 谁： 流星开发团队（他们刚募集到1120万美元投资，因此可以全职开发）。
- 什么：
+前瞻性极强的一个框架，想不出有谁那么激进过（也许Derby算一个）。
+将一个服务器端运行时环境（用Node + Mongo搭建）和一个客户端运行时环境衔接起来，让你的代码在两端都能运行，还包含数据库利用的WebSockets实现所有客户端和服务器之间的同步。
+在修改代码时就“实时部署” -客户端运行时可以即时更新而不丢失状态。
+可以看看这个视频，对它的认识就会更全面。
+跟会上与我有过交流的所有人一样，我也愿心希望这个框架获得成功 - 网开发就需要这种激进的改革才能真正进步。 - 为什么： 你实在觉得做常规的Web开发太无聊了，想找点刺激。
- 地点： GitHub 和 自有站点。
- 当： 诞生时间不长;除了其核心团队在用，不知道还有没有其他站点实际在用流星不过，这个团队真是在严肃地做着一件前无古人的事。
余烬
- 谁： Yehuda Katz（之前开发过jQuery和Rails），Ember团队和Yehuda的公司Tilde。
- 什么：
+构建“超级Web应用”所需的一切，MIT许可。
+功能最多，体积最大。
+融入了很多设计理念，涉及如何分解并对页面进行层次控制，以及如何利用一个状态机驱动的系统联结各个层次。
+正在开发一个功能非常完善的数据访问库（Ember.Data）。
+要在运行时控制整个页面，因此不适合开发大页面上的“富应用区”。
+对文件，URL等都有相当严格的一套约束，不过要是不喜欢，你可以重写，只要你知道怎么做就OK。
+设计灵感来自Rails和Cocoa。
+工具：为Rails提供项目模板（但如果你手工编写代码，也可以使用其他服务器端平台）。 - 原因： 常见的问题应该有通用的解决方案--Ember提供了所有通用解决方案。
- 地点： GitHub 和 自有站点。
- 当： 尚未发布1.0版，但也快了然后，API基本就能稳定下来。
AngularJS
- 谁： Google（他们内部在使用）。
- 什么：
+用JavaScript实现模型 - 视图 - 其他，MIT许可。
+基于DOM的模板，具备可观察能力，声明绑定机制，还有准MVVM式的代码风格（他们自己说是模型 - 视图 - 随便）
+内置基本URL路由和数据持久化能力
+工具：附带一个Chrome调试器插件，让你在调试的时候能够查看模型;还附带一个Jasmine测试框架。 - 为什么：
+从概念上讲，他们说这个框架相当于一个“填料层”，盖在当前浏览器上，以实现未来的浏览器将可能原生具备的能力（即声明绑定和可观察能力）。因此，我们现在就应该着手这么来写代码了。
+对服务器架构或文件组织方式没有影响。可以用在页面的某一小部分中 - 不需要控制整个页面。 - 地点： GitHub 和 自有站点。
- 当： 成品级框架，谷歌已经搞出来有一段时间了。
击倒
- 谁： Knockout团队和社区（核心团队目前有三个人）。
- 什么：
+用JavaScript实现模型 - 视图 - 视图模型（MVVM，Model-View-ViewModel），MIT许可。
+功能集中在富用户界面元素：基于DOM的声明绑定模板，可观察的模型加自动依赖检测。
+没有限定URL路由或数据访问 - 可组合任意第三方库（例如，用Sammy.js做路由，用纯Ajax实现存储）。
+在降低使用门槛方面下了很大工夫，提供详尽的文档状语从句：交互式示例。 - 为什么：
+只做好一件事（UI），向后兼容到IE6。
+对服务器架构或文件组织方式没有影响。可以用在页面的某一小部分中 - 不需要控制整个页面。 - 地点： GitHub 和 自有站点。
- 当： 到现在已经正式发布近两年了。
脊柱
- 谁： Alex MacCaw。
- 什么：
+用JavaScript实现MVC，MIT许可证。
+由最早为O'Reilly一本书写的示例代码发展而来，已成为一个OSS（开源软件）项目。
+是Backbone的一个衍生版（看名字就知道3）。 - 为什么： 你喜欢骨干，想要但又点不一样的东西。
- 地点： GitHub 和 自有站点
- 时间： v1.0.0已经发布。
3 Backbone和Spine都是“脊椎”的意思.--译者注
蝙蝠侠
- 谁： Shopify （一家电子商务平台公司）的团队。
- 什么：
+在JavaScript中实现MVC，几乎是专门为Rails + CoffeeScript开发者定制的，MIT许可。
+是所有框架中强制性规定最多的。你必须遵守其约定（例如，怎么组织文件和URL）。否则，就像他们幻灯片中说的，“你还是用其他框架吧”。
+非常完善的框架，具有相当丰富的模型，视图和控制器，还有路由。当然，还有可观察机制。
+基于DOM的模板。 - 理由： 如果你使用的Rails和CoffeeScript的，你找到亲人了。
- 地点： GitHub 和 自有站点。
- 时间： 当前版本0.9，几个月内将发布1.0版。
CanJS
- 谁： Bitovi（一家JavaScript咨询/培训公司）的团队。
- 什么：
+用JavaScript实现MVC，MIT许可。
+ REST可持久模型，基本的路由，基于字符串的模板。
+知名度不高（我也是上周才听说它的），但它的前身却是原来的JavaScriptMVC项目。 - 为什么：旨在集上述各技术门派之所长，提供与它们类似的功能，同时又保持体积小巧。
- 地点： GitHub 和 自有站点。
- 时间： 1.0版已经发布了。
总结
如果你正在考虑选型的问题，想知道上面这些框架/库中的哪一个最适合你的新项目，那我建议你重点关注以下两点。
- 功能范围。你想让这个框架或库为你做多少事儿？你的项目是从头做起，因而需要一个能贯穿始终的完整的各项功能齐备的架构吗？或者，你其实更喜欢自己来挑选模式和库？对不同的项目，不同的团队，任何选择都有价值，都是正确的。
- 美学设计你看过它们的代码吗，用没用过自己选择的框架构建出了一些小巧的应用你喜欢这样做吗不要只看它们的说明或者功能列表就作出选择：？？那些信息有价值，但不全面。打个比方，如果你置自己主观的编码经验于不顾，那就像在选择小说时只看它有几章几节，或者在找对象时只看其简历或个人描述。
尽管存在分歧，但我认为所有技术门派有一个重大的共性：它们都践行了模型与视图分离的思想而这个思想早在网络诞生之前就已存在，到现在差不多有20年历史了这么。说吧，就算你只做一个基本的网络应用的用户界面，在客户端应用这一思想也永远是正确的。