Dojo 的联合创建者 Dylan Schiemann 就 AJAX、Comet、Bayeux、RIAs 和 Dojo Toolbox 的问答

Dojo Toolkit 是一个模块化的开源 JavaScript 库，它被设计用来快速开发 JavaScript 或基于 Ajax 的应用程序和网站。InfoQ 最近与 Dylan Schiemann 先生就 AJAX、Comet、Bayeux、RIAs 及最新发布的 Dojo Toolbox 进行了一场问答，他是 SitePen 的 CEO 和 Dojo Toolkit 的联合创建者。

InfoQ：Dylan，你能简单的给我们介绍一下，你是如何开始开发 Dojo 的？你的初衷是什么？Dojo 还会向什么方向发展呢？

2004 年初，Alex Russell 寻找 Informatica 的 DHTML（现称为 Ajax）项目的合作者，最终他选择了我。做项目的过程中，一个共同的目标将众多社区成员 紧密联系在一起，这个目标就是创建一个能跨公司免费使用的工具包，避免重复无益的劳动。我们最初所做的支持 Netscape 4 的工具包显然有太多先天缺限，因此我们决定从一些早期项目（netWindows， BurstLib， f(m) 等）中汲取优秀的思想，创建一个新的工具包，这样能让我们用 JavaScript 的日子好过一些。虽然我们看到了工作的价值所在，但是根本没有想过会对开发社区产生影响或冲击。

InfoQ：你能描述一下这个工具包的体系结构么？下载** Dojo 1.1.1 我们都能得到什么？**

Dojo 由 4 个主要项目构成：Dojo Core、Dijit、DojoX 和 Dojo Utilities。只要引入标准的 dojo.js，就可享有如下特性： - 快速、小巧（用 gzip 打包后只有 26KB）的核心包，提供关于 XHR、事件、DOM、查询、动画及命名空间等的 APIs，以及一些常用函数。

• 可选的日期、颜色、返回 / 历史、货币等模块

在 Dojo 1.2 中，我们实际上已经提供了一个可选的工具，它能将你的基础代码降低到 6KB 大小，在此基础上再增加应用。Dojo 核心还包括另外一些你可以随意引用的代码，例如行为系统、通用正则表达式、日期和货币 APIs 等。

Dijit 既是一个 widget 系统，也是一个普通 widget 集合。这意味着你不仅得到可以直接使用的一套 widget，而且还能拥有创建个人应用的强大系统。 Dijit 中所有 widget 都是可访问的、可国际化的，它既可通过 unobtrusive 方式的标记也可通过 JavaScript 语句来完成实例化。Dijit 包括改良的通用表单元素、日 历、编辑器、树、幻灯片等。

由于 Dojo 和 Dijit 中一切工作都已经就绪，因此在我们着手将 Dojo 升级到 2.0 版本时，API 的兼容性将成为我们工作的重点之一。

DojoX（或者称为扩展 Dojo），包含的特性就没有那么广泛、复杂，或者说还不具有产品品质。其内容包括加密、补充实现的 Dojo 数据存储、支持本地矢量图形的 dojo.gfx、图表、离线模式、网格以及其它 widget。DojoX 中的特性并不能保证向后兼容已经发布的这些 1.x 版本。DojoX 有相当庞大的定期更新的代码库，最近新添的内容是 XMPP client、JSON-Schema、JSON-Referencing 以及一个安全 Ajax 模块。上述所有特性将与 Dojo 1.2 同期发布，并已包含进当前每晚构件（nightly builds）版本中。

Dojo Utilities，像它名字喻示的那样，可以为 JavaScript 开发人员提供大量有用的工具，包括：

• 高度灵活的构建系统，基于轻量级 Rhino 定制版本，可在满足依赖关系前提下合并 JavaScript 文件，及 HTML 和 CSS 文件。
• ShrinkSafe，同样基于 Rhino 的压缩工具，可以删除注释和无关紧要的空白区域等。
• DocTool，非常先进的系统，可以根据源代码产生 API 文档，同时也可以解决复杂的 maxin 继承结构问题等。
• DOH，Dojo Objective Harness 的缩写，一个单元测试工具，可以工作于浏览器和命令行两种方式。

