DIV CSS 佈局教程網

這並不是在诋毀Amazon，在非常有限的限定內它工作得相當優秀。但是與工作表相比，它所依賴的交互模型毫無疑問相當有限。

　　那麼，為什麼在現代web應用程序中存在這麼多的限制呢？目前，存在很多技術上的原因。因此，現在讓我們作進一步分析。
三、網絡的潛力

　　互聯網時代的偉大就在於世界各地所有的計算機互相聯系，就象在一個非常大的計算資源之中。遠程和本地過程調用變得很難區分，並且發行者已經不再清醒地了解它們在哪些物理機器上工作。 

　　不幸的是，遠程和本地過程調用是根本不相同的技術。

　　在網絡上的通訊是昂貴的(它們是慢並且不可靠的)。當一部分非網絡代碼被編譯或解釋時，各種方法和函數就象在其上操作的數據一樣被編碼為存儲在相同的本地內存中的指令(圖6)。這樣，把數據傳遞給一個方法並返回結果就相當直接。


圖6 本地過程調用序列圖-在此很少的元素如程序邏輯和數據模型都被存儲在本地內存並能彼此直接看見。
　　其實在底層，為了發送和接收數據，很多計算運行於一個網絡連接的兩端(圖7)。實際上，這種計算遠不如沿著物理線路的運行更導致系統的減慢-各級的編碼與解碼遍及通訊的各個方面，從沿著線路傳輸的物理信息，把這些信息翻譯為二進制的1和0，錯誤檢查和重發送，到重新整合該二進制序列。


圖7 一個遠程過程調用序列圖。在一台機器上的程序邏輯試圖操作在另外一台機器上的數據模型。
　　調用函數的請求必須被編碼為一個稍後將被串行化的對象（也即，被轉換成一個線性字節集合）。然後，被串行化的數據被傳遞到應用程序協議（現在通常為HTTP）並且通過物理傳輸發送。

　　在遠程機器上，該應用程序協議被解碼，並且數據的字節被反串行化以創建該請求對象的一個副本。然後，這個對象被應用到數據模型和一個生成的響應對象上。為了聯系該響應和調用函數，該串行化和傳輸層必須被再一次導航，最後導致一個響應對象被返回到調用函數。 

　　這些客戶端是復雜的但是適合於自動化實現。現代的編程環境例如Java和微軟.Net框架都提供了這種功能的自由使用。盡管如此，當產生一個遠程過程調用(RPC)時，在內部有大量的活動在進行並且如果這樣的調用太自由的話，性能也會受到影響。

　　因此，通過網絡的調用永遠不會象調用本地內存中的一個方法那麼富有效率。而且，網絡的不可靠性（並因此需要重新發送失去的信息包)也使得這種低效在不斷變化且很難預測。在你的本地機器上的內存響應性不僅更好一些而且相比之下可以被很好地定義。

　　這但與可用性有什麼關系呢？已證明，其關系相當大。

　　一個成功的計算機UI的確需要模仿我們真實的世界期望。該交互的最基本原則之一是，當我們點按某東西時，它能夠立即響應。在點按和響應之間的輕微的延遲都會帶給用戶迷惑並使之分神-把用戶的注意力從手頭的任務轉移到UI本身。

　　必須做所有的額外工作來穿越網絡常常就足已減慢一個系統，以至於該延遲變得相當引人注意。在一桌面應用程序中，我們需要做出糟糕的可用性設計決策來使得應用程序感覺起來充滿錯誤或不具有響應性，但是在一個聯網應用程序中，不需要我們關心這些！