Ajax-Web應(yīng)用的發(fā)展歷程

導(dǎo)航: 上一頁 | ASP | PHP | JSP | HTML | CSS | XHTML | aJAX | Ruby | JAVA | XML | Python | ColdFusion

最初，所有Web頁面都是靜態(tài)的，用戶請求一個資源，服務(wù)器再返回這個資源。什么都不動，什么都不閃。坦率地講，對于許多Web網(wǎng)站來說，這樣也是可以的，這些網(wǎng)站的Web頁面只是電子形式的文本，在一處生成，內(nèi)容固定，再發(fā)布到多處。在瀏覽器發(fā)展的最初階段，Web頁面的這種靜態(tài)性不成問題，科學(xué)家只是使用因特網(wǎng)來交換研究論文，大學(xué)院校也只是通過因特網(wǎng)在線發(fā)布課程信息。企業(yè)界還沒有發(fā)現(xiàn)這個新“渠道”會提供什么商機。實際上，以前公司主頁顯示的信息通常很少，無非是一些聯(lián)系信息或者只是一些文檔。不過沒過多久，Web用戶就開始有新的要求了，希望能得到更動態(tài)的網(wǎng)上體驗。個人計算機成為企業(yè)不可或缺的資源，而且從個人宿舍到住家辦公室開始出現(xiàn)越來越多的計算機。隨著Windows 95的問世，隨著人們已經(jīng)領(lǐng)教了Corel WordPerfect和Microsoft Excel豐富的功能，用戶的期望也越來越高。

目錄

• 1 CGI
• 2 applet
• 3 JavaScript
• 4 servlet、ASP和PHP
• 5 Flash
• 6 DHTML革命
• 7 XML衍生語言
• 8 基本問題
• 9 Ajax
• 10 Netflix的瀏覽頁面特性

CGI

要讓W(xué)eb更為動態(tài)，第一個辦法是公共網(wǎng)關(guān)接口（Common Gateway Interface，CGI）。與靜態(tài)的Web獲取不同，使用CGI可以創(chuàng)建程序，當用戶發(fā)出請求時就會執(zhí)行這個程序。假設(shè)要在Web網(wǎng)站上顯示銷售的商品，你可以利用CGI腳本來訪問商品數(shù)據(jù)庫，并顯示結(jié)果。通過使用簡單的HTML表單和CGI腳本，可以創(chuàng)建簡單的網(wǎng)上店面，這樣別人就可以通過瀏覽器來購買商品。編寫CGI腳本可以用多種語言，從Perl到Visual Basic都可以，這使得掌握不同編程語言的人都能編寫CGI腳本。

不過，要創(chuàng)建動態(tài)的Web頁面，CGI并不是最安全的方法。如果采用CGI，將允許別人在你的系統(tǒng)上執(zhí)行程序。大多數(shù)情況下這可能沒有問題，但是倘若某個用戶有惡意企圖，則很可能會利用這一點，讓系統(tǒng)運行你本來不想運行的程序。盡管存在這個缺陷，到如今CGI仍在使用。

applet

很顯然，CGI可以有所改進。1995年5月，Sun公司的John Gage和Andreessen（目前在Netscape通信公司）宣布一種新的編程語言誕生，這就是Java。Netscape Navigator為這種新語言提供了支持，最初是為了支持機頂盒。（你可能原認為最早涉足智能家居的公司是Microsoft和Sony其實不然。）就像所有革命都機緣巧合一樣，Java和因特網(wǎng)的出現(xiàn)恰到好處，在適當?shù)臅r間、適當?shù)牡攸c橫空出世，Java在Web上發(fā)布僅幾個月，就已經(jīng)有成千上萬的人下載。由于Netscape的Navigator支持Java，動態(tài)Web頁面掀開了新的一頁：applet時代到來了。

applet允許開發(fā)人員編寫可嵌入在Web頁面上的小應(yīng)用程序。只要用戶使用支持Java的瀏覽器，就可以在瀏覽器的Java虛擬機（Java Virtual Machine，JVM）中運行applet。盡管applet可以做很多事情，但它也存在一些限制：通常不允許它讀寫文件系統(tǒng)，它也不能加載本地庫，而且可能無法啟動客戶端上的程序。除了這些限制外，applet是在一個沙箱安全模型中運行的，這是為了有助于防止用戶運行惡意代碼。

