尽管如此，Web交互设计人员还是不可避免地对创建桌面应用软件的同事怀有一丝妒忌。桌面应用程序所拥有的功能丰富性和响应能力似乎是Web目前无法达到的。简单地让Web应用程序迅速蔓延，会在我们所提供的体验和用户从桌面应用程序获取的体验之间形成一道鸿沟。

但现在，这道鸿沟正被逐渐填平。让我们看看Google Suggest。根据您输入的内容，相关的条目便几乎立即更新。我们再看Google Maps。利用光标，在刻度线上移动来放大地图或者缩小，所有的一切几乎都是即时的，完全不用等待页面的刷新。

Google Suggest和Google Maps就是这种新型Web应用程序的两个例子，我在Adaptive Path上把这种理念称为 Ajax。也就是Asynchronous JavaScript + XML的简写，它预示着Web可能发生一次重大的变革。

Ajax的定义

Ajax并不是一种新技术，它实际上是几种已经在各自领域大行其道的技术的强强结合。Ajax由以下内容组成：

·            基于标准化的XHTML和CSS；

• 通过DOM（Document Object Model）实现动态显示和交互；

·            通过XML和XSLT来进行数据交换和处理；

• 使用XMLHttpRequest通过异步方式获取数据；

• 使用JavaScript来整合以上所有的技术

经典的Web应用程序模型工作方式如下：大多数用户动作在界面上激发一个HTTP请求到web服务器。服务器做一些处理——获取数据，处理数字，与现有的应用系统进行沟通——最后返回HTML到客户端。这样的模型适合于以超文本为基础的Web应用程序，但作为一个强调用户体验的狂热分子（The Elements of User Experience一书的拥护者），我们认为超文本造就Web成功的东西，却并不一定满足软件应用程序的要求。

传统的Web应用程序模型技术上来说意义非凡，但它并不适用于创建完美的用户体验。当服务器在做数据处理的时候，用户在干什么呢？没错，他们在等待。一个任务所需的步骤越多，用户需要等待的次数也越多。

显然，当我们设计Web应用程序的时候，我们不应该让用户傻等。界面一旦加载完成，为什么还要因为程序需要从服务器传输一些东西而中断用户交互呢？实际上，用户为什么要看到程序与服务器的联系？

为什么Ajax与众不同

Ajax应用程序摒弃了“开—关—开—关”的交互形式，在用户与服务器之间引入了一个中间件——Ajax引擎。看上去在应用程序上添加一个层面会减少响应，但事实上恰好相反。

不同于加载一个网页是，用户会话一旦建立，浏览器就加载一个Ajax引擎——由JavaScript编写并通常放置在一个隐藏帧内。引擎的责任包括构造用户操作界面以及与服务器的沟通。Ajax引擎允许用户与应用程序的交互异步进行——无须直接访问服务器。所以用户永远不会在服务器处理数据期间瞪眼面对一个白屏和沙漏图标。

用户动作的处理由传统的表单提交来激发一个HTTP请求，变为Javascript调用Ajax引擎。给用户的回应不用等到服务器处理后返回——比如简单的数据校验，在内存中编辑数据，甚至一些导航功能——都直接由引擎来处理。如果引擎需要从服务器获取些数据——提交数据给服务器处理，加载额外的界面代码，或者获取新数据——引擎通常以XML格式激发一个异步的请求，用户端完全没有被中断的感觉。

谁在使用Ajax

Google在Ajax开发上投入了巨大的精力。去年Google推出的几大产品——Orkut、Gmail、Google Groups最终测试版、Google Suggest和Google Maps——都是基于Ajax的应用。其他还包括：有着很多备受人们赞誉特性的Flickr（http://www.flickr.com/）基于Ajax，Amazon的A9.com搜索引擎也使用了类似的技术。

这些项目证实Ajax并不是一个技术性的实验品，它可以实践在现实世界的应用中。它也不是一种只能在实验室中运用的技术。Ajax适用于从简单的单函数Google Suggest到非常复杂的Google Maps等各种规模的应用程序。

