如果要用“充满魅力”一词来形容当前流行的交互设计，那么首推创建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；
· 通过XML和XSLT来进行数据交换和处理；
经典的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去改善用户体验，而不是把它弄得更糟。