Q：您认为现有的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的好处是，最终用户只需要下载他们浏览器支持的特定实现，因为我们已经事先考虑了所有的可能。

    Q：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更强大。你可以看到，它的内部其实还是那些东西，只不过随着它的成熟而增加了一些工具。

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

    Q：有人建议使用另一种客户端语言，例如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上的某种汇编语言。