對許多人來說，最初接觸Java編程語言就是從applet開始的，當時這是創(chuàng)建動態(tài)Web應(yīng)用的一種絕好的方法。applet允許你在瀏覽器中創(chuàng)建一個胖客戶應(yīng)用，不過要在平臺的安全限制范圍內(nèi)。當時，在很多領(lǐng)域都廣泛使用了applet，但是，Web社區(qū)并沒有完全被applet“征服”[2]。胖客戶的開發(fā)人員都很熟悉一個問題：必須在客戶端上部署適當?shù)腏ava版本。因為applet在瀏覽器的虛擬機中運行，所以開發(fā)人員必須確?？蛻舳税惭b了適當版本的Java。盡管這個問題也可以解決，但它確實妨礙了applet技術(shù)的進一步推廣。而且如果applet寫得不好，很可能對客戶主機造成影響，這使許多客戶對于是否采用基于applet的解決方案猶豫不定。

JavaScript

與此同時，Netscape創(chuàng)建了一種腳本語言，并最終命名為JavaScript（建立原型時叫做Mocha，正式發(fā)布之前曾經(jīng)改名為LiveWire和LiveScript，不過最后終于確定為JavaScript）。設(shè)計JavaScript是為了讓不太熟悉Java的Web設(shè)計人員和程序員能夠更輕松地開發(fā)applet（當然，Microsoft也推出了與JavaScript相對應(yīng)的腳本語言，稱為VBScript）。Netscape請Brendan Eich來設(shè)計和實現(xiàn)這種新語言，他認為市場需要的是一種動態(tài)類型腳本語言。由于缺乏開發(fā)工具，缺少有用的錯誤消息和調(diào)試工具，JavaScript很受非議，但盡管如此，JavaScript仍然是一種創(chuàng)建動態(tài)Web應(yīng)用的強大方法。

最初，創(chuàng)建JavaScript是為了幫助開發(fā)人員動態(tài)地修改頁面上的標記，以便為客戶提供更豐富的體驗。人們越來越認識到，頁面也可以當作對象，因此文檔對象模型（Document Object Model，DOM）應(yīng)運而生。剛開始，JavaScript和DOM緊密地交織在一起，但最后它們還是“分道揚鑣”，并各自發(fā)展。DOM是頁面的一個完全面向?qū)ο蟮谋硎荆擁撁婵梢杂媚撤N腳本語言（如JavaScript或VBScript）進行修改。

最后，萬維網(wǎng)協(xié)會（World Wide Web Consortium，W3C）介入，并完成了DOM的標準化，而歐洲計算機制造商協(xié)會（ECMA）批準JavaScript作為ECMAScript規(guī)約。根據(jù)這些標準編寫的頁面和腳本，在遵循相應(yīng)原則的任何瀏覽器上都應(yīng)該有相同的外觀和表現(xiàn)。

在最初的幾年中，JavaScript的發(fā)展很是坎坷，這是許多因素造成的。首先，瀏覽器支持很不一致，即使是今天，同樣的腳本在不同瀏覽器上也可能有不同的表現(xiàn)；其次，客戶可以自由地把JavaScript關(guān)閉，由于存在一些已知的安全漏洞，往往鼓勵用戶把JavaScript關(guān)掉。由于開發(fā)JavaScript很有難度（你會用alert嗎？），許多開發(fā)人員退避三舍，有些開發(fā)人員干脆不考慮 JavaScript，認為這是圖形設(shè)計人員使用的一種“玩具”語言。許多人曾試圖使用、測試和調(diào)試復(fù)雜的JavaScript，并為此身心俱疲，所以大多數(shù)人在經(jīng)歷了這種痛苦之后，最終只能滿足于用JavaScript創(chuàng)建簡單的基于表單的應(yīng)用。

servlet、ASP和PHP

