ajax|web|程式 這並不是在詆毀Amazon，在非常有限的限定內它工作得相當優秀。但是與工作表相比，它所依賴的互動模型毫無疑問相當有限。
那麼，為什麼在現代web應用程式中存在這麼多的限制呢？目前，存在很多技術上的原因。因此，現在讓我們作進一步分析。
三、網路的潛力
互連網時代的偉大就在於世界各地所有的電腦互相聯絡，就象在一個非常大的計算資源之中。遠程和本地程序呼叫變得很難區分，並且發行者已經不再清醒地瞭解它們在哪些物理機器上工作。
不幸的是，遠程和本地程序呼叫是根本不相同的技術。
在網路上的通訊是昂貴的(它們是慢並且不可靠的)。當一部分非網路代碼被編譯或解釋時，各種方法和函數就象在其上操作的資料一樣被編碼為儲存在相同的本地記憶體中的指令(圖6)。這樣，把資料傳遞給一個方法並返回結果就相當直接。
圖6 本地程序呼叫順序圖表-在此很少的元素如程式邏輯和資料模型都被儲存在本地記憶體並能彼此直接看見。 |
其實在底層，為了發送和接收資料，很多計算運行於一個網路連接的兩端(圖7)。實際上，這種計算遠不如沿著物理線路的運行更導致系統的減慢-各級的編碼與解碼遍及通訊的各個方面，從沿著線路傳輸的物理資訊，把這些資訊翻譯為二進位的1和0，錯誤檢查和重發送，到重新整合該二進位序列。
圖7 一個遠端程序呼叫順序圖表。在一台機器上的程式邏輯試圖操作在另外一台機器上的資料模型。 |
調用函數的請求必須被編碼為一個稍後將被序列化的對象（也即，被轉換成一個線性位元組集合）。然後，被序列化的資料被傳遞到應用程式協議（現在通常為HTTP）並且通過物理傳輸發送。
在遠程機器上，該應用程式協議被解碼，並且資料的位元組被反序列化以建立該請求對象的一個副本。然後，這個對象被應用到資料模型和一個產生的響應對象上。為了聯絡該響應和調用函數，該序列化和傳輸層必須被再一次導航，最後導致一個響應對象被返回到調用函數。
這些用戶端是複雜的但是適合於自動化實現。現代的編程環境例如Java和微軟.NET架構都提供了這種功能的自由使用。儘管如此，當產生一個遠端程序呼叫(RPC)時，在內部有大量的活動在進行並且如果這樣的調用太自由的話，效能也會受到影響。
因此，通過網路的調用永遠不會象調用本地記憶體中的一個方法那麼富有效率。而且，網路的不可靠性（並因此需要重新發送失去的資訊包)也使得這種低效在不斷變化且很難預測。在你的本地機器上的記憶體響應性不僅更好一些而且相比之下可以被很好地定義。
這但與可用性有什麼關係呢？已證明，其關係相當大。
一個成功的電腦UI的確需要模仿我們真實的世界期望。該互動的最基本原則之一是，當我們點按某東西時，它能夠立即響應。在點按和響應之間的輕微的延遲都會帶給使用者迷惑並使之分神-把使用者的注意力從手頭的任務轉移到UI本身。
必須做所有的額外工作來穿越網路常常就足已減慢一個系統，以至於該延遲變得相當引人注意。在一傳統型應用程式中，我們需要做出糟糕的可用性設計決策來使得應用程式感覺起來充滿錯誤或不具有響應性，但是在一個連網應用程式中，不需要我們關心這些！
- Ajax: 一個建立Web應用的新途徑
- Ajax的錯誤處理機制探討(2)
- Ajax的錯誤處理機制探討(1)
- 初次體驗.NET Ajax無重新整理技術
- Rails系統中的AJAX開發技術簡析(4)