在Adaptive Path，我们已经基于Ajax的理念工作了好几个月，我们意识到我们也仅仅是接触到Ajax所能带来的非凡体验的一点皮毛。Ajax是Web应用程序的一个重要发展，并且其重要性还在逐步增长。因为许多开发人员已经熟悉Ajax所包含的技术，我们期望看到更多的组织能够像Google那样通过Ajax获得更大的竞争优势。

更进一步

创建Ajax应用程序所面临的最大挑战并不在技术上。Ajax的核心技术是成熟的，稳定并被广泛应用着。这些挑战在于：应用设计人员忘掉所有我们所熟知的网络限制，去想像更宽广、更深远的可能情况。

接下来会很有趣。

Ajax Q&A

2005年3月13日：自从Jesse发表了该文，他收到了不计其数的咨询Ajax问题的信件，Jesse回复了其中有代表性的问题并整理成Q&A。

Q：是Adaptive Path还是Google发明了Ajax？Adaptive Path是否协助开发了Google的Ajax应用程序？
A：Ajax并不是由Adaptive Path或者Google发明的。Google最新的产品是Ajax应用程序最具代表性的例子。Adaptive Path没有参与Google的开发，但我们在为其他的一些客户做一些与Ajax相关的工作。

Q：Adaptive Path会出售Ajax组件或者注册Ajax这个商标吗？我从哪里可以下载到它？
A：Ajax并不是一个具体的软件或程序，它是一种理念——关于用合理的技术构建Web应用程序架构的思考。Ajax这个名称和它的理念都不是Adaptive Path私有的。

Q：Ajax只不过是XMLHttpRequest的别名吗？
A：不是。XMLHttpRequest只是Ajax的一个组成部分。XMLHttpRequest让客户端与服务器的异步通讯成为可能；Ajax是本文描述的一个整体理念，它不仅依赖于XMLHttpRequest，还包括CSS、DOM和其他技术等等。

Q：为什么你会起这么个名字？
A：我们需要一个简短的表示“Asynchronous JavaScript+CSS+DOM+XMLHttpRequest”的新词来与客户谈我们的理念。

Q：与服务器异步通讯的技术产生很多年了，Ajax何以称为新理念？
A：Ajax包含的技术被大量应用在现实世界中以至于改变了Web的基础交互模式是一个新现象。Ajax是针对现在而言，因为这些技术离工业化应用还需要很多时间去开发。

Q：Ajax是一个技术平台或者架构吗？
A：都是。Ajax是一系列技术的无缝集合。

Q：Ajax最适合于什么样的应用？
A：我也不知道。因为这是一个相当新的理念，就我们的理解而言，Ajax应用还处于初期阶段。有时候传统的Web应用程序模型可能更为适合。

Q：是否可以理解为Adaptive Path就是取代anti-Flash？
A：完全不是。Macromedia是Adaptive Path的客户之一，并且我们长期为Flash技术做技术支持。待Ajax成熟后，我认为对于具体的问题，Ajax有时候会是一个更好的解决方案，同样有时候Flash也许做得更好。我们也有兴趣探讨两者的结合。（比如Flickr，它结合了两者）。

Q：Ajax在易用性和浏览器兼容性上是否有限制？Ajax是否会与后退按钮冲突？Ajax与REST（雷达电子扫描技术）兼容吗？Ajax的开发有哪些安全考虑？Ajax能为那些禁止Javascript运行的用户工作吗？
A：所有这些问题的答案，我只能说“可能”。已经有很多的开发者着手这些方面的工作。要评估Ajax的所有限制，我想还需要做很多工作，我们希望Ajax开发社区能揭示更多的信息。

Q：你所提到的Google的一些应用中实际上并没有使用XML。我一定要在Ajax应用中使用XML或XSLT吗？
A：不是，对于Ajax客户端，XML作为数据交换的载体是支持最为完善的（XMLHttpRequest，DOM支持）。当然，你没有理由不接受可以达到同样效果的技术，例如JavaScript Object Notation（http://www.crockford.com/JSON/）或者其他类似的数据交换的格式。

