AJAX框架比较
编者按：近两年来，AJAX之风愈演愈烈，其相关技术以及背后所秉承的理念正逐渐被越来越多的开发人员所认可。随之而来的AJAX开源框架也层出不穷。更令人欣幸的是，在众多框架之中，我们华语开发者为Web应用开发人员贡献了两个出类拔萃之作：新技术的“领头羊”ZK，厚积薄发的“水牛 ”Buffalo。本期的工具栏目，邀请到ZK创始人——叶明宪和Buffalo创始人——陈金洲，对当前一些流行的AJAX框架做出点评，并且与读者分享AJAX框架的发展现状及趋势。
叶明宪观点
AJAX 已流行二、三年了，现今所谓 Web 2.0 网站或多或少有 AJAX 影子。然而新的 AJAX 框架仍不断诞生，现有的框架也在持续推出新的版本。为什么？
首先，AJAX应用范围持续扩大，从 del.icio.us 简易的编辑功能，到 999fang.com 整合 AJAX 和数据库搜寻，到 Google Spreadsheets 近似 Windows 应用程序。再者，AJAX已缓步进入企业应用。除了User Friendly，安全、开发及维护成本、与现有应用服务器、服务和开发环境的整合度等更是企业应用的重点。这些都已跳脱早期框架的范畴。
目前 AJAX 在企业应用正处于 Geoffrey Moore 所谓的Chasm中，预期接下二年会慢慢大量投入使用。而在消费型网站的应用正走过高成长期，聚光灯的焦点将逐渐移到如Google Spreadsheets的应用。
在这种背景之下，AJAX框架如雨后春笋，层出不穷。很多开发者朋可能都有自己的偏好，但是仍有一些开发人员面对这么多框架，可能会感觉无从下手。我们可以从多个面向来看这些框架。
从功能面来看，可分为以下几类：
1、浏览器端的底层链接库，如 Prototype, script.aculo.us, jQuery 等。
2、浏览器端UI组件库，如 Ext-JS, Dojo 等。
3、整合式框架，如 ZK, Backbase, IceFaces 等。
其中，底层链接库应用最广、轻巧易整合力但功能有限。整合式框架则包括浏览器端及服务器端的完整框架。
DWR和GWT则较难分类。DWR基本是JavaScript-to-Java 的 RPC框架，而GWT则是在RPC 加上浏览器端开发工具。
从应用面来看，可粗分网站应用和企业应用。底层链接库多用于网站应用或当其它框架的基础。UI组件库则二者都有，而整合式框架侧重在企业应用。
从系统架构来看，可分Client-centric和Server-centric。所谓 Client-centric 是指你写的程序代码(UI部份)主要执行的地方在客户端 (即浏览器)，而 Server-centric 则在服务器端。大部份框架多是 Client-centric，如Dojo, Prototype，GWT，Ext-JS，Backbase等。而Server-centric则以ZK为代表。
一般读者不太注意架构的差别，但它是决定开发及维护成本的关键。
读到这里，可能仍有人心存疑问：到底哪种框架适合我的应用？事实上，没有单一个框架适合所有应用。对于强调简易直觉接口的Web 2.0网站而言，通常只有几个需要 AJAX化的功能，可藉由浏览器端的底层链接库的帮助，并投入相当资源，以使这些AJAX 化出众夺目才是最重要的。对于现有Web应用程序，如架构于Struts、JSP或JSF等，则可依其对JavaScript熟悉度而选择浏览器端UI组件库或整合式框架。使用浏览器端 UI组件库，需要较多定制化JavaScript程序代码才能整合到原应用程序中。而使用整合式框架，则要视其是否支持现已使用的架构。例如，若使用.NET平台，则只能使用 Microsoft的框架。若使用JSP则可使用ZK和Backbase。若使用JSF则可使用ZK，Backbase和IceFaces。
利用ZK框架设计的Web应用程序具备丰富的胖客户端特性和简单的设计模型。ZK包括一个基于AJAX可自动进行交互式操作的事件驱动引擎和一套兼容 XUL (XML User-interface Language——基于XML的用户接口语言)的组件。利用直观的事件驱动模型，你可以用具有XUL特性的组件来表示你的应用程序并通过由用户触发的监听事件来操作这些组件。目前，ZK 3.0 版本已发布。提供了基于XUL和XHTML现成丰富的组件：网格、标签页装饰器、树形目录、组合框、图表、滚动条、分割条、音频等等。此外，还提供了宏组件，能够开发新组件像搭积木一样简单和方便。编写脚本(Script)功能可以用EL expressions和你偏好的脚本语言，包含但不仅限于Java、JavaScript、Ruby、Groovy和MVEL的语言。值得一提的是，最新版本还集成了Google Maps, FCKeditor, Dojo以及 Timeline，并且提供对Google最新发布的手机操作平台Android的开发支持。
有人预测，Silverlight、 Flex等RIA框架的出现，将对AJAX框架构成严重威胁，我的看法刚好相反。Silverlight、Flex等是大型软件公司企图以私有 protocol 垄断新兴市场的老方法。然而因特网的巨大并不是任何人所能控制的。感谢Tim Berners-Lee等人无私的贡献，因特网已成为最公平最开放的平台了。事实上 Flex 不久前才刚转为 Open Source，这对定价超过一万美元的软件，算是个重大的挫败。
陈金洲观点
毫无疑问，AJAX被越来越多的接受。这不仅仅体现在技术的应用上，更体现在行业范围内的需求提升上。Web应用这种类型不仅仅被用在企业业务系统，更多被用在Web2.0应用中。这些应用意味着以前只能被几十人几百人使用的系统，突然之间会有几十万几百万的用户。用户有了更多选择，能够吸引用户驻留的，除了华丽的界面，那么就是流畅的操作界面和快速的响应。作为实现不打断用户操作的关键技术AJAX, 从吸引用户这一点上，具有不可替代的使命。
意味着华丽、AJAX的Web2.0应用同样也冲击着企业应用的需求。虽然没有统计数据，但可以看到越来越多的企业应用要求更直观的界面，更流畅的操作，更少的延迟。例如，在前两年，级联下拉框的实现，大多数的框架（或者应用）的实现是选中一个时刷新整个页面，然后根据选中的那个更新下一个下拉框的待选值列表。这个实现在今天看起来几乎是完全不可接受的，无论对客户还是对开发者。
开发者这边，去年还有关于AJAX几宗罪的讨论，然而现在看来，更多的讨论沉浸到了某一个具体技术中。在认清AJAX技术本质之后，更多的开发者或欣然接受，或用户要求，开始了AJAX相关技术的学习和使用。从我周围看来，曾经认为JavaScript是不太入流的语言的程序员，现在已然逐渐发现，JavaScript很有趣，很强大；用 JavaScript实现很酷的网页效果，很有成就感，等等。
另外， AJAX这个词本身，早已远远超越了它所代表的本来含义。AJAX原本是异步的JavaScript和XML。然而一看到一个绚丽的网页（Web应用），几乎大多数人，具备Web相关知识的，第一个问题往往是：这用的AJAX吧？──AJAX现在几乎成为圆角、拖拽、绚丽、无刷新的代名词。当一个名称上升为一种概念、一种直觉的时候，我们应该知道，相关的技术应用到了什么程度。
现在几乎已经没有人手工与XMLHttp对象打交道，绝大多数的开发者都使用Buffalo, DWR, Prototype等辅助库、框架进行开发。
AJAX框架的选择
由于现在很少有人只用一种AJAX技术，我将AJAX框架的范围扩大一些，分为偏重展现、偏重传输、工具型三个部分。由于我自己的Web工作语言主要在 Java, Ruby以及Python之间，以下的评价不包含PHP, .NET下的一些工具。另外，对自己开发的和它的主要竞争者DWR有主要的比较，其他的仅作泛泛评述，估妄言之。
偏重展现：YUI, Qooxdoo, Dojo
·YUI ：目前设计比较完整，美观，全面的界面工具库。
·Qooxdoo: 开源的另一种选择。
·Dojo: 比较完善的库结构，丰富的界面控件。
偏重传输：Buffalo, DWR
Buffalo特性：
1、基于prototype。如果你的AJAX应用也是基于prototype，那么可以减少重复加载prototype的带宽，并且获得相当一致的编程概念。
2、Bind: 提供了对结果数据的处理，直接将数据绑定到页面对象并展示，这是一个动人的特性。在2.0中，Bind能力更加强大，能够将值直接绑定到表单元素、表格、 DIV/Span、甚至整个表单上。关键是这种绑定是无侵入并且与buffalo整体结构完全整合，对外表现只有一个简单的 {{buffalo.bindReply}}或者{{Buffalo.Bind.bind}}即可。
3、序列化：Buffalo支持任意对象，任意深度，任意数据结构的Java到JavaScript以及JavaScript到Java的双向序列化，并且支持引用。
4、生命周期对象访问：1.2.4之前需要继承一个BuffaloService,从1.2.4开始就不需要继承了，引入了线程安全的 BuffaloContext对象，只需要通过BuffaloContext.getContext()即可获得一个线程安全的引用，并且对 Request的各种属性进行操作。
5、对Collection/Array的模糊处理：Buffalo中提供了对Collection/Array对象的模糊识别能力。例如：服务器端有一个方法需要List参数，客户端传递过去一个javascript数组就可以了，不需要费心的组装对象。
6、客户端组装对象：Buffalo支持在客户端组装对象，甚至可以直接将整个表单序列化为一个对象作为参数传给远程客户端。
7、对重载方法的处理能力：由于Java与JavaScript之间类型的不匹配，DWR的代码生成无法对重载方法进行处理。例如，sum(double,double), sum(int, int) DWR很可能不知道你要调用哪一个。从2.0开始Buffalo支持了对重载的处理。
DWR特性：
1、支持Batch，可以将多个Service函数调用放在一个XMLHttpRequest请求中完成。
2、Converter：可以转换任意类型的Java对象到JavaScript，并允许直接使用。例如：Customer类包含一个address变量，当AjaxCall返回Customer对象的时候，可以直接在Javascript中使用customer.address来获得Address的信息。
3、允许Expose部分函数和属性。（Buffalo无限制，可以访问Service中的任意函数。）
4、DWR2.0中提出了Reverse Ajax，提供在Java代码中来处理页面上元素的功能。
工具型：Prototype, JQuery, Dojo
·Prototype：得益于Ruby语言的设计，它使得你能够以几乎类似于编写Ruby的方式编写JavaScript。由于绑定在Ruby On Rails的发行包中，它成为近两年最流行的AJAX工具。早期它小巧灵活，现在由于加入太多的特性，日渐臃肿。目前1.6版本大小已经超过120K。
·JQuery：Prototype的主要竞争者。简单是它最大的优点。大多数常见的复杂操作、效果，JQuery的代码量能够比Prototype少50%以上。
·Dojo：采用类似于Java包的管理方式，实现按需加载JS。提供了全面的AJAX、DOM操作支持。然而需要在HTML TAG中嵌入额外的属性，使得网页不能遵守W3C标准，不少开发者对此耿耿于怀。
来自RIA框架的冲击？
我并不赞同这种说法，恰恰相反，我认为像Silverlight，Flex等这些RIA框架要考虑来自Web应用的冲击。Web领域几乎已经不存在技术壁垒，能做哪些，那些不适合，负载均衡等等已经有充分的资源可以参考。各种模式都可以灵活的应用到其中，各种测试工具（如Selenium网页测试工具）、开发工具支持得非常出色。而RIA框架要考虑的问题远远要比现在的Web应用多得多。除了RIA所承诺的更容易的实现华丽的效果──在多种JS库的支持下这些效果在Web下并非难事──他们有更多的问题需要考虑：资源的获取和释放，测试的支持，本地存储的问题，事件机制，状态的同步，客户机、服务器数据交互机制（序列化反序列化）等等。RIA想如同现在的Web应用般大规模，远不到时候。大多数基于RIA应用的考虑是让应用能够离线运行，然而与此同时浏览器也在发展，基于网页的本地存贮已经在Google Reader中可以实际使用。也许某一天浏览器就是一个完美的RIA平台，Web应用只需添加本地存贮支持就可以离线使用──类似于Flex、 Silverlight的RIA技术，与Web应用，哪个更容易被接受，还真难见分晓
叶明宪观点
AJAX 已流行二、三年了，现今所谓 Web 2.0 网站或多或少有 AJAX 影子。然而新的 AJAX 框架仍不断诞生，现有的框架也在持续推出新的版本。为什么？
首先，AJAX应用范围持续扩大，从 del.icio.us 简易的编辑功能，到 999fang.com 整合 AJAX 和数据库搜寻，到 Google Spreadsheets 近似 Windows 应用程序。再者，AJAX已缓步进入企业应用。除了User Friendly，安全、开发及维护成本、与现有应用服务器、服务和开发环境的整合度等更是企业应用的重点。这些都已跳脱早期框架的范畴。
目前 AJAX 在企业应用正处于 Geoffrey Moore 所谓的Chasm中，预期接下二年会慢慢大量投入使用。而在消费型网站的应用正走过高成长期，聚光灯的焦点将逐渐移到如Google Spreadsheets的应用。
在这种背景之下，AJAX框架如雨后春笋，层出不穷。很多开发者朋可能都有自己的偏好，但是仍有一些开发人员面对这么多框架，可能会感觉无从下手。我们可以从多个面向来看这些框架。
从功能面来看，可分为以下几类：
1、浏览器端的底层链接库，如 Prototype, script.aculo.us, jQuery 等。
2、浏览器端UI组件库，如 Ext-JS, Dojo 等。
3、整合式框架，如 ZK, Backbase, IceFaces 等。
其中，底层链接库应用最广、轻巧易整合力但功能有限。整合式框架则包括浏览器端及服务器端的完整框架。
DWR和GWT则较难分类。DWR基本是JavaScript-to-Java 的 RPC框架，而GWT则是在RPC 加上浏览器端开发工具。
从应用面来看，可粗分网站应用和企业应用。底层链接库多用于网站应用或当其它框架的基础。UI组件库则二者都有，而整合式框架侧重在企业应用。
从系统架构来看，可分Client-centric和Server-centric。所谓 Client-centric 是指你写的程序代码(UI部份)主要执行的地方在客户端 (即浏览器)，而 Server-centric 则在服务器端。大部份框架多是 Client-centric，如Dojo, Prototype，GWT，Ext-JS，Backbase等。而Server-centric则以ZK为代表。
一般读者不太注意架构的差别，但它是决定开发及维护成本的关键。
读到这里，可能仍有人心存疑问：到底哪种框架适合我的应用？事实上，没有单一个框架适合所有应用。对于强调简易直觉接口的Web 2.0网站而言，通常只有几个需要 AJAX化的功能，可藉由浏览器端的底层链接库的帮助，并投入相当资源，以使这些AJAX 化出众夺目才是最重要的。对于现有Web应用程序，如架构于Struts、JSP或JSF等，则可依其对JavaScript熟悉度而选择浏览器端UI组件库或整合式框架。使用浏览器端 UI组件库，需要较多定制化JavaScript程序代码才能整合到原应用程序中。而使用整合式框架，则要视其是否支持现已使用的架构。例如，若使用.NET平台，则只能使用 Microsoft的框架。若使用JSP则可使用ZK和Backbase。若使用JSF则可使用ZK，Backbase和IceFaces。
利用ZK框架设计的Web应用程序具备丰富的胖客户端特性和简单的设计模型。ZK包括一个基于AJAX可自动进行交互式操作的事件驱动引擎和一套兼容 XUL (XML User-interface Language——基于XML的用户接口语言)的组件。利用直观的事件驱动模型，你可以用具有XUL特性的组件来表示你的应用程序并通过由用户触发的监听事件来操作这些组件。目前，ZK 3.0 版本已发布。提供了基于XUL和XHTML现成丰富的组件：网格、标签页装饰器、树形目录、组合框、图表、滚动条、分割条、音频等等。此外，还提供了宏组件，能够开发新组件像搭积木一样简单和方便。编写脚本(Script)功能可以用EL expressions和你偏好的脚本语言，包含但不仅限于Java、JavaScript、Ruby、Groovy和MVEL的语言。值得一提的是，最新版本还集成了Google Maps, FCKeditor, Dojo以及 Timeline，并且提供对Google最新发布的手机操作平台Android的开发支持。
有人预测，Silverlight、 Flex等RIA框架的出现，将对AJAX框架构成严重威胁，我的看法刚好相反。Silverlight、Flex等是大型软件公司企图以私有 protocol 垄断新兴市场的老方法。然而因特网的巨大并不是任何人所能控制的。感谢Tim Berners-Lee等人无私的贡献，因特网已成为最公平最开放的平台了。事实上 Flex 不久前才刚转为 Open Source，这对定价超过一万美元的软件，算是个重大的挫败。
陈金洲观点
毫无疑问，AJAX被越来越多的接受。这不仅仅体现在技术的应用上，更体现在行业范围内的需求提升上。Web应用这种类型不仅仅被用在企业业务系统，更多被用在Web2.0应用中。这些应用意味着以前只能被几十人几百人使用的系统，突然之间会有几十万几百万的用户。用户有了更多选择，能够吸引用户驻留的，除了华丽的界面，那么就是流畅的操作界面和快速的响应。作为实现不打断用户操作的关键技术AJAX, 从吸引用户这一点上，具有不可替代的使命。
意味着华丽、AJAX的Web2.0应用同样也冲击着企业应用的需求。虽然没有统计数据，但可以看到越来越多的企业应用要求更直观的界面，更流畅的操作，更少的延迟。例如，在前两年，级联下拉框的实现，大多数的框架（或者应用）的实现是选中一个时刷新整个页面，然后根据选中的那个更新下一个下拉框的待选值列表。这个实现在今天看起来几乎是完全不可接受的，无论对客户还是对开发者。
开发者这边，去年还有关于AJAX几宗罪的讨论，然而现在看来，更多的讨论沉浸到了某一个具体技术中。在认清AJAX技术本质之后，更多的开发者或欣然接受，或用户要求，开始了AJAX相关技术的学习和使用。从我周围看来，曾经认为JavaScript是不太入流的语言的程序员，现在已然逐渐发现，JavaScript很有趣，很强大；用 JavaScript实现很酷的网页效果，很有成就感，等等。
另外， AJAX这个词本身，早已远远超越了它所代表的本来含义。AJAX原本是异步的JavaScript和XML。然而一看到一个绚丽的网页（Web应用），几乎大多数人，具备Web相关知识的，第一个问题往往是：这用的AJAX吧？──AJAX现在几乎成为圆角、拖拽、绚丽、无刷新的代名词。当一个名称上升为一种概念、一种直觉的时候，我们应该知道，相关的技术应用到了什么程度。
现在几乎已经没有人手工与XMLHttp对象打交道，绝大多数的开发者都使用Buffalo, DWR, Prototype等辅助库、框架进行开发。
AJAX框架的选择
由于现在很少有人只用一种AJAX技术，我将AJAX框架的范围扩大一些，分为偏重展现、偏重传输、工具型三个部分。由于我自己的Web工作语言主要在 Java, Ruby以及Python之间，以下的评价不包含PHP, .NET下的一些工具。另外，对自己开发的和它的主要竞争者DWR有主要的比较，其他的仅作泛泛评述，估妄言之。
偏重展现：YUI, Qooxdoo, Dojo
·YUI ：目前设计比较完整，美观，全面的界面工具库。
·Qooxdoo: 开源的另一种选择。
·Dojo: 比较完善的库结构，丰富的界面控件。
偏重传输：Buffalo, DWR
Buffalo特性：
1、基于prototype。如果你的AJAX应用也是基于prototype，那么可以减少重复加载prototype的带宽，并且获得相当一致的编程概念。
2、Bind: 提供了对结果数据的处理，直接将数据绑定到页面对象并展示，这是一个动人的特性。在2.0中，Bind能力更加强大，能够将值直接绑定到表单元素、表格、 DIV/Span、甚至整个表单上。关键是这种绑定是无侵入并且与buffalo整体结构完全整合，对外表现只有一个简单的 {{buffalo.bindReply}}或者{{Buffalo.Bind.bind}}即可。
3、序列化：Buffalo支持任意对象，任意深度，任意数据结构的Java到JavaScript以及JavaScript到Java的双向序列化，并且支持引用。
4、生命周期对象访问：1.2.4之前需要继承一个BuffaloService,从1.2.4开始就不需要继承了，引入了线程安全的 BuffaloContext对象，只需要通过BuffaloContext.getContext()即可获得一个线程安全的引用，并且对 Request的各种属性进行操作。
5、对Collection/Array的模糊处理：Buffalo中提供了对Collection/Array对象的模糊识别能力。例如：服务器端有一个方法需要List参数，客户端传递过去一个javascript数组就可以了，不需要费心的组装对象。
6、客户端组装对象：Buffalo支持在客户端组装对象，甚至可以直接将整个表单序列化为一个对象作为参数传给远程客户端。
7、对重载方法的处理能力：由于Java与JavaScript之间类型的不匹配，DWR的代码生成无法对重载方法进行处理。例如，sum(double,double), sum(int, int) DWR很可能不知道你要调用哪一个。从2.0开始Buffalo支持了对重载的处理。
DWR特性：
1、支持Batch，可以将多个Service函数调用放在一个XMLHttpRequest请求中完成。
2、Converter：可以转换任意类型的Java对象到JavaScript，并允许直接使用。例如：Customer类包含一个address变量，当AjaxCall返回Customer对象的时候，可以直接在Javascript中使用customer.address来获得Address的信息。
3、允许Expose部分函数和属性。（Buffalo无限制，可以访问Service中的任意函数。）
4、DWR2.0中提出了Reverse Ajax，提供在Java代码中来处理页面上元素的功能。
工具型：Prototype, JQuery, Dojo
·Prototype：得益于Ruby语言的设计，它使得你能够以几乎类似于编写Ruby的方式编写JavaScript。由于绑定在Ruby On Rails的发行包中，它成为近两年最流行的AJAX工具。早期它小巧灵活，现在由于加入太多的特性，日渐臃肿。目前1.6版本大小已经超过120K。
·JQuery：Prototype的主要竞争者。简单是它最大的优点。大多数常见的复杂操作、效果，JQuery的代码量能够比Prototype少50%以上。
·Dojo：采用类似于Java包的管理方式，实现按需加载JS。提供了全面的AJAX、DOM操作支持。然而需要在HTML TAG中嵌入额外的属性，使得网页不能遵守W3C标准，不少开发者对此耿耿于怀。
来自RIA框架的冲击？
我并不赞同这种说法，恰恰相反，我认为像Silverlight，Flex等这些RIA框架要考虑来自Web应用的冲击。Web领域几乎已经不存在技术壁垒，能做哪些，那些不适合，负载均衡等等已经有充分的资源可以参考。各种模式都可以灵活的应用到其中，各种测试工具（如Selenium网页测试工具）、开发工具支持得非常出色。而RIA框架要考虑的问题远远要比现在的Web应用多得多。除了RIA所承诺的更容易的实现华丽的效果──在多种JS库的支持下这些效果在Web下并非难事──他们有更多的问题需要考虑：资源的获取和释放，测试的支持，本地存储的问题，事件机制，状态的同步，客户机、服务器数据交互机制（序列化反序列化）等等。RIA想如同现在的Web应用般大规模，远不到时候。大多数基于RIA应用的考虑是让应用能够离线运行，然而与此同时浏览器也在发展，基于网页的本地存贮已经在Google Reader中可以实际使用。也许某一天浏览器就是一个完美的RIA平台，Web应用只需添加本地存贮支持就可以离线使用──类似于Flex、 Silverlight的RIA技术，与Web应用，哪个更容易被接受，还真难见分晓