JavaScript宝座：七大框架论剑

英文原文： Rich JavaScript Applications – the Seven Frameworks   

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

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

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

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

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

        文章可长啦，先概述一下：

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

        技术：共识与分歧

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

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

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

        用 Backbone 创建人 Jeremy Ashkenas 的话说：“现如今，你说‘单页应用’，都跟说‘不用马拉的车’差不多了”（意思是，早已经没那么新鲜了）²。

        ² “不用马拉的车”（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 说：“我们加入了很多魔法，但都是有用的魔法，换句话说，它们可以分解为常规的操作原语。”

        分歧：基于字符串的模板与基于 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 的一个衍生版（看名字就知道³）。

• Why: 你喜欢 Backbone，但又想要点不一样的东西。
• Where: GitHub 和 自有站点
• When: v1.0.0已经发布。

        ³ 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，在客户端应用这一思想也永远是正确的。

        原文链接：Rich JavaScript Applications – the Seven Frameworks   

        作者：Steven Sanderson

        翻译：@李松峰

    来自:     www.ituring.com.cn