Dojo 以模块化的方式构成，你可以轻松获取个人所需特性模块，无须为 Dojo 中的其它内容耗费系统资源。

Dojo 还是一个开源大本营，Cometd、DWR、Open Record 和 Psych Desktop 等其它一些项目的均发源于此。

InfoQ：今年Dojo 似乎势头很强劲，尤其是在这个夏天** O’Reilly 、 Pragmatic Programmers 和 Addison Wesley 三家出版社分别推出了三本新书之后。你为什么选择现在？**

首先，因为我们已经发布了稳定的 1.0 版本，而且也能够找到一些很出色并乐意写 Dojo 的作家，所以出书可行的。 我们的特色是，有很多公司象 IBM、Google、Sun、Blue Coat Systems、Nexaweb 等等，以及我们为数众多的个体捐助成员，都为创建快速、强大并富有特性的工具包付出了坚持不懈的努力。我们有一个勤奋工作 着的优秀社区，2007 年耗费几个月时间把 Dojo 改写成一个更加迅速、更为轻巧的工具包之后，我们的辛勤付出开始得到回报，这是我认为对你问题的最好答 案。

我们如何发展社区也催生了一些特色。开放、透明、应用良好的许可（BSD 或 AFL）、遵循 CLA 程序，确保避免使用源代码时的知识产权问题。以 Dion Almaer 的标准 ，Dojo 的开放程度可以得到完美的 100 分。

InfoQ：前不久，SitePen 发布了 Dojo Toolbox ****，这是一个为 Dojo 开发人员准备的 AIR 应用程序，你能跟我们谈谈它么？

Adobe 以一种很有趣的方式发布了基于 WebKit 的平台，它既支持 Open Web 技术（HTML、JavaScript、CSS、 Canvas、SVG 等），也支持其独有的 Flash/Flex 栈。这赋于开发人员桌面应用程序独有的优点，包括访问本地文件、较好的缓存和单点部署环 境。在创建可安装的 web apps 这个问题上，他们已经取得了一定的成功。 Adobe 与 SitePen 接触的目的，首先是希望在 AIR 发布之前，Dojo 能改进对它的支持；其次才是提议共同开发应用程序，Dojo Toolbox 由此诞生。

Dojo 拥有的特性如此丰富，以致于想要创建一个易于打印的 PDF 格式的 API 文档、或是易于理解的结构视图都成为一个挑战，因此我们决心让 18MB 的 Dojo 文 档可以脱机使用。我们也知道，提供一种简易的方式创建优化版本的 Dojo 构建并不难，AIR 就是个很好的解决方案。我们基于 BSD 许可协议进行 Dojo Toolbox 的研发，它发布短短几周来，我们已经收到了大量可以增加 app 功能特性的要求和计划。我们是以模块化的方式来设计 Dojo Toolbox 的，这样人们就能创建属于自己的定制工具箱构件，或者将他们的自己的模块贡献出来作为官方版本之用。

InfoQ：除了像 Dojo 这样纯粹的 JavaScript 库外，在 Java 领域开发 web 应用最受欢迎的另外一种方式就是 GWT 了。这二者的运行机制有根本上的差异，GWT 充当一个代码产生器，试图要让开发人员摆脱对不同浏览器差异的检查。你怎样考虑这两种方式的优劣？

经常存在这样一种倾向，告诉你必须选 X 不能选 Y，而不是把这种自由让给开发者，由他去选择喜欢的或表现最完美的组合。我们喜欢给人以选择权，而且事实上，我们当前正在做的一个项目要把 Dojo 和 GWT 很好地结合起来。 lex Russell 在今年的 Google I/O 活动上做了一篇题为“Can We Get There From Here”的讲话。其中一个观点就是，当开始应用 GWT 时，它做得越多，越难拆分。从复杂性程度来说，随着 HTML/CSS 越来越透明，Dojo 只 比普通的 HTML 或者带有诸如命名空间特性的 JavaScript 复杂一点点，然而 Silverlight、GWT 和 Flex 反编译的难度就大大增加。对 于 Dojo，我们已经做了一个很清楚的决定，编译步骤完全是可选的。GWT 确实有一个重新加载的按钮，但是那要在 IDE 环境里才有用。他们的代码优化器促 进了性能的提升，这是我们曾经打算在 JS Linker 工具当中复制的功能，但是后来放弃了，因为我们决定要保持源代码对于 JavaScript 开发人员易于理解的特性。

