iNeo

拋開這些不管，Web設計者們對設計交互式的Web沒有什么更好的辦法，卻對我們做桌面軟件的同事投去少許羨慕的目光.桌面應用程序有豐富的界面以及對于Web程序來說無法比擬的響應能力。同樣，Web的快速發展，在我們所提供的體驗和用戶從桌面應用程序所得到的體驗間產生巨大的差距

而如今差距正在消失。請看看“Google建議(Google Suggest)”. 觀察它按你的輸入顯示建議條目的更新速度，幾乎是立即更新的。再看看"Google Maps". 放大，用你的鼠標搬動和滾動。這些動作幾乎是立即響應的，不用等待頁面刷新。

"Google Suggest"和"Google Maps" 是采用Ajax技術的兩個典型例子。Ajax是Asynchronous JavaScript and XML的簡稱，它表現出一個Web開發上的根本轉變，那就是，Web上可能做些什么. Ajax的定義

Ajax不是一個技術，它實際上是幾種技術，每種技術都有其獨特這處，合在一起就成了一個功能強大的新技術。Ajax包括：

• XHTML和CSS
• 使用文檔對象模型(Document Object Model)作動態顯示和交互
• 使用XML和XSLT做數據交互和操作
• 使用XMLHttpRequest進行異步數據接收
• 使用JavaScript將它們綁定在一起

傳統的web應用模型工作起來就象這樣：大部分界面上的用戶動作觸發一個連接到Web服務器的HTTP請求。服務器完成一些處理---接收數據，處理計算，再訪問其它的數據庫系統，最后返回一個HTML頁面到客戶端。這是一個老套的模式，自采用超文本作為web使用以來，一直都這樣用, 但看過《The Elements of User Experience》的讀者一定知道，是什么限制了Web界面沒有桌面軟件那么好用。

圖1: 傳統Web應用模型(左)與Ajax模型的比較(右).

這種舊的途徑讓我們認識到了許多技術，但它不會產生很好的用戶體驗。當服務器正在處理自己的事情的時候，用戶在做什么？沒錯，等待。每一個動作，用戶都要等待。

很明顯，如果我們按桌面程序的思維設計Web應用，我們不愿意讓用戶總是等待。當界面加載后，為什么還要讓用戶每次再花一半的時間從服務取數據？實際上，為什么老是讓用戶看到程序去服務器取數據呢？ Ajax如何不同凡響

通過在用戶和服務器之間引入一個Ajax引擎，可以消除Web的開始－停止－開始－停止這樣的交互過程. 它就像增加了一層機制到程序中，使它響應更靈敏，而它的確做到了這一點。

不像加載一個頁面一樣，在會話的開始，瀏覽器加載了一個Ajax引擎---采用JavaScript編寫并且通常在一個隱藏frame中。這個引擎負責繪制用戶界面以及與服務器端通訊。Ajax引擎允許用異步的方式實現用戶與程序的交互－－不用等待服務器的通訊。所以用戶再不不用打開一個空白窗口，看到等待光標不斷的轉，等待服務器完成后再響應。

圖 2: 傳統Web應用的同步交互過程(上)和Ajax應用的異步交互過程的比較(下).

通常要產生一個HTTP請求的用戶動作現在通過JavaScript調用Ajax引擎來代替. 任何用戶動作的響應不再要求直接傳到服務器---例如簡單的數據校驗，內存中的數據編輯，甚至一些頁面導航---引擎自己就可以處理它. 如果引擎需要從服務器取數據來響應用戶動作---假設它提交需要處理的數據，載入另外的界面代碼，或者接收新的數據---引擎讓這些工作異步進行，通常使用XML, 不用再擔誤用戶界面的交互。 誰在使用Ajax

在采用Ajax的開發上面，Google做了巨大的投資。去年Google所有主要的產品都用了這項技術---Orkut, Gmail, 以及最近的beta版的Google Groups, Google Suggest和Google Maps---它們全是Ajax的應用。(要想了解更多這些Ajax實際的技術細節，請看它們的分析文章:Gmail, Google Suggest, Google Maps). 其它的像：Flickr, 采用許多人們喜歡的Ajax特性，還有Amazon的A9.com搜索引擎也采用類似的技術。

這些項目證明了Ajax不只是學術上的，也有許多真實世界成功應用。這不是什么實驗室里的技術。Ajax的應用可大可小，從非常簡單的，像單一功能的Google Suggest到非常復雜的Google Maps.

Ajax：Web應用開發新理念

