在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的代码库已经被不少开发者实践使用过，所以我们相信这是一个不错的开始。