虚拟座谈：HTML5 来了，JavaScript 框架会如何发展

HTML 5 是万维网核心语言的第 5 个主要版本，早在 2004 年就由网络富文本应用技术工作组（WHATWG）发起。虽然标准仍在制定之中，但有些浏览器已经能够支持一部分HTML 5 的特性了，如 Safari 4 beta 。

除了更多的标记以外，HTML 5 还添加了一些脚本API ：

新增的特性充分地考虑了应用程序开发人员，HTML 5 引入了大量的新的 Javascript API。可以利用这些内容与对应的 HTML 元素相关联，它们包括：

• 二维绘图 API，可以用在一个新的画布（Canvas）元素上以呈现图像、游戏图形或者其他运行中的可视图形。
• 一个允许 web 应用程序将自身注册为某个协议或 MIME 类型的 API。
• 一个引入新的缓存机制以支持脱机 web 应用程序的 API。
• 一个能够播放视频和音频的 API，可以使用新的video和audio元素。
• 一个历史纪录 API，它可以公开正在浏览的历史纪录，从而允许页面更好地支持 AJAX 应用程序中实现对后退功能。
• 跨文档的消息传递，它提供了一种方式，使得文档可以互相通信而不用考虑它们的来源域，在某种程度上，这样的设计是为了防止跨站点的脚本攻击。
• 一个支持拖放操作的 API，用它可以与draggable特性相关联。
• 一个支持编辑操作的 API，用它可以与一个新的全局contenteditable特性相关联。
• 一个新的网络 API，它支持 web 应用程序在本地网络上互相通信，并在它们的源服务器上维持双向的通信。
• 使用 JavaScript API 的键 / 值对实现客户端的持久化存储，同时支持嵌入的 SQL 数据库。
• 服务器发送的事件，通过它可以与新的事件源（event-source）元素关联，新的事件源元素有利于与远程数据源的持久性连接，而且极大地消除了在 Web 应用程序中对轮询的需求。

最近 InfoQ 利用电子邮件组织了一次虚拟座谈，主题为 JavaScript 框架将会如何发展，以便充分利用这些新的 API。此次座谈邀请了来自主流 JavaScript 框架的代表：

• Dylan Schiemann，SitePen 的 CEO， Dojo 的共同创建者
• Matt Sweeney和Eric Miraglia，来自 YUI 开发团队
• Andrew Dupont， Prototype 的核心开发者
• Thomas Fuchs， script.aculo.us 的创建者， Prototype 和 Ruby on Rails 的核心开发人员
• David Walsh， MooTools 的核心开发人员
• Scott Blum和Joel Webber，GWT 的领头人

下面是我们的问题以及各专家的回答。

InfoQ：由于 HTML 5 标准仍在制定之中，大多数开发人员对它的新特性并不熟悉，您认为对于 web 开发人员，哪些特性是最值得关注的？

Dylan：HTML 5 包含很多东西，其中很多有价值的特性都已经在 Dojo 这样的框架中实现了。例如，内置的富表单控件将包含多文件上传和数据属性，这样人们就不会再抱怨 Dojo 使用非标准的自定义属性了，虽然这些属性也是合法的。最近 Peter Higgins 为 Dojo 解析器写了一个补丁，大概有 1KB 左右的代码量，以便当这些特性添加到浏览器时可以使用它们。对我来说最感兴趣的特性是 WebSocket，它是由 Michael Carter 提出，并由 Orbited 最先实现的。WebSocket 非常适合那些长连接应用，你可以将它看做是 web 安全的 TCP Socket。

Matt & Eric：对那些把浏览器当成是应用平台的开发人员来说，HTML 5 包含了一些很具创新性的组件。但需要注意的是这有点超出文档语义领域，已经到达 DOM API 领域了，这不是 HTML 规范的必须部分。我们希望 HTML 5 规范能够限制在对文档语义的增强和精化上，而把对行为 API 的规定留给其它规范。

一般来说，开发人员应该知道 HTML5 提供的以下 HTML 相关的特性：

• 反对使用仅用于显示的元素和属性
• 更多有语义的元素
• 更多种输入控件和语义
• 自定义数据属性

开发人员看起来对 HTML 5 中的 DOM API 很感兴趣，如果它们最后能够被实现，其中的某些特性确实能够丰富我们的工具箱，成为很重要的工具。最早被浏览器厂商实现的 2D 绘图 API（通过 Canvas 元素）以及客户端存储 API 已经引发了广泛的关注，这些关注与浏览器厂商在标准确定之前就率先实现有关。但是还有很多其他的重要变化目前也在草案之中：