我极力主张人们仔细考虑与业务相关的所有因素，体验过后再决定对其最具生产效率的产品。

InfoQ: 现在还有其它几种 JavaScript 框架 / 工具包取得了不同程度的成功，在一些企业也得到了应用，你认为 Dojo 和这些产品有什么区别？

Dojo 通过满足来自 IBM、Sun、AOL 以及包括 SitePen 客户在内的其他一些公司的即时需求，获得了广泛切实的提高。我们的开放许可注意到对企业非常重要的细节，从 IP 问题到可访问性和国际化的支持，这令我们成为公司所指望的可以优化其开发能力的优秀开源解决方案。金融机构、军队、政府以及其它一些大型组织都应用 Dojo 贯穿其 Web 开发模型始终。其中大量工作都是“暗物质”Ajax，用在防火墙后。

InfoQ：今年负责新 ECMAScript 4（又称 JavaScript 2）的组织 推出了语言概览的修订版本 后，引发大量争论。你怎么看待提议中语言的改变，以及对类似 Dojo 这样的 JavaScript 框架所产生的影响？

SitePen 的 Kris Zyp 也参加了 ECMAScript 工作组。到目前为止，新语言规范对 Dojo Toolkit 的影响很小，因为我们都很注重实效，要等到它准备就绪后才会开始应用。 总的来说，我们努力保持理智，坚持公正，集中精力做 JavaScript 开发者在这门语言中最需要的工作。我们推动必要特性的完善，反对增加开发难度的改变。

InfoQ：当你创建的 web UIs 过度应用 JavaScript 时，对于经验不丰富的开发人员，许多缺限和错误并不那么容易被发现。在可用性、搜索引擎、“返回”按钮行为、浏览器性能等方面。哪些是Dojo 开发者最常犯的错误？

说到这一点，一个单一的浏览器页面，或者任何 web 或软件应用都会访问一定数量的系统资源，除了你所提到的那些，一个普遍的问题是这些开发新手不去理解他们所做工作的真正含意，举例来说，有些人会用次秒级的 XHR 轮询来实现一个有 100 副动态图的页面。在 Dojo 1.0 版本后，我们就试图少一些“不可思议”，这样开发者更好地理解每种特性都来之不易，正如工具包越小运行越快，很多困难的事情都要求取舍和平衡。 开发者经常犯的另外一个错误是，他们总认为浏览器是稳定和可靠的。坚持用一种理想化的态度去做事是不正确和不可思议的。先看一下用类似 Firebug 的工具所暴露的浏览器性能瓶颈问题，再来告诉我们对浏览器的真实表现的看法吧。

InfoQ：有人说，一个完美的 JavaScript 框架被创造出来，标志着传统的“Web 平台”已经到达潜能的极限 ，应当被其它更先进的产品所替代。对此你怎么看？

我认为出现这种说法的原因是过去 4 年新发明出现的速度之快，彻底地超过了浏览器厂商的能力，他们无法创造更好的部署环境。浏览器厂商经常被批评尝试用非标准的做法，这对他们并不公平，因为如果没有了实验和革新的空间，这些东西是无法成为标准的。 Flex 和 Silverlight 做了适宜的工作提供了良好的开发经验，但是并没有排除 Open Web。我们相信一个进化中的方法不断地提高我们目前所拥有的一切，是一个可行的选择。以 WebKit 为例，它为浏览器中的应用提供了非常好的环境，这个浏览器可能位于 Adobe AIR 内部、位于包括 iPhone 在内的许多移动设备上，或者是桌面、移动设备和 Nintendo Wii 上的 Opera。

JavaScript 工具包在更新 Web 方面已经做了很好的工作，比如说像 Google Gears 这样的东西，它比浏览器厂商可以做到的要快得多。当浏览器厂商在增加新特性和新功能的时候，像 Dojo 这样的工具包也在不断进行自身完善，在 web 范围内寻找可提升的功能。

InfoQ：你认为纯粹的 JavaScript 框架，已经达到与诸如** Flex 、 OpenLaszlo 或 Curl 这样的基于插件的RIA 解决方案相抗衡的程度了么？**

