临发布 2.0 前对 ExtJS 作者 Jack Slocum 的访谈

在 Ext 下一个版本的预览文章发布近一个月之后，ExtJS 团队最近发布了该框架的 2.0 alpha 版本 ，包含以下新功能:

• 可编组和摘要的表格
• 可滚动的 Tabs
• 固定布局
• 包含列的 Tree 器件
• Web 桌面
• 新 API 文档中心
• 一些新演示

需要指出的是，ExtJS2.0 的 API 已经被数个客户投入到产品开发的环境中，并已经是稳定的 API。框架遵从 LGPL3.0 的协议，也提供商业和 OEM 的许可。2.0 最终完成时间大约定在十月底。

InfoQ 特约了 ExtJS 的作者 Jack Slocum 就这次发布进行了访谈：

解析一下 ExtJS 与 JavaScript 生态系统下 JQuery、Dojo、Prototype、YUI 等之间的关系。是不是打算构建一个多层的 JavaScript 的框架？还有，为什么我们需要结合以上的库，而不是单纯使用 ExtJS（虽然可以单用）？

JQuery、Prototype 和 YUI 都属于非常核心的 JS 库。虽然 YUI，还有最近的 JQuery，都给自己构建了一系列的 UI 器件（Widget），不过却没有一个真正的整合好的和完整的程序开发平台。哪怕是这些低层的核心库已经非常不错了，但当投入到真正的开发环境中，依然需要开发者做大量的工作去完善很多缺失之处。而 Ext 就是要填补这些缺口。主流开源框架中只有 Dojo 像 Ext 一样，尝试着提供整合的开发平台。相比 Dojo 这个出色的工具包，我们认为 Ext 能提供一个粘合度更高的应用程序框架。Ext 的各个组件在设计之时就要求和其它 Ext 组件组合一起工作是无缝合作的。这种流畅的互通性，离不开一个紧密合作的团队，还必须时刻强调设计和开发这两方面目标上的统一，而这点是很多开源项目未能做到的。从构建每一个组件开始，我们始终都强调组件的外观、性能、互通性和可扩展性，而我们认为组件已经达到了这几点的要求。Ext 绝对可以单独使用。实际上，除了有特定的要求，推荐单独使用 Ext，这样的话文件占位更小，支持和整合也更紧密。我们也支持与 jQuery、YUI 或 Prototype 整合使用，作为低层库的角色出现，以提供处理各种核心的服务，如 DOM 和事件处理，Ajax 连接和动画特效。使用整合方式的一个原因是它们已具备了一些特定的器件而 Ext 并没有原生支持——像 YUI 的 History 控件便是一个典型的例子。这时，Ext 需要依赖 YUI 这个库的底层来实现 History 控件，这样一来的话也可免去 Ext 自身底层库，从而减少了整个程序的内存占用。另一个使用整合方式的原因是，对于许多已在使用其他底层库的程序，你可能希望逐步加入 Ext。总之，如果已经有了其他库，Ext 可已利用它们。我们的宗旨是为用户提供各种可能性和性能上的优化。而事实是，只要实现了相对应的底层库接口，为任意一个框架添加上适配器是没有问题的——人们可以轻松地将 Dojo、Moo、Ajax.NET，或其它 JS 库转变为 Ext 的底层。

要支持这些不同种类的 JS 库，最困难的事情是什么？

最大的挑战也是最明显的，就是保持 Ext 与其它库的同步更新，并要保证能良好地配合工作。每当其中的一个库发布了新版，我们必须测试它们，看看有没有哪些变动会导致 Ext 出现问题。

要支持各种不同的 Web 浏览器，同样，遇到最大的问题是怎样的？

我们所面对的最大的问题，就是对修改和新增内容的测试和验证花去了大量的时间。不但要处理各浏览器以及版本上的差异，还要对付各浏览器不同文档类型声明（Doc types）之间差异。可以让我们放心的是，我们直接在 Ext 中内建了很多工具，让它处理跨浏览器的问题。包括针对 Box 模型问题常规化的一个基类组件，特定平台的常量值和一些自适应的 CSS 样式类，这些样式类可解决浏览器怪癖（Browser Quirks）的问题而无须 CSS Hacks。 正因为有了这样的内建支持，再加上核心框架是稳定和久经测试的，用户一般不需要过多考虑跨浏览器的问题，从而加快开发速度，并且大大减少应用所需的测试量。

