ajax|web|程序这并不是在诋毁Amazon，在非常有限的限定内它工作得相当优秀。但是与工作表相比，它所依赖的交互模型毫无疑问相当有限。
那么，为什么在现代web应用程序中存在这么多的限制呢？目前，存在很多技术上的原因。因此，现在让我们作进一步分析。
三、网络的潜力
互联网时代的伟大就在于世界各地所有的计算机互相联系，就象在一个非常大的计算资源之中。远程和本地过程调用变得很难区分，并且发行者已经不再清醒地了解它们在哪些物理机器上工作。
不幸的是，远程和本地过程调用是根本不相同的技术。
在网络上的通讯是昂贵的(它们是慢并且不可靠的)。当一部分非网络代码被编译或解释时，各种方法和函数就象在其上操作的数据一样被编码为存储在相同的本地内存中的指令(图6)。这样，把数据传递给一个方法并返回结果就相当直接。
 图6 本地过程调用序列图-在此很少的元素如程序逻辑和数据模型都被存储在本地内存并能彼此直接看见。 |
其实在底层，为了发送和接收数据，很多计算运行于一个网络连接的两端(图7)。实际上，这种计算远不如沿着物理线路的运行更导致系统的减慢-各级的编码与解码遍及通讯的各个方面，从沿着线路传输的物理信息，把这些信息翻译为二进制的1和0，错误检查和重发送，到重新整合该二进制序列。
 图7 一个远程过程调用序列图。在一台机器上的程序逻辑试图操作在另外一台机器上的数据模型。 |
调用函数的请求必须被编码为一个稍后将被串行化的对象（也即，被转换成一个线性字节集合）。然后，被串行化的数据被传递到应用程序协议（现在通常为HTTP）并且通过物理传输发送。
在远程机器上，该应用程序协议被解码，并且数据的字节被反串行化以创建该请求对象的一个副本。然后，这个对象被应用到数据模型和一个生成的响应对象上。为了联系该响应和调用函数，该串行化和传输层必须被再一次导航，最后导致一个响应对象被返回到调用函数。
这些客户端是复杂的但是适合于自动化实现。现代的编程环境例如Java和微软.NET框架都提供了这种功能的自由使用。尽管如此，当产生一个远程过程调用(RPC)时，在内部有大量的活动在进行并且如果这样的调用太自由的话，性能也会受到影响。
因此，通过网络的调用永远不会象调用本地内存中的一个方法那么富有效率。而且，网络的不可靠性（并因此需要重新发送失去的信息包)也使得这种低效在不断变化且很难预测。在你的本地机器上的内存响应性不仅更好一些而且相比之下可以被很好地定义。
这但与可用性有什么关系呢？已证明，其关系相当大。
一个成功的计算机UI的确需要模仿我们真实的世界期望。该交互的最基本原则之一是，当我们点按某东西时，它能够立即响应。在点按和响应之间的轻微的延迟都会带给用户迷惑并使之分神-把用户的注意力从手头的任务转移到UI本身。
必须做所有的额外工作来穿越网络常常就足已减慢一个系统，以至于该延迟变得相当引人注意。在一桌面应用程序中，我们需要做出糟糕的可用性设计决策来使得应用程序感觉起来充满错误或不具有响应性，但是在一个联网应用程序中，不需要我们关心这些！
