优点、前提和批评

使用Ajax的最大优点就是能在不更新整个页面的前提下维护数据。这使得Web应用程序更为迅捷地响应用户交互，并避免了在网络上发送那些没有改变的信息。

Ajax不需要任何浏览器插件，但需要用户允许JavaScript在浏览器上执行。就像DHTML应用程序那样，Ajax应用程序必须在众多不同的浏览器和平台上经过严格的测试。随着Ajax的成熟，一些简化Ajax使用方法的程序库也相继问世。同样，也出现了另一种辅助程序设计的技术，为那些不支持JavaScript的用户提供替代功能。

对应用Ajax最主要的批评就是，它可能破坏浏览器后退按钮的正常行为（参见Jakob Nielsen’s的《Web设计10大错误（1999年）》）。在动态更新页面的情况下，用户无法回到前一个页面状态，因为浏览器仅能记忆历史记录中的静态页面。一个被完整读入的页面与一个已经被动态修改过的页面之间的差别非常微妙；用户通常会希望单击后退按钮能够取消他们的前一次操作，但是在Ajax应用程序中，这将无法实现。开发者们想出了种种办法来解决这个问题，大多数都是在用户单击后退按钮访问历史记录时，通过创建或使用一个隐藏的IFRAME来重现页面上的变更。（例如，当用户在Google Maps中单击后退时，它在一个隐藏的IFRAME中进行搜索，然后将搜索结果反映到Ajax元素上，以便将应用程序状态恢复到当时的状态。）

一个相关的观点认为，使用动态页面更新使得用户难于将某个特定的状态保存到收藏夹中。该问题的解决方案也已出现，大部分都使用URL片断标识符（通常被称为锚点，即URL中#后面的部分）来保持跟踪，允许用户回到指定的某个应用程序状态。（许多浏览器允许JavaScript动态更新锚点，这使得Ajax应用程序能够在更新显示内容的同时更新锚点。）这些解决方案也同时解决了许多关于不支持后退按钮的争论。

进行Ajax开发时，网络延迟——即用户发出请求到服务器发出响应之间的间隔——需要慎重考虑。不给予用户明确的回应，没有恰当的预读数据，或者对XMLHttpRequest的不恰当处理，都会使用户感到延迟，这是用户不希望看到的，也是他们无法理解的。通常的解决方案是，使用一个可视化的组件来告诉用户系统正在进行后台操作并且正在读取数据和内容。

开发Ajax应用面临的挑战及解决方案

对程序员而言，开发Ajax应用最头痛的问题莫过于以下几点：

1. Ajax在本质上是一个浏览器端的技术，首先面临无可避免的第一个问题即是浏览器的兼容性问题。各家浏览器对于JavaScript/DOM/CSS的支援总有部分不太相同或是有Bug，甚至同一浏览器的各个版本间对于JavaScript/DOM/CSS的支援也有可能部分不一样。这导致程序员在写Ajax应用时花大部分的时间在调试浏览器的兼容性而非在应用程序本身。因此，目前大部分的Ajax程序库或开发框架大多以js程序库的形式存在，以定义更高阶的JavaScript API 、JavaScript对象（模板）、或者JavaScript Widgets来解决此问题。如prototype.js。
2. Ajax技术之主要目的在于局部交换客户端及服务器间之数据。如同传统之主从架构，无可避免的会有部分的业务逻辑会实现在客户端，或部分在客户端部分在服务器。由于业务逻辑可能分散在客户端及服务器，且以不同之程序语言实现，这导致Ajax应用程序极难维护。如有使用者接口或业务逻辑之更动需求，再加上前一个JavaScript/DOM/CSS之兼容性问题，Ajax应用往往变成程序员的梦靥。针对业务逻辑分散的问题，Ajax开发框架大致可分为两类：
   • 将业务逻辑及表现层放在浏览器，数据层放在服务器：因为所有的程序以JavaScript执行在客户端，只有需要数据时才向服务器要求服务，此法又称为胖客户端（fat client）架构。服务器在此架构下通常仅用于提供及储存数据。此法的好处在于程序员可以充分利用JavaScript搭配业务逻辑来做出特殊的使用者接口，以符合终端使用者的要求。但是问题也不少，主因在第一，JavaScript语言本身之能力可能不足以处理复杂的业务逻辑。第二，JavaScript的执行效能一向不好。第三，JavaScript存取服务器数据，仍需适当的服务器端程序之配合。第四，浏览器兼容性的问题又出现。有些Ajax开发框架如DWR企图以自动生成JavaScript之方式来避免兼容的问题，并开立通道使得JavaScript可以直接叫用服务器端的Java程序来简化数据的存取。但是前述第一及第二两个问题仍然存在，程序员必须费相当的力气才能达到应用程序之规格要求，或可能根本无法达到要求。
   • 将表现层、业务逻辑、及数据层放在服务器，浏览器仅有使用者接口引擎（User Interface engine）；此法又称为瘦客户端（thin client）架构，或中心服务器（server-centric）架构。浏览器的使用者接口引擎仅用于反映服务器的表现层以及传达使用者的输入回到服务器的表现层。由浏览器所触发之事件亦送回服务器处理，根据业务逻辑来更新表现层，然后反映回浏览器。因为所有应用程序完全在服务器执行，数据及表现层皆可直接存取，程序员只需使用服务器端相对较成熟之程序语言（如Java语言）即可，不需再学习JavaScript/DOM/CSS，在开发应用程序时相对容易。缺点在于使用者接口引擎以及表现层通常以标准组件的形式存在，如需要特殊组件（使用者接口）时，往往须待原框架之开发者提供，缓不济急。如开源码Ajax开发框架ZK目前支援XUL及XHTML组件，尚无XAML之支援。
3. Ajax是以异步的方式向服务器提交需求。对服务器而言，其与传统的提交表单需求并无不同，而且由于是以异步之方式提交，如果同时有多个Ajax需求及表单提交需求，将无法保证哪一个需求先获得服务器的回应。这会造成应用程序典型的多程序（process）或多线程（thread）的竞争（racing）问题。程序员因此必须自行处理或在JavaScript里面动手脚以避免这类竞争问题的发生（如Ajax需求未回应之前，先disable提交按钮），这又不必要的增加了程序员的负担。目前已知有自动处理此问题之开发框架似乎只有ZK。

外部连接

工具

• Atlas, 微软AJAX工具箱。
• Dojo工具箱, AJAX/DHTML工具箱。
• Prototype, 开放源代码框架。
• Sajax, 简单AJAX工具箱
• Rialto, Rich Internet AppLication TOolkit.
• ZK, 开放源代码AJAX/XUL框架。
• MochiKit 一个不自称AJAX的轻量级js库，支持Json。

门户

• Ajax Goals, AJAX Goals.
• Ajaxmatters, Ajaxmatters.
• Ajax Impact, Ajax Impact.

图书

• 《Ajax基础教程》, Foundations Of Ajax 中文版，人民邮电出版社图灵公司出版，第一本讲述Ajax技术的中文图书。ISBN 7-115-14481-8
• 《Ajax实战》，Ajax in Action 中文版，人民邮电出版社图灵公司出版，人称Ajax圣经的经典著作。ISBN 7-115-14717-5
• 《Head Rush Ajax》O’Reilly出版社

其他资源

• Ajax内部交流文档(新增DEMO)，AJAX简明教程。
• AJAX 上手篇，AJAX 上手篇
• 掌握 Ajax，掌握 Ajax