盡管applet是基于Web的，但胖客戶應(yīng)用存在的許多問題在applet上也有所體現(xiàn)。在大量使用撥號連接的年代（就算是今天，撥號連接也很普遍），要下載一個復(fù)雜applet的完整代碼，要花很多時間，用戶不能承受。開發(fā)人員還要考慮客戶端上的Java版本，有些虛擬機還有更多的要求[3]。理想情況下只需提供靜態(tài)的Web頁面就夠了，畢竟，這正是設(shè)計因特網(wǎng)的本來目的。當然，盡管靜態(tài)頁面是靜態(tài)的，但是如果能在服務(wù)器上動態(tài)地生成內(nèi)容，再把靜態(tài)的內(nèi)容返回，這就太好了。

在Java問世一年左右，Sun引入了servlet?，F(xiàn)在Java代碼不用再像applet那樣在客戶端瀏覽器中運行了，它可以在你控制的一個應(yīng)用服務(wù)器上運行。這樣，開發(fā)人員就能充分利用現(xiàn)有的業(yè)務(wù)應(yīng)用，而且，如果需要升級為最新的Java版本，只需要考慮服務(wù)器就行了。Java推崇“一次編寫，到處運行”，這一點使得開發(fā)人員可以選擇最先進的應(yīng)用服務(wù)器和服務(wù)器環(huán)境，這也是這種新技術(shù)的另一個優(yōu)點。servlet還可以取代CGI腳本。

servlet向前邁出了很大一步。servlet提供了對整個Java應(yīng)用編程接口（API）的完全訪問，而且提供了一個完備的庫可以處理HTTP。不過，servlet不是十全十美的。使用servlet設(shè)計界面可能很困難。在典型的servlet交互中，先要從用戶那里得到一些信息，完成某種業(yè)務(wù)邏輯，然后使用一些“打印行”創(chuàng)建HTML，為用戶顯示結(jié)果。代碼清單1-1所示的代碼就相當常見。

Flash

并不是只有Microsoft和Sun在努力尋找辦法來解決動態(tài)Web頁面問題。1996年夏天，F(xiàn)utureWave發(fā)布了一個名叫FutureSplash Animator的產(chǎn)品。這個產(chǎn)品起源于一個基于Java的動畫播放器，F(xiàn)utureWave很快被Macromedia兼并，Macromedia則將這個產(chǎn)品改名為Flash。

利用Flash，設(shè)計人員可以創(chuàng)建令人驚嘆的動態(tài)應(yīng)用。公司可以在Web上發(fā)布高度交互性的應(yīng)用，幾乎與胖客戶應(yīng)用相差無幾（見圖1-4）。不同于applet、servlet和CGI腳本，F(xiàn)lash不需要編程技巧，很容易上手。在20世紀90年代末期，掌握Flash是一個很重要的特長，因為許多老板都非常需要有這種技能的員工。不過，這種易用性也是有代價的。

像許多解決方案一樣，F(xiàn)lash需要客戶端軟件。盡管許多流行的操作系統(tǒng)和瀏覽器上都內(nèi)置有所需的Shockwave播放器插件，但并非普遍都有。雖然能免費下載，但由于擔心感染病毒，使得許多用戶都拒絕安裝這個軟件。Flash應(yīng)用可能還需要大量網(wǎng)絡(luò)帶寬才能正常地工作，另外，由于沒有廣泛的寬帶連接，F(xiàn)lash的推廣受到局限（因此產(chǎn)生了“跳過本頁”之類的鏈接）。雖然確有一些網(wǎng)站選擇建立多個版本的Web應(yīng)用，分別適應(yīng)于不同的連接速度，但是許多公司都無法承受支持兩個或更多網(wǎng)站所增加的開發(fā)開銷。

總之，創(chuàng)建Flash應(yīng)用需要專用的軟件和瀏覽器插件。applet可以用文本編輯器編寫，而且有一個免費的Java開發(fā)包，F(xiàn)lash則不同，使用完整的Flash工具包需要按用戶數(shù)付費，每個用戶需要數(shù)百美元。盡管這些因素不是難以逾越的障礙，但它們確實減慢了Flash在動態(tài)Web應(yīng)用道路上的前進腳步。