• Iframe 沙箱
• 支持"getElementsByClassName()"
• "classList" API
• 音频和视频（通过 Audio 和 Video 元素）API
• 离线 web 应用 API
• 编辑（通过 contentEditable 属性）API
• 跨文档消息 API
• 服务器端事件 API

HTML 5 试图解决一些重大的问题，而且解决的不错，比我们上面列出的还要多。

Andrew：“web 存储”（客户端数据库）会被广泛使用——很多网站已经开始好好地利用它了。新的 form 控件（Web Forms 2）从一开始就存在于标准之中，我都等不及赶快使用了。服务器发送事件可以用来构造纯粹的“推”服务程序，而不需要依赖 Ajax 的不断轮询或不稳定的长连接。我还喜欢自定义数据属性，虽然相比之下，这只是一个不太重要的特性。

Thomas：除了离线应用特性（主要指持久化存储），我认为 VIEDO 和 AUDIO 标签是最重要的新特性，因为我们终于可以离开烦人的 OBJECT 和 EMBED 了。当然这还需要一段时间，直到所有浏览器都支持，不过这确实是朝着正确的方向在发展，而对所有非正式标准的标准化工作也会让浏 览器表现得比现在更好。一个容易被忽略的特性是 web 应用程序能够注册协议和媒体类型，以使它们自己成为默认处理程序，就像桌面应用程序一样（但是从 UI 的角度看，仍有很多阻碍，因为对计算机不甚了解的用户不懂什么是“协议”或者“媒体类型”）。

David：除非被广泛支持，否则没有哪个 HTML 5 的特性是非常值得关注的。这些概念值得去实现，但在只有少数几个浏览器支持的情况下使用是不明智的。这就是我们不使用 querySelectorAll 的原因：浏览器厂商的不同实现会导致更多针对浏览器的 hack，而不是简单的避免使用 QSA。

Scott & Joel：在 HTML5 中我最关注的是那些现在就可以使用，而不需要开发人员额外创建不同版本程序的特性。我对其 中的数据库和缓存 API 特别感兴趣，程序可以真正支持在线和离线两种模式了。另外对于移动 web 开发人员来说，HTML5 提供了大量特性来处理低速和连接 不稳定的移动网络。

另外一些 HTML5 的特性也很让人激动，例如 <canvas>、<audio> 和 <video>，这些功能现在还需要插件来实现。目前这些标签还没有被主流浏览器广泛支持，但是随着浏览器支持的增强，使用的人也会增加。

InfoQ：您认为现有的 JavaScript 框架该如何发展，以支持像内置媒体、离线浏览以及更高级的服务器进程通信这样的新特性？能粗略说一下您所在项目的路线图么？

Dylan：我们的目标一直是弥补浏览器的不足。我们希望我们的框架能够越来越不重要（例如，实现统一的事件系统或者是 QuerySelectorAll）。我们发现在某些情况下，我们会随着时间的推移一点一点的删除代码，但是 Dojo 的用户并不会感到有任何的不同，他们 还是可以继续使用相同的 API，只是这些 API 会简单的调用本地实现。对于你提到的更高级的特性，Dojo 已经可以支持媒体和离线程序，并且支持 JSON-PRC 和 REST，甚至可以在 Perservere 这样的服务器端 JavaScript 环境中运行！

Matt & Eric：JavaScript 框架的作用是利用更丰富的 API 和透明的跨浏览器支持来改善编程环境。YUI 将会遵循 HTML 5 标准（特别是那些已经对浏览器产生影响的），并添加对老版本浏览器的支持，以便让新的功能可以在标准实现和推广之前就得以应用。客户端存储 API 是一个 例子，YUI 将要实现它以消除 HTML 5 和现有浏览器之间的不同。

Andrew：像 Prototype 这样的“中间件”框架，主要是把难用的、不一致的 API 包装为统一的、完善的接口，HTML5 并不会 （为 Prototype）带来太大的影响。HTML5 的特性会让某些工作变得简单，但是 Prototype 会一直保留“困难的方式”，直到最后一个非 HTML5 浏览器不再得到支持。

另一方面，建立在 Prototype 上的库 －script.aculo.us，显然需要做出选择。Script.aculo.us 提供了一个“slider”控件，HTML5 也有。是否应该使用浏览器内置的 HTML5 slider？还是使用现有的纯 JavasScript 版本，以保正在所有浏览器中的外观一致？