如果要用“充滿魅力”一詞來形容當前流行的交互設計，那么首推創建Web應用程序。畢竟，當你最終聽到某人傾倒于產品的交互設計，難道不是在網上？（Okay，我承認iPod除外）。所有追求酷，追求創新的新項目都是聯機應用的。

盡管如此，Web交互設計人員還是不可避免地對創建桌面應用軟件的同事懷有一絲妒忌。桌面應用程序所擁有的功能豐富性和響應能力似乎是Web目前無法達到的。簡單地讓Web應用程序迅速蔓延，會在我們所提供的體驗和用戶從桌面應用程序獲取的體驗之間形成一道鴻溝。

但現在，這道鴻溝正被逐漸填平。讓我們看看Google Suggest。根據您輸入的內容，相關的條目便幾乎立即更新。我們再看Google Maps。利用光標，在刻度線上移動來放大地圖或者縮小，所有的一切幾乎都是即時的，完全不用等待頁面的刷新。

Google Suggest和Google Maps就是這種新型Web應用程序的兩個例子，我在Adaptive Path上把這種理念稱為 Ajax。也就是Asynchronous JavaScript + XML的簡寫，它預示著Web可能發生一次重大的變革。

Ajax的定義

Ajax并不是一種新技術，它實際上是幾種已經在各自領域大行其道的技術的強強結合。Ajax由以下內容組成：

· 基于標準化的XHTML和CSS；

通過DOM（Document Object Model）實現動態顯示和交互；
· 通過XML和XSLT來進行數據交換和處理；

使用XMLHttpRequest通過異步方式獲取數據；
使用JavaScript來整合以上所有的技術
經典的Web應用程序模型工作方式如下：大多數用戶動作在界面上激發一個HTTP請求到web服務器。服務器做一些處理——獲取數據，處理數字，與現有的應用系統進行溝通——最后返回HTML到客戶端。這樣的模型適合于以超文本為基礎的Web應用程序，但作為一個強調用戶體驗的狂熱分子（The Elements of User Experience一書的擁護者），我們認為超文本造就Web成功的東西，卻并不一定滿足軟件應用程序的要求。

傳統的Web應用程序模型技術上來說意義非凡，但它并不適用于創建完美的用戶體驗。當服務器在做數據處理的時候，用戶在干什么呢？沒錯，他們在等待。一個任務所需的步驟越多，用戶需要等待的次數也越多。

顯然，當我們設計Web應用程序的時候，我們不應該讓用戶傻等。界面一旦加載完成，為什么還要因為程序需要從服務器傳輸一些東西而中斷用戶交互呢？實際上，用戶為什么要看到程序與服務器的聯系？

為什么Ajax與眾不同

Ajax應用程序摒棄了“開—關—開—關”的交互形式，在用戶與服務器之間引入了一個中間件——Ajax引擎。看上去在應用程序上添加一個層面會減少響應，但事實上恰好相反。

不同于加載一個網頁是，用戶會話一旦建立，瀏覽器就加載一個Ajax引擎——由JavaScript編寫并通常放置在一個隱藏幀內。引擎的責任包括構造用戶操作界面以及與服務器的溝通。Ajax引擎允許用戶與應用程序的交互異步進行——無須直接訪問服務器。所以用戶永遠不會在服務器處理數據期間瞪眼面對一個白屏和沙漏圖標。



用戶動作的處理由傳統的表單提交來激發一個HTTP請求，變為Javascript調用Ajax引擎。給用戶的回應不用等到服務器處理后返回——比如簡單的數據校驗，在內存中編輯數據，甚至一些導航功能——都直接由引擎來處理。如果引擎需要從服務器獲取些數據——提交數據給服務器處理，加載額外的界面代碼，或者獲取新數據——引擎通常以XML格式激發一個異步的請求，用戶端完全沒有被中斷的感覺。

誰在使用Ajax

Google在Ajax開發上投入了巨大的精力。去年Google推出的幾大產品——Orkut、Gmail、Google Groups最終測試版、Google Suggest和Google Maps——都是基于Ajax的應用。其他還包括：有著很多備受人們贊譽特性的Flickr（http://www.flickr.com/）基于Ajax，Amazon的A9.com搜索引擎也使用了類似的技術。

這些項目證實Ajax并不是一個技術性的實驗品，它可以實踐在現實世界的應用中。它也不是一種只能在實驗室中運用的技術。Ajax適用于從簡單的單函數Google Suggest到非常復雜的Google Maps等各種規模的應用程序。