DHTML革命

當Microsoft和Netscape發(fā)布其各自瀏覽器的第4版時，Web開發(fā)人員有了一個新的選擇：動態(tài)HTML（Dynamic HTML，DHTML）。與有些人想像的不同DHTML不是一個W3C標準，它更像是一種營銷手段。實際上，DHTML結(jié)合了HTML、層疊樣式表（Cascading Style Sheets，CSS）、JavaScript和DOM。這些技術(shù)的結(jié)合使得開發(fā)人員可以動態(tài)地修改Web頁面的內(nèi)容和結(jié)構(gòu)。

最初DHTML的反響很好。不過，它需要的瀏覽器版本還沒有得到廣泛采用。盡管IE和Netscape都支持DHTML，但是它們的實現(xiàn)大相徑庭，這要求開發(fā)人員必須知道他們的客戶使用什么瀏覽器。而這通常意味著需要大量代碼來檢查瀏覽器的類型和版本，這就進一步增加了開發(fā)的開銷。有些人對于嘗試這種方法很是遲疑，因為DHTML還沒有一個官方的標準。不過，將來新標準有可能會出現(xiàn)。

XML衍生語言

20世紀90年代中期，基于SGML衍生出了W3C的可擴展標記語言（eXtensible Markup Language，XML），自此以后，XML變得極為流行。許多人把XML視為解決所有計算機開發(fā)問題的靈丹妙藥，以至于XML幾乎無處不在。實際上，Microsoft就已經(jīng)宣布，Office 12將支持XML文件格式。

如今，我們至少有4種XML衍生語言可以用來創(chuàng)建Web應(yīng)用（W3C的XHTML不包括在內(nèi)）：Mozilla的XUL；XAMJ，這是結(jié)合Java的一種開源語言；Macromedia的MXML； Microsoft的XAML。

XUL：XUL（讀作“zool”）代表XML用戶界面語言（XML User Interface Language），由Mozilla基金會推出。流行的Firefox瀏覽器和Thunderbird郵件客戶端都是用XUL編寫的。利用XUL，開發(fā)人員能構(gòu)建功能很豐富的應(yīng)用，這個應(yīng)用可以與因特網(wǎng)連接，也可以不與因特網(wǎng)連接。為了方便那些熟悉DHTML的開發(fā)人員使用，XUL設(shè)計為可以跨平臺支持諸如窗口和按鈕等標準界面部件。雖然XUL本身不是標準，但它是基于各種標準的，如HTML 4.0、CSS、DOM、XML和ECMAScript等等。XUL應(yīng)用可以在瀏覽器上運行，也可以安裝在客戶端主機上。

當然，XUL也不是沒有缺點。它需要Gecko引擎，而且目前IE還沒有相應(yīng)的插件。盡管Firefox在瀏覽器市場中已經(jīng)有了一定的份額，但少了IE的支持還是影響很大，大多數(shù)應(yīng)用都無法使用XUL。目前開展的很多項目都是力圖在多個平臺上使用XUL，包括Eclipse。

XAML：XAML（讀作“zammel”）是Microsoft即將推出的操作系統(tǒng)（名為Windows Vista）的一個組件。XAML是可擴展應(yīng)用標記語言（eXtensible Application Markup Language）的縮寫，它為使用Vista創(chuàng)建用戶界面定義了標準。與HTML類似，XAML使用標記來創(chuàng)建標準元素，如按鈕和文本框等。XAML建立在Microsoft的 .NET平臺之上，而且可以編譯為 .NET類。

XAML的局限應(yīng)當很清楚。作為Microsoft的產(chǎn)品，它要求必須使用Microsoft的操作系統(tǒng)。多數(shù)情況下特別是在大公司中，這可能不成問題，但是有些小公司使用的不是Microsoft的操作系統(tǒng)，總不能削足適履吧，就像是沒有哪家公司會因為買家沒有開某種牌子的車來就把他拒之門外。Vista交付的日期一再推遲，與此同時XAML也有了很大變化，不再只是一個播放器。據(jù)說，在未來幾年內(nèi)，我們可能會看到一個全新的XAML。

