Dojo的联合创建者Dylan Schiemann访谈

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可用，具备发展前景，同时保持高效。

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