HTML5 提供了一些特性的本地实现，而之前的多年我们一直用 HTML 和 JavaScript 来实现这些特性，这是一个进步。如果我们能够全部转移到 HTML5 而不管老版本浏览器，大多数的（JavaScript）库都可以移除大量的代码。但是在很长的一段时间里，我们还需要保留这些旧代码。

Prototype 和 script.aculo.us 并没有长期的路线图，但是我知道，当四种主流浏览器中至少有两个支持某一特性时，我就会认真考虑是否实现它。记住，HTML5 不会一次就全部实现的。

Thomas：是的，它们会进化的，最终当浏览器支持这些新特性时，它们也会支持。这对于框架来说并不是什么新鲜事，当新版本浏览器发布时，通常需要关注的是 bugs 而不是新特性。目前，对于 script.aculo.us 来说，最新的“舞台”将是 Canvas 元素，它可以平衡 Prototype 的功能。例如，insertAdjacentHTML() DOM API 可能会比我们目前插入 HTML 的方法更快。

David：我认为我们会像以前那样：从浏览器实现中抽象出 API，对那些不一致的实现进行修复。在某种程度上，我们为老版本浏览器开发解 决方案，以提供跨浏览器支持，但当我们无法实现时，我们会提供检测功能以处理这种情况（或许使用欺骗手段）。我们还不能忘记 IE6 拒绝灭亡的事实，还要过 很长的时间，我们才能完全依赖这些特性。

对于路线图，我们将会利用这些特性的优点，首先创建更小、更快的库。如果我们可以为支持 HTML5 的浏览器构建更快的选择器引擎，我们会将精力集中在那 里，而不是一些非广泛支持的特性。将规范集成到我们的 API 将会提升性能并减少代码量，这在短期内是对我们的最大好处，直到更高级的特性被浏览器市场普遍 实现。

Scott & Joel：对于 GWT 来说，我们会集中在那些被主流浏览器实现的特性上，但是我们也 可能会根据用户浏览器的不同而提供不同的实现方式。例如我们提供了抽象的存储 API，可以根据用户的环境使用 Google Gears 或 HTML 5。GWT 的好处是，最终用户只需要下载他们浏览器支持的特定实现，因为我们已经事先考虑了所有的可能。

InfoQ：HTML 5 为客户端添加了非常多的重量级特性，有些人认为目前的 JavaScript 和 DOM 编程模型已经走到了尽头。我们是否需要为不久的将来考虑一个完全不同的编程模型？

Dylan：jQuery 和 Dojo 的一个主要不同是，jQuery 本质上是以 DOM 为中心的，而 Dojo 还试图改进 JavaScript 的不足。像 Mozilla Lab 的 Bespin 这样的程序用于非 DOM 为中心的开发，我一直认为 DOM 是 JavaScript 开发人员的工具，而不是全部，如果有些事不能通过修改 DOM 来解决，那就不应该在浏览器中解决。坦白地说，我们已经通过不同的工具提供了不同的开发方式。

Matt and Eric：浏览器环境允许不同的模型，而且事实上也有很多模型被开发出来。Flash/Flex/AIR 就是一个很好的 例子，它与 HTML/DOM/CSS（同时）都是 web 成功的关键部分。当你使用 iPhone 上的 Facebook 程序而不是 Facebook 的移动网站 时，你就在使用一种新的模型。到目前为止，还没有哪个其他的模型可以在访问性和简便性上超过它。我们应该在以后“考虑其它模型”么？作为开发人员，我们曾 经有过争执，每次我们构建新程序时，都会考虑其他的模型。如果今天的大多数程序是 web 程序，那么就已经说明浏览器仍然有价值。我们认为浏览器中仍有许多 未被发现的价值，聪明的改进规范（就像 ECMA3.1 那样）将会对目前的平台产生长远的改善。

Andrew：这很难说。有些人希望浏览器解析标记；有些人希望浏览器在窗口上绘制像素。这取决于你构建的程序类型。这并非是要代替 DOM，而是寻找其他的模型来补充 DOM，这样你就可以使用最合适的工具来工作。我觉得 Canvas 和 SVG 可能就是这一类模型。

Thomas：我不这样认为， HTML、CSS 和 JavaScript 的组合已经被证明是非常实用和通用的，每一项技术都在积极的进步，没有必要替换掉它们。

David：怎么会在“不久的将来”呢？任何 HTML5 中能够改变这个模型的东西，都会在多年后才能出现。而且目前的模型已经很完善、很易于理解，更被成千上万的网页所使用。我认为目前还不会有任何改变。