MXML：Macromedia創(chuàng)建了MXML，作為與其Flex技術(shù)一同使用的一種標記語言。MXML是最佳體驗標記語言（Maximum eXperience Markup Language）的縮寫，它與HTML很相似，可以以聲明的方式來設(shè)計界面。與XUL和XAML類似，MXML提供了更豐富的界面組件，如DataGrid和TabNavigator，利用這些組件可以創(chuàng)建功能豐富的因特網(wǎng)應(yīng)用。不過，MXML不能獨立使用，它依賴于Flex和ActionScript編程語言來編寫業(yè)務(wù)邏輯。

MXML與Flash有同樣的一些限制。它是專用的，而且依賴于價格昂貴的開發(fā)和部署環(huán)境。盡管將來.NET可能會對MXML提供支持，但現(xiàn)在Flex只能在J2EE應(yīng)用服務(wù)器上運行，如Tomcat和IBM的WebSphere，這就進一步限制了MXML的廣泛采用。

XAMJ：讓人欣喜的是，開源社區(qū)又向有關(guān)界面設(shè)計的XML衍生語言領(lǐng)域增加了新的成員。XAMJ作為另一種跨平臺的語言，為Web應(yīng)用開發(fā)人員又提供了一個工具。這種衍生語言基于Java，而Java是當前最流行的面向?qū)ο笳Z言之一，XAMJ也因此獲得了面向?qū)ο笳Z言的強大功能。XAMJ實際上想要替代基于XAML或HTML的應(yīng)用，力圖尋找一種更為安全的方法，既不依賴于某種特定的框架，也不需要高速的因特網(wǎng)連接。XAMJ是一種編譯型語言，建立在“clientlet”（小客戶端）體系結(jié)構(gòu)之上，盡管基于XAMJ的程序也可以是獨立的應(yīng)用，但通常都是基于Web的應(yīng)用。在撰寫本書時，XAMJ還太新，我們還沒有聽到太多批評的聲音。不過，批評是肯定會有的，讓我們拭目以待。

當談到“以X開頭的東西”時，別忘了W3C XForms規(guī)約。XForms設(shè)計為支持更豐富的用戶界面，而且能夠?qū)?shù)據(jù)與表示解耦合。毋庸置疑，XForms數(shù)據(jù)是XML，這樣你就能使用現(xiàn)有的XML技術(shù)，如XPath和XML Schema。標準HTML能做的，XForms都能做，而且XForms還有更多功能，包括動態(tài)檢查域值、與Web服務(wù)集成等等。不同于其他的許多W3C規(guī)約，XForms不需要新的瀏覽器，你可以使用現(xiàn)在已有的許多瀏覽器去實現(xiàn)。與大多數(shù)XML衍生語言一樣，XForms是一種全新的方法，所以它要得到采納尚需時日。

基本問題

有了以上了解，你怎么想？即使是要求最苛刻的客戶應(yīng)用，也已經(jīng)把Web作為首選平臺。很顯然，基于Web的應(yīng)用很容易部署，這種低門檻正是Web應(yīng)用最耀眼的地方。由于瀏覽器無處不在，而且無需下載和安裝新的軟件，用戶利用基于瀏覽器的客戶端就能很輕松地嘗試新的應(yīng)用。用戶只需點擊一個鏈接就能運行你的應(yīng)用程序，而不用先下載幾兆比特的安裝程序才行?；跒g覽器的應(yīng)用也不考慮操作系統(tǒng)是什么，也就是說，不僅使用不同操作系統(tǒng)（如Linux和Mac OS X）的人能運行你的應(yīng)用程序，而且你也不必考慮針對不同的操作系統(tǒng)開發(fā)和維護多個安裝包。