我认为他们干得很不错。OpenLaszlo 在很多方面都更接近一个类似于 GWT 的编译器，它可以部署到 Flash 或 Open Web 上。令人欣慰的是我们已经开始往其它方向作出努力了。对于原生的矢量图形，dojox.gfx 能够支持 SVG、Canvas 和 VML 已经有一段时间了。作为展现工具，最近我们增加了对 Silverlight 的支持，因为在 IE 测试构建中，VML 已经完全乱了套。我们也做了用 Flash 和 Flex 来展现矢量图形和图表的实验，同时提供我们还在没有本地存储能力的浏览器中对 Flash 的本地存储功能提供支持。 在这里，我需要重申的是，这是一个关于选择和务实的问题。

InfoQ： 大家都普遍相信 JavaScript 并非无所不能，有些事情必须依靠 Flex/Flash。这种情况是无处不在的，比如图表。随着最近在图表以及其它相关领域作出的一些行动 ，Dojo 似乎正在成为限制其它技术被应用的原因。当 JavaScript 库越来越博大精深，浏览器给予的支持越来越大，你认为通过插件方式实现页面构件的必要性是否降到了最低？

就 Dojo 而言，我们相信即使有些事情暂时本身不能完成，只要真的希望，最终还是可以用 Dojo 来完成的。原生的矢量图形和图表支持同其它非原生的产品相比是更有竞争力的，不过我们让用户自行选择，而不是把开发者锁定到某种方案上。未来很难预测，但是插件的作用通常是用来完成用本地产品或者 JavaScript 所不能实现的的功能。随着现有全部的浏览器开始支持原生矢量图形，dojox.gfx 可以掩饰跨浏览器实现的不同，此时使用插件的需要才是可选的，而非必需的。这都是 Open Web 自然演变的一部分。

InfoQ：有人说 IE 7 是给设计人员的一份厚礼，因为它对 CSS 已经提供了更好的支持。那么** IE 8 **会不会是给 JavaScript 开发人员的厚礼呢？根据现在已知的宣传信息和各种细节，你对即将发布的 IE 新版本有何看法？那将会是一个很大的进步么？你认为它将会给象 Dojo 这样的 JavaScript 框架带来怎样的影响呢？

我想现在说这些为时尚早，第一版感觉有两点进步 (6 个连接而不是 2 个；安全的跨域请求)，一点退步 (VML 方面严重的 Bug)，因此对下一版我们持谨慎乐观的态度。

InfoQ：2005 年后，当 AJAX 变得广为人知时，最时新的术语是 Comet。至今仍有人为这些术语争论不休 ，因此我想请教你对此的定义。

Comet 是个集合体，内容涉及技术、传输、协议、服务器还有客户机，用于在服务器和客户机之间传送低延迟数据。 XHR 是 Comet 的最小版，其它所有东西都是对 XHR 的改进，以交付更快的、实时的应用。我的定义特意避免了争论点，因为我更喜欢包容和广泛，尤其是对大多数人而言，Ajax 已经成为浏览器中动态展现所有东西的代名词。

InfoQ： Bayeux 协议 看起来是一个可以激活 Comet 应用程序的重要组件，它推动** JSON 以发布订阅模型为客户端和服务器之间的事件编码。你能详细描述一下这个么？因为其唯一性，Bayeux 似乎已经事实上获得业界的认可，但是你认为它会向更为正式的标准化方向发展么，比如通过 **** W3C ？**

到目前为止，我认为非正式的自然状态比较有用，尽管我也相信，标准化组织如果有兴趣最终会选中它。Bayeux 是 Cometd 项目中服务器和客户机之间的标 准协议。当然还有另外一种比较流行的 XMPP 协议。作为 HTML5 的补充，WebSocket 的草案也引起了我很大的兴趣，它的 API 抽象已经在 Orbited 项目中实现。

InfoQ：在 Java 王国里，目前有几种 方式可以开发Comet 应用，随着 ** Servlets 3(JSR 315) 规范浮出水面**，其中定义了制作 Comet 的标准方式，你认为这种类型的应用会向什么方向发展呢？