Q：Ajax应用比传统的Web应用程序方便开发吗？
A：也不尽然。Ajax的应用不可避免要在客户端运行复杂的JavaScript脚本。编写复杂并且高效稳定的脚本并不是一件容易的事情，优秀的开发工具和框架能帮助我们接受这一挑战。

Q：Ajax应用程序总比传统的Web应用程序程序更友好吗？
A：不一定，Ajax给交互设计人员更多的灵活性。能力越大，责任也越大。我们必须小心使用Ajax去改善用户体验，而不是把它弄得更糟。

　　1、XMLHttpRequest的有效性

　　Ajax开发者面对的一个最大问题是当XMLHttpRequest不可用时如何反应。虽然大部分现代浏览器支持 XMLHttpRequest，但还是有少量的用户，他们的浏览器不能支持，或由于浏览器安全设置而阻止对XMLHttpRequest的使用。若你的 Web应用发布于公司内部的Intranet上，你很可能可以指定支持哪种浏览器，并可以确保XMLHttpRequest是可用的。若你在公共WEB上发布，则你必须意识到由于假定XMLHttpRequest是可用的，所有就阻止了老浏览器、手持设备浏览器等等用户来使用你的系统。

　　然而，你应该尽力保证应用系统“正常降级”使用，在系统中保留适用于不支持XMLHttpRequest的浏览器的功能。在购物车例子中，最好的方法是有一个Add to Cart按钮，可以进行常规的提交处理，并刷新页面来反映购物车状态的变化。Ajax行卫可以在页面被载入时通过JavaScript添加到页面中，只在 XMLHttpRequest可用的情况下，为每个Add to Cart按钮加上JavaScript处理函数。另一个方法是在用户登录时检测XMLHttpRequest，再决定是提供Ajax版本还是常规基于 form提交的版本。

　　2、可用性考虑

　　围绕着Ajax应用的大部分问题都是很普通的问题。例如，让用户知道他们的输入已经被注册并处理，是很重要的，因为在 XMLHttpRequest处理过程中并不能提供通常的漏斗旋转光标。一种方法是将“确认”按扭上的文本替换为“正在更新中…”，以避免用户在等待响应时多次点击按钮。

　　另一个问题是，用户可能没有注意到他们正在观看的页面已经被更新。可以通过使用各种视觉技巧来将用户的眼光吸引到页面的更新区域。还有一个问题是通过Ajax更新页面打断了浏览器“退回前页”按钮的正常工作，地址栏中的URL不能反映页面的全部状态，并且不能使用书签功能。参见Resource 章节中列出的网站地址上的文章来了解更多Ajax应用关于可用性方面的问题。

　　3、服务器负载

　　使用Ajax界面代替传统的基于form的界面可能戏剧性地增加传递到服务器的请求数量。例如，一个普通的Google搜索给服务器造成一次命中，并在用户确认搜索表单时发生。然而，Google Suggest，将会试图自动完成你的搜索词，在用户打字时将会往服务器发送多个请求。在开发一个Ajax应用时，要注意到你将会发送多少请求到用户器端，以及服务器的负载指标。你可以通过在客户端适当地缓存请求、与服务器响应来缓减负载压力。你也应该在设计Ajax应用时尽量在客户端处理更多的逻辑，而不用与服务器端通讯。

　　4、处理异步

　　一定要记住，没有任何东西可以保证XMLHttpRequest将会按照它们被发送的顺序来依次结束。实际上，你在设计系统时，脑子里应该始终假定它们不会按原来顺序结束。在购物车例子中，使用了一个最后更新的时间戳来保证最新的数据不会被改写。这个非常基本的方法可以在购物车场景中工作，但可能不能在其它情况下工作。在设计时刻就要考虑你该如何处理异步服务器响应。

　　结论

　　你现在应该对于Ajax的基本原则有了一个良好的了解，另外，你应该理解一些更高级的随Ajax方法而来的设计问题。创建一个成功的Ajax应用需要一系列的方法—从JavaScript UI设计到服务器端架构—但是你现在应该已经具备了需要使用到的Ajax核心知识。