既然基于Web的應(yīng)用是前所未有的好東西，那我們?yōu)槭裁催€要寫這本書？如果回頭看看因特網(wǎng)的起源就可以知道，最初因特網(wǎng)實際上就是為了科學(xué)家們和學(xué)術(shù)機構(gòu)間交換文章和研究成果，這是一種簡單的請求/響應(yīng)模式。那時不需要會話狀態(tài)，也不需要購物車，人們只是在交換文檔。但現(xiàn)在你有很多辦法來創(chuàng)建動態(tài)的Web應(yīng)用，如果想讓應(yīng)用真正深入人心，贏得大量的用戶，就必須在瀏覽器上大做文章，這說明，因特網(wǎng)以請求/響應(yīng)模式作為基礎(chǔ)，由此帶來的同步性對你造成了妨礙。

與Microsoft Word或Intuit Quicken之類的胖客戶應(yīng)用相比，Web模型當然只能根據(jù)一般用戶需要做折中考慮。不過，由于Web應(yīng)用很容易部署，而且瀏覽器的發(fā)展相當迅速，這意味著大多數(shù)用戶都已經(jīng)學(xué)會了適應(yīng)。但是，還是有許多人認為Web應(yīng)用只能算“二等公民”，給人的用戶體驗不是太好。因為因特網(wǎng)是一個同步的請求/響應(yīng)系統(tǒng)，所以瀏覽器中的整個頁面會進行刷新。最初，這種簡單的請求并沒有什么問題。如果用戶做了一兩處修改，就必須向服務(wù)器發(fā)回整個文檔，而且要重新繪制整個頁面。盡管這樣是可行的，但是這種完全刷新的局限，意味著應(yīng)用確實還很粗糙。

這并不是說開發(fā)人員只是袖手旁觀，全然接受這種狀況。Microsoft對于交互式應(yīng)用有一定了解，而且對于這種標準請求/響應(yīng)模式的限制一直都不滿意，因此提出了遠程腳本（remote scripting）的概念。遠程腳本看似神奇，其實很簡單：它允許開發(fā)人員創(chuàng)建以異步方式與服務(wù)器交互的頁面。例如，顧客可以從下拉列表中選擇狀態(tài)，這樣就會在服務(wù)器上運行一個腳本，計算顧客的運費。更重要的是，顯示這些運費時無需刷新整個頁面！當然，Microsoft的方案只適用于它自己的技術(shù)，而且需要Java，但有了這個進步，說明更豐富的瀏覽器應(yīng)用并不是海市蜃樓。

對于同步頁面刷新問題還有其他一些解決方案。針對Microsoft的遠程腳本，Brent Ashley在創(chuàng)建JavaScript遠程腳本（JavaScript Remote Scripting，JSRS）時開發(fā)了一個平臺中立（獨立于平臺）的方案。JSRS依賴于一個客戶端JavaScript庫和DHTML，可以向服務(wù)器做異步的調(diào)用。與此同時，許多人利用了IFRAME標記，可以只加載頁面中的某些部分，或者向服務(wù)器做“隱藏”的調(diào)用。盡管這是一個可行的方法，而且也為很多人所用，但它肯定不是最理想的，還有待改善。

Ajax

終于談到這里了：客戶希望得到一個功能更完備的應(yīng)用，而開發(fā)人員想避開繁瑣的部署工作，不想把可執(zhí)行文件逐個地部署到數(shù)以千計的工作站上。我們已經(jīng)做過很多嘗試，但是任何方法都不像它原來標榜的那么完美。不過，最近一個極其強大的工具橫空出世了。

是的，我們又有了一個新的選擇，新的工具，可以創(chuàng)建的確豐富的基于瀏覽器的應(yīng)用。這就是Ajax。Ajax不只是一個特定的技術(shù)，更應(yīng)算是一種技巧，不過前面提到的JavaScript是其主要組件。我們知道，你可能會說“JavaScript根本不值一提”，但是由于Ajax的出現(xiàn)，人們對這種語言又有了新的興趣，應(yīng)用和測試框架再加上更優(yōu)秀的工具支持，減輕了開發(fā)人員肩頭的重擔。隨著Atlas的引入，Microsoft對Ajax投入了大力支持，而名聲不太好的Rails Web框架也預(yù)置了充分的Ajax支持。在Java世界中，Sun已經(jīng)在其BluePrints Solutions Catalog中增加了許多Ajax組件。

