1.1 为什么需要Ajax富客户端？
建造一个富客户端毫无疑问要比设计一个网页复杂。付出这些额外的努力，动机何在？需要付出什么代价？而且……等一下，富客户端到底是什么？
富客户端的两个要点是：第一，它是“富”的；第二，它是“客户端”。
这好像是一句废话，别急，待我稍作解释。“富”是指客户端的交互模型，要有多样化的输入方式和符合直觉的及时反馈手段。说简单点儿，一个“富”的应用使用起来应该像是在使用现在的桌面应用一样，例如，就像是使用字处理软件（Word）或电子表格软件（Excel）。接下来，我们有必要仔细地考察一下所要涉及的各个方面。
1.1.1 比较用户体验
花几分钟使用一下你选中的应用（浏览器除外），记下它用到了哪些用户交互，然后马上回来。为了简短起见，我举一个电子表格的例子，但是，这里所涉及的要点是通用的，足以针对文本编辑器上的各种情形。
好，我们开始。先在电子表格中随便输入几个等式，注意到，可以以几种方式进行交互：编辑数据，用键盘和鼠标浏览数据，还可以使用鼠标拖拽来重新组织数据。
我做这些操作的时候，程序给了我反馈。移动鼠标的时候，光标改变了形状；当鼠标停在上面的时候，按钮变亮了；选中的文字也改变了颜色。窗口或者对话框被选中的时候，也和平常显得不一样了，等等（图1-1）。这些就是所谓“富”的交互。当然了，仍然有一些有待改进的地方，但这是一个好的开始。
OK，电子表格就是一个富客户端程序了吗？当然不是。
在电子表格或者类似的桌面应用中，业务逻辑和数据模型是在一个封闭的环境中运行的。在这个环境中，它们彼此清晰地了解对方，并且可以互相访问，而环境之外的东西，对于它们来说是未知的（图1-2）。那么客户端又是什么呢？它是与另一个独立的进程相互通信的程序，后者通常运行在服务器上。一般来说，服务器总是要比客户端大一些，能力强一些，配置更好一些，因为在服务器上通常要存储浩如烟海的信息。客户端程序使得最终用户可以查看和修改这些信息，当多个客户端连接在同一个服务器上的时候，可以在它们之间共享这些信息。 这个桌面电子表格应用展现了用户交互的众多可能性。被选中单元格的行列标题都是突出显示的；按钮在鼠标移上去的时候会显示提示信息；工具栏上排列着各种丰富的控件；单元格也可以交互地查看和编辑一个独立的桌面应用的架构示意图。应用运行在它自己的独立进程之中，数据模型和程序逻辑能够彼此“看到”对方的存在。除了通过文件系统之外，同一个应用的第二个运行实例[3]没有办法访问到第一个运行实例的数据模型。通常来说，整个程序的状态都保存在单个文件中，当应用运行的时候，这个文件会被加锁以阻止其他的进程同时访问
客户/服务器系统和n层架构的示意图。服务器提供了共享的数据模型，客户端与该数据模型交互。客户端同时还维护数据模型的一部分，以获得快速的访问，但是它将服务器端的模型当作业务领域对象的最终表示。多个客户端可以与同一个服务器交互，当然，这需要有合适的资源锁定机制和合理的对象（或者数据行）隔离措施作为保证。服务器可以是单进程的，就像在20世纪90年代早期和中期传统的客户/服务器模型中一样，也可以是由很多个中间件层或者多个Web服务等组成。在任何一种情况下，从客户端的角度来看，服务器都有一个单独的接入点，可以看作是一个黑盒
在现代的n层架构中，服务器往往要和更远的后端服务器（例如数据库）通信，因此被称作“中间件”的层同时扮演着客户端和服务器的角色。我们的Ajax应用位于这个链的一端，它仅仅是作为客户端，因此为讨论方便，我们可以把整个n层系统看作是一个标记为“服务器”的黑盒。
我的电子表格应用只需要管理它自己保存在内存或本地文件系统中的少量数据。如果架构设计良好的话，数据和它的表现形式的耦合可以非常松散，但是我不能通过网络来分割或者通过网络来共享它们。从这个意义上来说，电子表格应用不是一个客户端。
与之相对应的Web浏览器就是一个典型的客户端，它与Web服务器通信，请求需要的页面。浏览器有丰富的功能，用来管理用户的浏览行为，常见功能有回退按钮、历史列表和分页浏览多个文档等等。但是当我们把特定网站的Web页面看作是一个应用时，这些通用的浏览功能实际上和应用关系不大，充其量也就如电子表格和Windows的开始按钮或者窗口列表之间的关系。
我们来考察一下现代的Web应用。为了简单起见，我们选择了“地球人都知道”的在线书店Amazon.com（图1-4）。在浏览器中打开Amazon网站，因为在此之前我访问过，它会给我显示一个友好的问候、一些推荐书目，还有我的购买历史信息。
点击推荐书目中的任何一条，就会转到另外一个页面（此时，页面要刷新一下，在这几秒钟内我什么也看不到）。新页面是该书的相关信息：书评、二手书报价、同一作者的其他著作，以及以前我浏览过的其他书籍（图1-5）。
图1-4 Amazon.com的首页。系统记得我上一次的访问。导航链接除了通用模板文件，还有个性化信息
图1-5 Amazon.com书籍详细信息的页面。包括一大堆通用信息和个性化信息的超链接。虽说其中的大量内容和图1-4中的一模一样，但是由于Web浏览器使用基于文档的操作，每次发送新页面都必须要重新发送这些内容
简而言之，呈现在我面前的是非常丰富的、关联度很高的信息。但是对我而言，交互的方式就是点击那些超链接，然后填写一些表格。假设我在键盘前面不小心睡着了，第二天才醒来，如果不刷新页面，我就没法知道《哈里·波特》系列的新书已经出版了，也不能将我的列表从一个页面带到另一个页面，我要是想同时看到更多一些东西也不行，因为我无法改变页面上局部内容区域的大小。
我似乎是在批评Amazon的界面，其实并非如此，我只是拿它来做个例子。事实上，在传统Web开发方式的桎梏下，他们已经做得非常棒了。但是比起电子表格来说，它所用的交互模型毫无疑问是太有限了。
为何现代的Web应用仍然有这么多的局限呢？造成目前的状况有一些合理的技术原因，我们现在就来考察一下。
1.1.2 网络延迟
因特网的宏伟蓝图是将这个世界上所有的计算机都连接起来，形成一个无比巨大的计算资源。如果能把本地调用和远程调用等同起来，那么无论是分析蛋白质的成分还是破解外太空的信号，使用者都无需考虑机器的物理位置，剩下来的只有愉快地计算。
但是非常不幸，本地调用和远程调用是完全不同的东西。在现有的技术水平之下，网络通信仍然是一件代价高昂的事情（也就是说，通常很慢，而且并不可靠）。在没有网络调用的情况中，不同的方法和函数以及它们所操作的数据都位于相同的本地内存中（图1-6），向方法内传递数据并且获得方法的返回结果是非常直接的。
图1-6 本地过程调用的顺序图。参与者很少，因为程序逻辑与数
据模型都保存在本地内存中，并且彼此可以直接访问
而在有远程调用的情况下，位于网络两端的通信双方为了发送和接收数据在底层需要进行大量计算（图1-7）。比起数据在线路上的往返，这些计算需要消耗更多的时间。传输一段二进制的数据，中间要经过很多环节的编码和解码、错误校验、失败重发、数据包拆分和重组，数据最终转化为0和1表示的二进制信号，通过线路（或者无线连接）到达另外一方。
在本地，调用函数的调用请求被编码为一个对象，然后将这个对象序列化为一系列字节，最后使用应用层协议（通常是HTTP）通过物理传输介质（例如铜缆、光纤或者无线电波）将其发送出去。
在远程机器上，对应用层协议解码，将获得的数据字节反序列化，创建一个请求对象的副本。然后对数据模型应用这个对象并生成一个响应对象。为了将响应对象传递给本地的调用函数，所有的序列化、反序列化以及传输层的操作都要反向再来一次。最后，响应对象被传递给本地的调用函数。
图1-7 远程过程调用的顺序图。一台机器的程序逻辑尝试操作另外一台机器上的数据模型
这个交互过程很复杂吧，幸好，它是可以自动完成的。现代的编程环境如Java和Microsoft的.NET框架都内置了这个能力。尽管如此，执行远程调用时，上述所有这些操作仍然会在内部执行。如果我们到处使用远程调用，性能势必会大受影响。
这也就是说，远程调用是不可能和本地调用一样有效率的。更糟糕的是，网络的不稳定更让这种效率损失捉摸不定，难以预计。相比之下，运行在本地内存之中的本地调用，在这一点上无疑要有优势得多。
等等，说了半天的远程调用，这和软件的可用性有关系吗？答案是，大有关系。
一个成功的计算机用户界面要能以最起码的水平模拟我们在真实世界中的体验。交互的基本规则之一就是，当我们推一下、刺一下或者捅一下某个东西的时候，它立刻就会响应。响应的时间只要稍微拖长一点点，就会使人困惑，分散其注意力，把关注点从手头的任务转移到用户界面上。
远程调用横穿整个网络，需要执行大量的额外操作，它们往往会把系统拖慢，使用户察觉到延迟。在桌面应用中，只有当可用性设计做得非常糟糕的时候，才会出现这种令用户感觉充满bug、反应迟钝的用户界面，但在网络应用中，什么都不做就能得到大量这样的界面。
因为网络延迟不可预测，这类界面问题往往都神出鬼没，对应用响应的测试也难以开展。换句话说，网络延迟是导致实际应用的交互性糟糕的一个普遍原因。
1.1.3 异步交互
用户界面的开发者对于网络延迟只能做最坏的假设。简单地说，就是要尽可能让用户界面与网络活动无关。天才的程序员们早已发明了一种确实有效而且久经考验的方案，来专门解决这一问题。先卖个关子，让我们到现实世界中走一趟。
在我每天早上必做的事中，很重要的一项是叫醒我的孩子去上学。我可以站在床边把他们折腾醒，催着他们起床穿衣，但这是一种很耗费时间的方法，总要耗费我很多宝贵的早间时光（图1-8）。
图1-8 在我每日早晨必做的事中，以同步方式响应用户输入的顺序图。顺序图中纵向表示时间的流逝，其中的阴影区域表示了我被阻塞不能接受其他输入的时间长度
我要叫醒孩子，看看窗外，往往会忽略了喂猫。孩子们起来之后会问我要早餐。就像服务器端的进程一样，孩子们起床总是慢吞吞的。如果我遵循同步交互模式，就要等他们老半天。不过，只要他们嘟囔一句“我醒了”，我就可以先去干其他的事，需要时再回来看看他们。
按照计算机的术语，我需要做的就是为每个孩子在一个单独的线程中建立一个异步进程。开始之后，孩子们会在他们的线程里自己起床，我这个父线程没有必要同步傻等，他们完事后会通知我（往往还会问我要吃的）。在他们醒来的过程中，我并不需要和他们交互，就当他们已经起来并自己穿好衣服了，因为我有理由相信他们很快会这么做的（图1-9）。
对于任何用户界面来说，这是一种沿用已久的实践，即创建异步的线程，让它在后台处理那些需要计算很久的任务，这样用户可以继续做其他的事情。当启动这个线程的时候，有必要阻塞用户的操作[4]，但是在可接受的很短时间之后，阻塞就会解除。因为存在网络延迟，使用异步方式来处理任何耗时的远程调用是一种很好的实践。
图1-9 以异步方式响应用户输入的顺序图。如果遵循异步的输入模式，我可以让孩子们在醒来的时候通知我。在他们缓慢的起床过程中，我可以继续从事其他活动，这使得我被阻塞的时间大大缩短
实际上，网络延迟问题和相关的解决方案由来已久。在老的客户/服务器模式中，当设计不佳的客户端程序碰上了高负载的服务器时，用户界面就会出现让人难以忍受的延迟。即便是在如今的因特网时代，当切换页面时，如果浏览器半天出不来东西，那么这种糟糕的情况很可能就是因为网络延迟造成的。在现有技术条件下，我们暂时还没有办法消除网络延迟，但是至少有一个对策，那就是采用异步方式处理远程调用，不是吗？
糟糕的是，对于Web开发人员而言这样做存在一个难点：HTTP协议是一个“请求—响应”模式的协议。也就是说，客户端请求一个文档，服务器要么返回这个文档，要么告诉客户端找不着文档或者让客户端去另外一个地方找，还可以告诉客户端可以使用它的本地缓存，诸如此类。总而言之，“请求—响应”模式的协议是一种单向的通信协议。客户端可以向服务器发起连接，但是服务器不可以向客户端发起连接。甚至，当客户端下次发起通信请求时，健忘的服务器都记不起来这个客户端是谁了（HTTP是无连接的）。
多数Web开发者使用现代的编程语言，例如，Java、PHP或者.NET，他们熟悉用户会话（user session）的概念，这其实是应用服务器对于不能保持连接状态的HTTP协议的一种补救措施。HTTP就其最初的设计目的来说表现得非常好，采用一些巧妙的处理，它能够适应设计之初没有考虑的场合。但是我们的这个异步回调方案中的关键特征是，客户端会收到两次通知，一次是在线程创建的时候，另一次是在线程结束的时候。标准的HTTP和传统Web应用模型可不会提供这些。
像Amazon那样的传统Web应用，是建造在页面概念之上的。给用户显示一个文档，上面包括各种链接和表单，用户可进一步访问更多的文档。这种交互模式可以在很大的规模上支持复杂的数据集（就像Amazon和其他网站已经证明的那样），它所提供的用户体验也足以满足开展业务的需要。
十年来，这种交互模式在我们对因特网商业应用的看法上打下了深深的烙印。界面友好的所见即所得（WYSIWYG）Web制作工具使得站点更容易被理解为一堆页面。服务器端的Web框架使用状态图来对页面的转换建模。没有引入，传统的Web应用就这么一直牢牢地束缚在页面刷新操作之上，就好像这种刷新是理所当然而且无可避免的，从没有尝试过任何异步的处理方案。
当然，毫无疑问，传统的Web应用肯定不是一无是处的。毕竟Amazon在这种交互模式上创造了成功的商业应用。但是这种适用于Amazon的方式并不一定适用于所有的人。为什么这么说呢？要理解这一点，我们需要考察用户的使用模式（usage pattern）。
1.1.4 独占或瞬态的使用模式
泛泛地讨论自行车和SUV（运动型轿车）孰优孰劣毫无意义。因为它们各自都有优点和缺点——舒适度、速度、油耗或者个人身份的象征等等。只有在特定的使用模式下讨论，这样的比较才有意义。例如，是要在上下班高峰时段穿越市中心，还是要带上一家老小去度假，或者只是要找个躲雨的地方。在类似这样的具体情况下，我们才能有的放矢地比较。对于用户界面，亦复如是。
软件可用性专家Alan Cooper写了很多有关使用模式的好文章，他定义了两种主要的使用方式：瞬态的（transient）和独占的（sovereign）[5]。瞬态应用可能每天都会偶尔使用一下，但是总是作为次要的活动，突发性地用上一会儿。与之形成鲜明对比的是独占应用，独占应用需要应付用户每天几个小时的持续使用。
很多应用天生就具备独占或者瞬态的性质。例如，写作用的字处理软件就是一个独占应用，可能还会用到几个瞬态的应用，比如文件管理（文件的开启和关闭窗口中常常会嵌入这个功能）、字典或者拼写检查工具（很多字处理程序也嵌入这些功能），还有与同事联络的电子邮件和聊天工具。而对于软件开发者，文本编辑器、调试器或者IDE（集成开发环境）则是独占的。
独占应用常常使用得更频繁。要知道，一个良好的用户界面应该是不可见的。衡量使用频繁程度的一个好的标尺，是当这个用户界面发生明显的停顿时，它对于用户流程的影响。例如，从一个目录向另一个目录移动文件要发生2秒钟的停顿，我能愉快地接受；可是如果这两秒是发生在我正饱含激情地用绘画软件创作一幅作品时，或者是我正努力地调试一段很难对付的代码时，这肯定会让我感觉十分不爽。
Amazon是一个瞬态应用，eBay、Google以及大多数大型的公众Web应用都是瞬态应用。自因特网诞生之日起，专家们就曾经预测传统的桌面应用面临Web应用的冲击。十年过去了，这些都还没有发生，为什么呢？基于Web页面的方案对于瞬态应用是足够了，但是对于独占应用却还远远不够。
1.1.5 忘掉Web
现代Web浏览器和它最原始的出发点（从远程服务器上获得一个文档）相比已经完全不是一码事了，它们之间就像是瑞士军刀和新石器时代的狩猎工具一样，可谓是天壤之别。各种交互组件、脚本语言和插件，这些年来无法抑制地疯狂发展，近乎强制地一次又一次地创造着新的浏览体验。[可以到www.webhistory.org/www.lists/wwwtalk.1993q1/0182.html瞻仰一下浏览器的史前时代。1993年的时候，Netscape创立之前的Marc Andreessen（Netscape的创始人）还在游说Tim Berners-Lee（Web的创始人，W3C的领导者）等人，列举为HTML引入一个图片标签的好处]。
几年以前，一些先行者就已经开始把JavaScript当作一种严肃的编程语言来对待。但就整体而言，更多的人仍然把它和那些假模假样的警告框以及“点击猴子赢大奖”的广告一类的小把戏联系在一起。
浏览器大战导致JavaScript成了个被误解的、病态的孩子，Ajax可以看作是他的康复中心[6]。只要适当引导，然后给它配上合适的框架，JavaScript就很有可能变成因特网的模范公民。它能真正增强Web应用的实用性，而且不强迫用户安装额外的软件，或者逼迫用户抛弃自己心爱的浏览器。得到广泛理解的成熟的工具可以帮助我们达成这一目标。本书后面会大量提到的设计模式就是这样一类工具。
推广和普及一项新技术，既是技术事务，也是社会行为。一旦技术已经成熟，人们还需要领会应该如何去使用它。这一步骤常常是通过用它来做我们很熟悉的事情开始的。比如，早年的自行车叫做“木马轮”或者“蹬行马”，靠脚使劲蹬地的反作用力来前进。随着这一技术渐渐为大众所接受，后来的发明者们会发明出这一技术新的使用方式，给它加上踏板、刹车、链条齿轮以及充气轮胎。每一次的发明创造，都使得自行车中马的影子越来越淡，以至于彻底消失（图1-10）。
相同的过程也发生在如今的Web开发领域。Ajax背后的技术有能力将Web页面转换成某种完全不同的新东西。早期Ajax的使用尝试使得Web页面开始变得像“木马轮”一样不伦不类。要领悟Ajax的精髓，我们就要忘掉Web的页面概念，也就是说，我们要打破这些年来所形成的经验。就在Ajax正式命名后的这几个月，这样的事已经发生了不少。
1.2 Ajax的四个基本原则
我们用到的很多框架中都已经固化了基于页面的传统应用模式，同时这些应用模式也已经深深进入了我们的思想中。我们花几分钟来揭示出哪些核心概念是我们需要重新思考的，以及如何从Ajax的角度来重新思考。
1.2.1 浏览器中的是应用而不是内容
在传统的基于页面的Web应用中，浏览器扮演着哑终端[7]的角色。它对用户处于操作流程哪一阶段一无所知。这些信息全部都保存在服务器上，确切地说，就是在用户会话上。时至今日，服务器端的用户会话早已是司空见惯。如果你使用Java或者.NET编程，服务器端的用户会话更是标准API的一部分——还有Request、Response、MIME类型——没有了它们简直不可想象。图1-11描绘了传统Web应用典型的生命周期。
当用户登录或者以其他方式初始化一个会话时，系统会创建几个服务器端的对象。例如，电子商务类型的网站需要创建表示购物车以及用户身份证明的对象。同时将浏览器站点的首页呈现给用户，这个HTML标记的数据流由模板文件以及特定于该用户的数据和内容（例如该用户最近浏览的商品列表）组成。
用户每次和服务器交互，都会获得另一个文档。在这个文档中，除了特定于该用户的数据以外，包含的其他模板文件和数据都是相同的。浏览器总是忠实地丢弃掉老的文档，显示新的文档，因为它是哑终端，而且也不知道还可以做些什么。
当用户选择退出或者关闭浏览器的时候，应用退出，会话消失。这个时候持久层会把用户下次登录后需要显示的信息存储起来。Ajax则不同，它把一部分应用逻辑从服务器端移到了浏览器端。
用户登录的时候，服务器交付给浏览器一个复杂得多的文档，其中包含大量的JavaScript代码。这个文档将会在整个会话的生命周期内与用户相伴。在这一过程中，随着用户与其交互，它的外观可能会发生相当大的变化。它知道如何响应用户的输入，能够决定对于这些请求，是自行处理还是传递给Web服务器（Web服务器再去访问数据库或者其他资源），或者通过两者结合的方式进行处理。
因为这个文档在整个用户会话中都存在，所以它可以保存状态。
1.2.2 服务器交付的是数据而不是内容
我们已经提到，在传统的Web应用中，服务器在每个步骤都需要把模板文件、内容和数据混合发送给浏览器。但实际上，当向购物车中添加一件物品的时候，服务器真正需要响应的仅仅是更新一下购物车中的价格。如图1-13所示，这只是整个文档中极小的一小部分。
基于Ajax的购物车可以向服务器发起一个异步请求来完成这件事，这样做显得更聪明。模板文件、导航列表和页面布局上的其他部分已经随着初始页面发送给了浏览器，服务器无需重发，以后每次只需要发送相关的数据就可以了。
Ajax应用可以通过多种方式来做这件事情。例如，返回一段JavaScript代码、一段纯文本或者一小段XML文档。这些方式各自的优缺点，我们将留到第5章再详细考察。但是，毫无疑问的是，无论返回数据采用何种格式，这些方式所传输的数据量都要比传统的Web应用中一股脑返回一个大杂烩的方式少得多。
在Ajax应用中，网络的通信流量主要是集中在加载的前期，无论如何，用户登录后是需要一次性地将一个大而复杂的客户端交付给浏览器。但是在此之后，与服务器的通信则会有效率得多。对于瞬态应用来说，积累起来的通信流量要比以前的基于页面的Web应用少很多。与此同时，平均的交互次数则有所增加。整体而言，Ajax应用的带宽消耗要比传统的Web应用低一些。
1.2.3 用户交互变得流畅而连续
浏览器提供了两种输入机制：超链接和HTML表单。
超链接可以在服务器上创建，并预加载指向动态服务器页面或者servlet的CGI参数。可以用图片或者CSS（层叠样式表）来装饰超链接，并且当鼠标停在上面时还可以提供基本的反馈。经过合理设计，超链接可以变成一个很有想像力的UI组件。
表单则提供了桌面应用的一组基础UI组件：输入文本框、单选按钮和多选按钮，还有下拉列表。但仍然缺少很多有用的UI组件，例如，没有可用的树控件、可编辑的栅格、组合输入框等。表单像超链接一样，也指向服务器的一个URL地址。
超链接和表单也可以指向JavaScript函数。这一技术通常用在将数据提交给服务器之前对表单输入进行简单的校验，如检验是否有空值，数值是否越界等等。这些JavaScript函数的生存期和页面本身是一致的，当页面提交之后，这些函数也就不存在了。
当一个页面已提交而下一个页面还没有显示出来的时候，用户实际上处于没人管的状态。老的页面还要显示一会儿，浏览器甚至还会允许用户点击一些链接。但这些点击可能会导致一些不可预料的结果，甚至破坏服务器端会话的状态。用户通常应该等到页面刷新完成，当然也可以选择在刷新完成之前就在新页面上做一些操作。例如，当页面只显示了一部分时从中选择一条裤子放进购物车不大可能会造成什么破坏（例如，不会修改顶级的服装分类：男装、女装、童装、配饰）。
我们继续看这个购物车的例子。Ajax的购物车是通过异步方式发送数据的，用户可以很快地把东西拖进来，就像点击一样快。只要客户端购物车的代码足够健壮，它可以很轻松地处理这样的负载，而用户则可以继续做他想做的事。
要知道，在服务器端并没有一个真正的购物车等着装东西，只有会话中的一个对象而已。购物的时候，用户并不想知道会话对象，购物车对于用户而言是一个较恰当的比喻，用现实世界中熟悉的概念来描述这里发生的事情。对于用户来说，如果强迫他们去理解计算机领域中的术语，只会让他们远离网站。等待页面的刷新，一下子就把用户从愉快的使用体验中拽了出来，让他感觉到自己所面对的只不过是一台冰冷的机器罢了（图1-14）。使用Ajax来实现这些应用则可以避免这些令人不快的体验。当然了，在这个例子中的购物只是一个瞬态活动。考察一下其他的业务领域，例如，一个业务量很大的帮助中心或者一项复杂的工程任务，如果因为需要等待页面刷新而将工作流程打断几秒钟，那肯定是不可接受的。
Ajax的另一个好处是，我们可以对丰富的用户操作事件进行捕获。类似于拖拽这样的复杂UI概念也不再是遥不可及的。这使得Web应用的UI体验可以全面提升到近乎与桌面应用的UI组件相媲美的高度。从可用性的角度来看，这很重要，不仅仅是因为它释放了我们的想象力，而且也是因为它可以将用户交互和服务器端的请求更加充分地混合起来。
在传统的Web应用中，与服务器交互需要点击超链接或者提交表单，然后等待页面的刷新，这打断了用户的工作流程。与之相对应的是，让服务器响应鼠标移动、拖拽或者键盘输入这样的用户事件，也就是说，服务器在用户身边为用户服务，而不是挡在用户前面，打断他的操作。Google Suggest（www.google.com/webhp?complete=1）就是这样一个简单的但是很有说服力的例子。当用户在搜索框键入一些字符的时候，应用从服务器取回与用户已键入字符串相似的搜索条目（根据全世界其他人的搜索），并且显示在输入框下方的下拉列表中。第8章将提供这类服务的一个简单实现。
1.2.4 有纪律的严肃编程
现在传统的Web应用有时候也会用到JavaScript，不过主要是用来给页面添加一些花哨的东西。基于页面的模型使得这样的增强没有办法更进一步，限制了用户可以得到的更加理想的交互。这种类似于第22条军规的状况，使得JavaScript很不公平地获得了一种琐碎的、自由散漫的编程语言的名声，为那些严肃的开发者[10]所不屑。
为Ajax应用编程的情况则完全不同。提交给用户运行的应用将会一直运行直到用户关闭程序为止。不崩溃，不变慢，也没有内存泄漏之类的毛病。如果我们的产品定位于独占式应用的市场，这还意味着很多小时的密集使用。要达到这个目标，当然需要高性能的、可维护的代码，这与服务器端应用的要求是一致的。
相比之下，Ajax的代码库会比传统的Web应用大很多。对代码库进行良好的组织是非常重要的。编写代码不再是单个开发者的职责，而是整个团队来参与。可维护性、分离关注点、共同的编程风格以及设计模式，这些都是需要考虑的问题。
浙公网安备 33010602011771号