1.1.3异步交互（ajax in action）

     对于界面设计师们来说，对付网络延时问题的唯一明智方法就是——作最坏的打算。在实际的项目中，我们必须使得ui做出反应而不受网络的影响。幸运的是，只要反映及时，这个拘束的response还是可以的。让我们来插曲：我每天早上的例行工作就是叫醒我的孩子上学校。我监督他们直到他们离开床。但这是一个费时的事情，我很少这样做。

 

我要叫醒孩子,望着窗外,也不理睬猫. 孩子会注意到当他们完全醒来的时候,会要求他们吃早餐. 如同计算机程序,叫醒儿童是延迟的. 如果我走了同步互动的模式,我将花很长的时间等待. 只要他们嘀咕"我已经醒了:"我可以快乐的干别的事情,如果他们需要我还要看他们是否迟到.
在计算机中，我将会在这里产生一个异步线程在单独的进程中。一开始,孩子们依靠自己的进程醒了,父母进程,也不需要配合他们,直到他们通知我. 希望如果他们已经睡醒了,我就不需要去管他们,我确信某一天会是这样。
有许多UI，它是一个行之有效的方法，一个异步线程，对于一个过长的进程句柄，让他作为一个背景进程在后台运行，一直到用户收到一些东西。在很短的过程里这个过程是可以接受的。

因为网络是延迟的，它是一个好的办法,相对于一些延迟更长时间的RPC来说它是异步的。
这个问题或者这个方案已经很好的制定。网络的延迟出现在老式的c/s模式中，使得瘦客户端被冻结，而因出了过载的服务器。而在网络时代，当我们访问网页的时候，你的浏览器会慢慢悠悠的载入。我们无法对付延迟，但是我们用远程异步可以解决他们，对吧？
对于不幸运的web开发人员，他们会发现这些。http协议是一个request_response协议。也就是说，客户端发出一个请求文档，服务器做出反应，或者发出一个文档说网页找不到，或者告诉客户，网页正在缓存中。http是一个单方向的协议。客户端可以联接服务器，服务器是不能让客户端启动的，并且不知道也不记得是谁发出的访问。
大多数的开发者不管是java or .net都知道一个概念就是用户session,有一个想法就是http协议缺少一个服务器状态协议。http协议最初设计是非常好的，他已经充分的考虑了扩展的需要。然而，无论怎样，我门的异步调用解决方案是客户端获得两次通知：当线程产生和完成的时候。直接的http和杰出的应用模式无法为我们解决这问题。
杰出的模式，例如亚马逊，他仍然建立在页面的观念上。一个文档展示给客户，链接和列表可以把客户导向到更远的地方。大量的数据互相影响，亚马逊和其他一些模式已经证明了一点，构架这样一个商业行为感受到太多的限制了。
但是 ，亚马逊已经构建了也成功的模式，难道我们能说它没用吗？要知道，他并不是对说有的用户，所以我们应该理解这种模式。