坦率地講，Ajax并不是什么新鮮玩藝。實際上，與這個詞相關(guān)的“最新”術(shù)語就是XMLHttpRequest對象（XHR），它早在IE 5（于1999年春天發(fā)布）中就已經(jīng)出現(xiàn)了，是作為 Active X控件露面的。不過，最近出現(xiàn)的新現(xiàn)象是瀏覽器的支持。原先，XHR對象只在IE中得到支持（因此限制了它的使用），但是從Mozilla 1.0和Safari 1.2開始，對XHR對象的支持開始普及。這個很少使用的對象和相關(guān)的基本概念甚至已經(jīng)出現(xiàn)在W3C標準中：DOM Level 3 加載和保存規(guī)約（DOM Level 3 Load and Save Specification）。現(xiàn)在，特別是隨著Google Maps、Google Suggest、Gmail、Flickr、Netflix和A9等應(yīng)用變得越來越炙手可熱，XHR也已經(jīng)成為事實上的標準。

與前面幾頁提到的方法不同，Ajax在大多數(shù)現(xiàn)代瀏覽器中都能使用，而且不需要任何專門的軟件或硬件。實際上，這種方法的一大優(yōu)勢就是開發(fā)人員不需要學(xué)習一種新的語言，也不必完全丟掉他們原先掌握的服務(wù)器端技術(shù)。Ajax是一種客戶端方法，可以與J2EE、.NET、PHP、Ruby和CGI腳本交互，它并不關(guān)心服務(wù)器是什么。盡管存在一些很小的安全限制，你還是可以現(xiàn)在就開始使用Ajax，而且能充分利用你原有的知識。

你可能會問：“誰在使用Ajax？”前面已經(jīng)提到，Google顯然是最早采用Ajax的公司之一，而且已經(jīng)用在很多技術(shù)上，隨便說幾個應(yīng)用，如Google Maps、Google Suggest和Gmail。Yahoo!也開始引入Ajax控件，另外Amazon提供了一個簡潔的搜索工具，其中大量使用了這個技術(shù)，例如，在鉆石的某一方面上移動滑塊，這會帶來動態(tài)更新的結(jié)果（見圖1-5）。并不是每次改變你的查詢標準時都會更新頁面，而是在移動滑塊時就會查詢服務(wù)器，從而更快、更容易地縮小你的選擇范圍。

Netflix是一家很有名的DVD租借公司，它也使用了Ajax。當用戶瀏覽影片時，可以得到更詳細的信息。當顧客把鼠標放在一個影片的圖片上時，這個影片的ID就會發(fā)送到中心服務(wù)器，然后會出現(xiàn)一個“氣泡”，提供這個影片的更多細節(jié)（見圖1-6）。同樣，頁面并不會刷新，每個影片的詳細信息并不是放在隱藏的表單域中。利用這種方法，Netflix可以提供影片的更多信息，而不會把頁面弄亂。顧客瀏覽起來也更容易，他們不必點擊影片，看完影片詳細信息后再點擊回到影片列表頁面；他們只需把鼠標停在影片上，就這么簡單！我們想要強調(diào)的是，Ajax并不限于.com之類的網(wǎng)站使用，普通公司的開發(fā)人員也開始涉足這個技術(shù)，有些人已經(jīng)在使用Ajax來改善原來很丑陋的驗證方案，或者用于動態(tài)地獲取數(shù)據(jù)了。

Netflix的瀏覽頁面特性

關(guān)鍵在于，因特網(wǎng)默認的請求/響應(yīng)模式有了重大轉(zhuǎn)變，這正是Ajax的核心所在，盡管這并非全新的內(nèi)容。Web應(yīng)用開發(fā)人員現(xiàn)在可以自由地與服務(wù)器異步交互，這說明他們可以完成許多原本只能在胖客戶上完成的任務(wù)。例如，當用戶輸入郵政編碼時，可以驗證它是否正確，然后自動用相應(yīng)的城市名和州名填充到表單中的其他部分；或者，當用戶選擇美國時，可以引入美國各個州的一個下拉列表。以前也可以用其他方式模擬這些工作，但是使用Ajax的話，這些工作會更加簡單。