如果有一种鞭策 EXT 2.0 前进的动力，你能形容下那是什么吗？

为开发者带来坚实和协调的基础平台。尽管 1.x 版本的 EXT 已经不错了，但是在某些方面仍有余地可以降低开发者的门槛，并减少代码量。特别在创建复杂程序的时候，我们希望 API 本身能应付此类较复杂的处理：例如组件的延时渲染、组件的生命周期等任务可以交给 API 控制，省下开发者手工操作的步骤。关于 2.0 的另外一个主要改进是一个更加健壮的基础平台，满足了定制组件（插件）、群组组件（容器）和组件初始化的要求。在布局和组件的一致性方面的新改进，意味着一旦你明白了怎么配置好一个 EXT 的组件，你便能够以相同的方式处理框架内全部其他的组件。最终为用户带来更快速更易用的开发，而没有牺牲 EXT 本身的体积和性能。

这次 2.0 的升级你认为最具创新是什么？

应该说是容器的新架构。在 1.x 中，程序布局主要是围绕 BorderLayout（针对布局）和 BasicDialog（针对窗口和对话框）。虽然这两个组件表现不错也非常好用,。但是若想在其基础上复用代码，扩展新功能，就受到很多制肘。在 2.0 里，我们使用新容器和布局架构，增加了相当数量的布局管理器 （CardLayout、ColumnLayout、FormLayout、TableLayout 等共九个），并重新整理了容器 API，使得你能以相同的方式将组件加入到 TabPanel、Window、Panel 等等。总之，我们提供的不只是 UI 器件，还是一整套运行良好的框架，一个可帮助用户生成应用程序的基础。

你会如何比较用 ExtJS 和 JavaScript 与其它技术，如 Silverlight 和 Flex 来实现客户端应用？

从某种方面来说，Ext 实际会是这些以浏览器插件为基础的新技术的一种补充。Flex 和 Silverlight 都可以包含 DHTML/Ajax。我们其中的一个 Adobe AIR Simple Tasks 演示正是 Ext 在这种环境下运行的一个好例子。从这个例子，可以看出在 EXT 的帮助下实现的高质量外观，原生 AIR 不花费大量时间来包装 UI 器件和定制 CSS 难以达到这种程度。当然，原生的平台拥有一些原生的优势，当前 JavaScript 没有本地编译和合适工具的支持。JavaScript 应用程序更简单的开发和部署模型也自有其存在的空间。Microsoft 推出的《Sliverlight 企业部署指南（Enterprise Sliverlight Deployment Guide）》，当中有 SMS、活动目录（Active Directory）等等一大堆令人头痛的东西——这些都是 JavaScript 应用中绝不会见到的！另外，新近问世的移动平台（如 iPhone）上的 JavaScript/DHTML 支持却有明显的改进（比插件支持更受欢迎）。看起来还是有很好的理由去选择 JavaScript，而不是那些基于插件的技术。

可供选择的工具很多，最重要的是开发者应该针对手头的工作选择最适合的工具。有时候基于插件的技术才是最适合的，但我们很自信 JavaScript 技术还会在很长的一段时间里占据 Web 开发的一席之地，而 Ext 会在其中扮演重要的角色。

ExtJS 下一步的计划是什么？

当前的重点是发布一个稳定和可靠的 2.0。尽管首次发布的是一个 Alpha 的版本，但是由于 2.0 的代码库已经被不少开发者实践使用过，所以我们相信这是一个不错的开始。

查看英文原文： ExtJS Creator Jack Slocum Discusses Upcoming 2.0 Release - - - - - -

译者简介：Frank Cheung 有多年 Web 前端开发经验，动态语言爱好者。负责 EXT 中文站（ www.ajaxjs.com ）JavaScript 开源论坛 Js 堂（jstang.5d6d.com）的维护工作。专注 Ajax 和 WebUI, 从 YUI-Ext 起，翻译了不少 EXT 相关的资料（发布在 Javaeye AJAX 论坛、和自己的博客上 www.ajaxjs.com/frank ）。