在Adaptive Path，我們已經基于Ajax的理念工作了好幾個月，我們意識到我們也僅僅是接觸到Ajax所能帶來的非凡體驗的一點皮毛。Ajax是Web應用程序的一個重要發展，并且其重要性還在逐步增長。因為許多開發人員已經熟悉Ajax所包含的技術，我們期望看到更多的組織能夠像Google那樣通過Ajax獲得更大的競爭優勢。

更進一步

創建Ajax應用程序所面臨的最大挑戰并不在技術上。Ajax的核心技術是成熟的，穩定并被廣泛應用著。這些挑戰在于：應用設計人員忘掉所有我們所熟知的網絡限制，去想像更寬廣、更深遠的可能情況。

接下來會很有趣。

Ajax Q&A

2005年3月13日：自從Jesse發表了該文，他收到了不計其數的咨詢Ajax問題的信件，Jesse回復了其中有代表性的問題并整理成Q&A。

Q：是Adaptive Path還是Google發明了Ajax？Adaptive Path是否協助開發了Google的Ajax應用程序？
A：Ajax并不是由Adaptive Path或者Google發明的。Google最新的產品是Ajax應用程序最具代表性的例子。Adaptive Path沒有參與Google的開發，但我們在為其他的一些客戶做一些與Ajax相關的工作。

Q：Adaptive Path會出售Ajax組件或者注冊Ajax這個商標嗎？我從哪里可以下載到它？
A：Ajax并不是一個具體的軟件或程序，它是一種理念——關于用合理的技術構建Web應用程序架構的思考。Ajax這個名稱和它的理念都不是Adaptive Path私有的。

Q：Ajax只不過是XMLHttpRequest的別名嗎？
A：不是。XMLHttpRequest只是Ajax的一個組成部分。XMLHttpRequest讓客戶端與服務器的異步通訊成為可能；Ajax是本文描述的一個整體理念，它不僅依賴于XMLHttpRequest，還包括CSS、DOM和其他技術等等。

Q：為什么你會起這么個名字？
A：我們需要一個簡短的表示“Asynchronous JavaScript+CSS+DOM+XMLHttpRequest”的新詞來與客戶談我們的理念。

Q：與服務器異步通訊的技術產生很多年了，Ajax何以稱為新理念？
A：Ajax包含的技術被大量應用在現實世界中以至于改變了Web的基礎交互模式是一個新現象。Ajax是針對現在而言，因為這些技術離工業化應用還需要很多時間去開發。

Q：Ajax是一個技術平臺或者架構嗎？
A：都是。Ajax是一系列技術的無縫集合。

Q：Ajax最適合于什么樣的應用？
A：我也不知道。因為這是一個相當新的理念，就我們的理解而言，Ajax應用還處于初期階段。有時候傳統的Web應用程序模型可能更為適合。

Q：是否可以理解為Adaptive Path就是取代anti-Flash？
A：完全不是。Macromedia是Adaptive Path的客戶之一，并且我們長期為Flash技術做技術支持。待Ajax成熟后，我認為對于具體的問題，Ajax有時候會是一個更好的解決方案，同樣有時候Flash也許做得更好。我們也有興趣探討兩者的結合。（比如Flickr，它結合了兩者）。

Q：Ajax在易用性和瀏覽器兼容性上是否有限制？Ajax是否會與后退按鈕沖突？Ajax與REST（雷達電子掃描技術）兼容嗎？Ajax的開發有哪些安全考慮？Ajax能為那些禁止Javascript運行的用戶工作嗎？
A：所有這些問題的答案，我只能說“可能”。已經有很多的開發者著手這些方面的工作。要評估Ajax的所有限制，我想還需要做很多工作，我們希望Ajax開發社區能揭示更多的信息。

Q：你所提到的Google的一些應用中實際上并沒有使用XML。我一定要在Ajax應用中使用XML或XSLT嗎？
A：不是，對于Ajax客戶端，XML作為數據交換的載體是支持最為完善的（XMLHttpRequest，DOM支持）。當然，你沒有理由不接受可以達到同樣效果的技術，例如JavaScript Object Notation（http://www.crockford.com/JSON/）或者其他類似的數據交換的格式。

Q：Ajax應用比傳統的Web應用程序方便開發嗎？
A：也不盡然。Ajax的應用不可避免要在客戶端運行復雜的JavaScript腳本。編寫復雜并且高效穩定的腳本并不是一件容易的事情，優秀的開發工具和框架能幫助我們接受這一挑戰。

Q：Ajax應用程序總比傳統的Web應用程序程序更友好嗎？
A：不一定，Ajax給交互設計人員更多的靈活性。能力越大，責任也越大。我們必須小心使用Ajax去改善用戶體驗，而不是把它弄得更糟。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=542160