那么，是誰發(fā)明了Ajax？要找出真正的源頭，總免不了一場爭論。不過有一點是確定的，2005年2月，Adaptive Path的Jesse James Garrett最早創(chuàng)造了這個詞。在他的文章Ajax: A New Approach to Web Applications（Ajax：Web應(yīng)用的一種新方法）中，Garrett討論了如何消除胖客戶（或桌面）應(yīng)用與瘦客戶（或Web）應(yīng)用之間的界限。當然，當Google在Google Labs發(fā)布Google Maps和Google Suggest時，這個技術(shù)才真正為人所認識，而且此前已經(jīng)有許多這方面的文章了。但確實是Garrett最早提出了這個好名字，否則我們就得啰啰嗦嗦地說上一大堆：異步（Asynchronous）、XMLHttpRequest、JavaScript、CSS、DOM等等。盡管原來把Ajax認為是Asynchronous JavaScript + XML（異步JavaScript + XML）的縮寫，但如今，這個詞的覆蓋面有所擴展，把允許瀏覽器與服務(wù)器通信而無需刷新當前頁面的技術(shù)都涵蓋在內(nèi)。

你可能會說：“哦，那有什么大不了的？”這么說吧，使用XHR而且與服務(wù)器異步通信，就能創(chuàng)建更加動態(tài)的Web應(yīng)用。例如，假設(shè)你有一個下拉列表，它是根據(jù)另外一個域或下拉列表的輸入來填寫的。在正常情況下，必須在加載第一個頁面時把所有數(shù)據(jù)都發(fā)送給客戶端，然后使用JavaScript根據(jù)輸入來填寫下拉列表。這么做并不困難，但是會讓頁面變得很臃腫，取決于這個下拉列表到底有多“動態(tài)”，頁面有可能膨脹得過大，從而出現(xiàn)問題。利用Ajax，當作為觸發(fā)源的域有變化，或者失去了輸入焦點，就可以向服務(wù)器發(fā)一個簡單的請求，只要求得到更新下拉列表所需的部分信息即可。

來單獨考慮一下驗證。你寫過多少次JavaScript驗證邏輯？用Java或C#編寫驗證邏輯可能很簡單，但是由于JavaScript缺乏很好的調(diào)試工具，再加上它是一種弱類型語言，所以用JavaScript編寫驗證邏輯實在是一件讓人頭疼的事情，而且很容易出錯。服務(wù)器上還很有可能重復(fù)這些客戶端驗證規(guī)則。使用XHR，可以對服務(wù)器做一個調(diào)用，觸發(fā)某一組驗證規(guī)則。這些規(guī)則可能比你用JavaScript編寫的任何規(guī)則都更豐富、更復(fù)雜，而且你還能得到功能強大的調(diào)試工具和集成開發(fā)環(huán)境（IDE）。

你現(xiàn)在可能又會說：“這些事情我早已經(jīng)用IFRAME或隱藏框架做到了?！蔽覀兩踔吝€使用這種技術(shù)來提交或刷新過頁面的一部分，而不是整個瀏覽器（頁面）。不能不承認，這確實可行。不過，許多人認為這種方法只是一種修補手段，以彌補XHR原來缺乏對跨瀏覽器的支持。作為Ajax的核心，XHR對象設(shè)計為允許從服務(wù)器異步地獲取任意的數(shù)據(jù)。

我們討論過，傳統(tǒng)的Web應(yīng)用遵循一種請求/響應(yīng)模式。如果沒有Ajax，對于每個請求都會重新加載整個頁面（或者利用IFRAME，則是部分頁面）。原來查看的頁面會放到瀏覽器的歷史棧中（不過，如果使用了IFRAME，點擊“后退”按鈕不一定能得到用戶期望的歷史頁面）。與此不同，用XHR做出的請求不會記錄在瀏覽器的歷史中。如果你的用戶習慣于使用“后退”按鈕在Web應(yīng)用中進行導(dǎo)航，就可能會產(chǎn)生問題。