Ajax: 一个建立Web应用的新途径
如果要问做什么事是最有吸引力，那就是创建Web应用。毕竟，上次你听到有人称赞某产品的交互设计是什么时候的事了？(除了iPod之外) 它们都很cool, 而且都是很创新的项目。

抛开这些不管，Web设计者们对设计交互式的Web没有什么更好的办法，却对我们做桌面软件的同事投去少许羡慕的目光.桌面应用程序有丰富的界面以及对于Web程序来说无法比拟的响应能力。同样，Web的快速发展，在我们所提供的体验和用户从桌面应用程序所得到的体验间产生巨大的差距

而如今差距正在消失。请看看“Google建议(Google Suggest)”. 观察它按你的输入显示建议条目的更新速度，几乎是立即更新的。再看看"Google Maps". 放大，用你的鼠标搬动和滚动。这些动作几乎是立即响应的，不用等待页面刷新。

"Google Suggest"和"Google Maps" 是采用Ajax技术的两个典型例子。Ajax是Asynchronous JavaScript and XML的简称，它表现出一个Web开发上的根本转变，那就是，Web上可能做些什么. Ajax的定义

Ajax不是一个技术，它实际上是几种技术，每种技术都有其独特这处，合在一起就成了一个功能强大的新技术。Ajax包括：

XHTML和CSS
使用文档对象模型(Document Object Model)作动态显示和交互
使用XML和XSLT做数据交互和操作
使用XMLHttpRequest进行异步数据接收
使用JavaScript将它们绑定在一起

传统的web应用模型工作起来就象这样：大部分界面上的用户动作触发一个连接到Web服务器的HTTP请求。服务器完成一些处理---接收数据，处理计算，再访问其它的数据库系统，最后返回一个HTML页面到客户端。这是一个老套的模式，自采用超文本作为web使用以来，一直都这样用, 但看过《The Elements of User Experience》的读者一定知道，是什么限制了Web界面没有桌面软件那么好用。




图1: 传统Web应用模型(左)与Ajax模型的比较(右).

这种旧的途径让我们认识到了许多技术，但它不会产生很好的用户体验。当服务器正在处理自己的事情的时候，用户在做什么？没错，等待。每一个动作，用户都要等待。

很明显，如果我们按桌面程序的思维设计Web应用，我们不愿意让用户总是等待。当界面加载后，为什么还要让用户每次再花一半的时间从服务取数据？实际上，为什么老是让用户看到程序去服务器取数据呢？ Ajax如何不同凡响

通过在用户和服务器之间引入一个Ajax引擎，可以消除Web的开始－停止－开始－停止这样的交互过程. 它就像增加了一层机制到程序中，使它响应更灵敏，而它的确做到了这一点。

不像加载一个页面一样，在会话的开始，浏览器加载了一个Ajax引擎---采用JavaScript编写并且通常在一个隐藏frame中。这个引擎负责绘制用户界面以及与服务器端通讯。Ajax引擎允许用异步的方式实现用户与程序的交互－－不用等待服务器的通讯。所以用户再不不用打开一个空白窗口，看到等待光标不断的转，等待服务器完成后再响应。




图 2: 传统Web应用的同步交互过程(上)和Ajax应用的异步交互过程的比较(下).

通常要产生一个HTTP请求的用户动作现在通过JavaScript调用Ajax引擎来代替. 任何用户动作的响应不再要求直接传到服务器---例如简单的数据校验，内存中的数据编辑，甚至一些页面导航---引擎自己就可以处理它. 如果引擎需要从服务器取数据来响应用户动作---假设它提交需要处理的数据，载入另外的界面代码，或者接收新的数据---引擎让这些工作异步进行，通常使用XML, 不用再担误用户界面的交互。 谁在使用Ajax

在采用Ajax的开发上面，Google做了巨大的投资。去年Google所有主要的产品都用了这项技术---Orkut, Gmail, 以及最近的beta版的Google Groups, Google Suggest和Google Maps---它们全是Ajax的应用。(要想了解更多这些Ajax实际的技术细节，请看它们的分析文章:Gmail, Google Suggest, Google Maps). 其它的像：Flickr, 采用许多人们喜欢的Ajax特性，还有Amazon的A9.com搜索引擎也采用类似的技术。

这些项目证明了Ajax不只是学术上的，也有许多真实世界成功应用。这不是什么实验室里的技术。Ajax的应用可大可小，从非常简单的，像单一功能的Google Suggest到非常复杂的Google Maps.




Ajax：Web应用开发新理念

如果要用“充满魅力”一词来形容当前流行的交互设计，那么首推创建Web应用程序。毕竟，当你最终听到某人倾倒于产品的交互设计，难道不是在网上？（Okay，我承认iPod除外）。所有追求酷，追求创新的新项目都是联机应用的。

尽管如此，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去改善用户体验，而不是把它弄得更糟。