在 Java 领域，有各种开源的 Comet 服务器可供选择，例如：Jetty、DWR、GlassFish，还有免费版的 Lishtstreamer 和 Caplin Liberator。新的 Servlets 的规范，经过验证可为 Jetty 和 GlassFish 提供支持。我相信最终规范就绪后，所有这些服务器都会应用它。 现 在还出现另外一个有趣的问题，Joe Walker 在 JavaOne 提出的 on-board 和 off-board 的区别。你选择的 Comet 服务器用何种语言写成的，没有确定你所选择的语言对客户端 (客户端是一个基于 Web 的客户端，或者是一个基于 Web 服务器的客户端，它与你的 Comet 服务器进行通信) 具有访问权来得重要。

InfoQ：有人认为既然 web 应用程序以理解 JavaScript(浏览器) 的客户端为目标，那么开发端对端的 JavaScript 方案就有意义了。对这点你怎么看？你是否发觉 Server 端的 JavaScript 正在成为主流？

Jaxer (Aptana)、Persevere (SitePen)、AxiomStack (Axiom)、Phobos (Sun) 还有其它一系列产品的出现，证实你刚刚提到的现象已经很普遍，JavaScript 已成为世界上最广泛存在的编程语言。我认为任何只要做过客户端开发的人，都不用再学习诸如 PHP、Python、 Java 及其它一些语言的语法就能够涉足服务器端的开发 (虽然目前大多数的 Dojo 的用户以更传统的方法使用 Dojo)。 我不知将来会怎样，但是我认为现在是个好机会在服务器和客户端应用相同的 JavaScript 代码库。

InfoQ：虽然你经常会发现开发者处理大型 Java 代码库，但是与 JavaScript 完全不同。它具有动态特性，还有一个事实，就是像 Dojo 这样的框架以一些不同的客户端 (浏览器) 为目标，必然为开发过程增加了一些特殊的限制和困难。除了用 Trac 来进行问题追踪 外，对这些特定类型的软件，目前你是否发现了什么比较有效的工具或方法吗？

我 想对于 JavaScript 代码库的规模你肯定会吃惊的。在 SitePen，我们最近刚从 Trac 转到 Redmine，因为它保持了 Trac 的简易性，同 时还增加了我们渴望已久的特性 (依赖性、预测、多项目)。我们还在用 Subversion，因为有很多工具都支持它。在 SitePen 用得很杂，每一种文本编辑器和 IDE 我们都有用过，看你问的是什么了。 我 们用 Dojo DocTool 和其它能在 Dojo 中找到的工具。我们还用一些不很常见的工具，例如 Windmill、Tito Web Studio、 Charles 和 Versions。我不能说我们有一个全面的标准，这里有最好的维护和重构代码库工具，就像你所拥有的能为 Java 做同种工作的工具一 样，但是我不能确定我们的要求是相同的。

InfoQ：人们已经推测，当** Steve Yegge 谈到下一个比较强大的语言（若存在的话）时，他指的是 JavaScript。而且事实上，他也把很重要的一部分 Rails 框架从 Ruby 转到 JavaScript ，这使得前面的推测更为准确。你也用过这门语言，你觉得具有这种可能性么？**

答案是肯定的，而且我认为这又回到了服务器端的 JavaScript 的问题。 Persevere 是这种方法的另外一个很好的例子。简单来说，Persevere 是一套开源的用于持久化和分布式计算的工具集，它使用了 HTTP REST、JSON-RPC、JSONQuery 和 HTTP Channels 的基于标准的 JSON 接口。

InfoQ：你怎么看 Dojo 的发展？你们下一步有哪些计划？接下来的几个月有哪些惊喜值得我们期待呢？

短 期来说，我们将继续提升性能，象网格、图表、树还有编辑器这样的 widgets，以及 Dijit 的整体感观、表单和数据验证，还有 Comet 客户端的稳定 性，验证系统等等。我们已经开始对 Dojo2.0 的展望，也许会在 2010 发布。对于有志开发 web 应用，并且希望给他们用户提供卓越体验的开发人员，我们将保持 Dojo 可用，具备发展前景，同时保持高效。

InfoQ.com 上有更多关于 RIAs、 JavaScript和 Web 2.0的很有意思的文章。

查看原文： Q&A with Dylan Schiemann co-creator of Dojo on AJAX, Comet, Bayeux, RIAs and the Dojo Toolbox