Scott & Joel：我认为目前的方式还没有任何走到尽头的迹象，反而发展的更快、更有组织了。

一方面，有很多理由去制造更好的浏览器（带有 V8 的 Chrome、带有 TraceMonky 的 Firefox、带有 SquirrelFish Extreme 的 Safari，当然还有 IE8）。不管你喜欢哪个浏览器，开发者都有一个更强大的平台。

同时，开发者在这个平台上可使用的工具也越来越好。当 GWT 出现时，我认为它是革命性的。而几周前我们刚刚发布了 GWT 1.6，它比最初的 GWT，甚至比一年前的 GWT 更强大。你可以看到，它的内部其实还是那些东西，只不过随着它的成熟而增加了一些工具。

因此我认为还有很大的发展空间。

InfoQ：有人建议使用另一种客户端语言，例如 Ruby。您认为 JavaScript 目前是否足够强大？是否需要做出大的修改？是否应该使用更多的 DSL 技术？

Dylan：我想我们很可能会看到 DSL，甚至在服务器端也会有 JavaScript。有一个服务器端 JavaScript 讨论组对此有着 极大的兴趣。JavaScript 本身并不是问题所在，真正的问题是浏览器对 DOM 和 JavaScript 交互的实现方式，以前的 JavaScript 引 擎比现在 Mozilla、Google、Apple 和 Opera 都要慢很多。我曾经认真考虑过如果 Python 或 Ruby 成为客户端语言意味着什么，坦白 说我觉得这并不能解决问题。

Matt & Eric：JavaScript 在 ECMA 3.1 中做出了彻底的改变，这就是目前我们真正需要的。

浏览器可以自行选择实现其它的脚本引擎。不过既然它们按照规范实现了 DOM API，使用什么脚本语言也就无所谓了。一些人——包括 Yahoo 的 Douglas Crockford－曾经争论过将来的 Web 是否需要一种新的内建安全机制的语言。

Andrew：完全的语言替换是不会发生的－JavaScript 背后的力量很强大。我喜欢已经流产的 ES4 提案中的很多新特性——运算符重 载、Ruby 风格的 catch-all methods 等等。不幸的是，ES4 包含的太多了。我很庆幸在“妥协”后，ES3.1 包含了 getter 和 setter。但是我认为 ES 3.1 做的还不够。简单来说，我觉得应该尽量让 JavaScript 更加动态。

Thomas：是的，我觉得 JavaScript 就应该是现在这样。它不应该成为一个“真正的面向对象编程语言”，它强大的基于原型的机制已经很好了。这可以让我们使用不同的开发风格，并根据个人喜好进行定制。JavaScript 和 Ruby 有时候非常相似（JavaScript 框架 Prototype 中的某些部分就是在向 JavaScript 中添加 Ruby 风格的元素）。更多的 DSL 将会很好——我最希望未来在 JavaScript 中 能有两样东西，一样是捕获未定义函数名（就像是 Ruby 的 method_missing），另一样是内联函数（blocks）以避免总是需要写 function(){...}。

David：JavaScript 是这个星球上最成功的编程语言之一。尽管有些语言没有那么多的问题（我们知 道 Valerio 喜欢写 Lua 代码，他已经爱上 Lua 了），JavaScript 真正的问题一直是浏览器的实现。框架为我们解决了其中的大量问题，但是显然 JavaScript 规范应 该得到更新。框架的目的有 3 个：1）抽象出浏览器的不同，并支持老版本浏览器；2）提供丰富的、更方便的 API；3）提供规范中没有的功能（例如效果、可 排序表格、图册）。

对于浏览器的错误实现，我们需要 1），对于仍不好用的 API，我们需要 2），对于规范无法提供丰富的功能，我们需要 3）。我们只是没有发现这些东西在近期有任何改变。

Scott & Joel：我认为 JavaScript 作为一种语言非常强大，甚至有些时候太强大了。你有 64 位整型数或为金融程序而内建的 BigDecimal，但是 JavaScript 面临的最大挑战在与如何构建和管理庞大的手写源代码库。当我们最初创建 GWT 时，我们打赌 JavaScript 为人们喜欢的巨大灵活性也可以使它成为一个优秀的编译器目标语言，因此也可以将它当成是 Web 上的某种汇编语言。

你可以在 JavaScript frameworks 和 Rich Internet Applications 找到更多信息。

阅读英文原文： Virtual Panel: Evolution of JavaScript Frameworks for HTML 5 。

感谢张凯峰对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。