（本文選自《程序員》2007年第12期）
編者按：近兩年來，AJAX之風愈演愈烈，其相關技術以及背後所秉承的理念正逐漸被越來越多的開發人員所認可。隨之而來的AJAX開源框架也層出不窮。更令人欣幸的是，在衆多框架之中，我們華語開發者爲Web應用開發人員貢獻了兩個出類拔萃之作：新技術的“領頭羊”ZK，厚積薄發的“水牛”Buffalo。本期的工具欄目，邀請到ZK創始人——葉明憲和Buffalo創始人——陳金洲，對當前一些流行的AJAX框架做出點評，並且與讀者分享AJAX框架的發展現狀及趨勢。
葉明憲觀點
AJAX 已流行二、三年了，現今所謂 Web 2.0 網站或多或少有 AJAX 影子。然而新的 AJAX 框架仍不斷誕生，現有的框架也在持續推出新的版本。爲什麼？
首先，AJAX應用範圍持續擴大，從 del.icio.us 簡易的編輯功能，到 999fang.com 整合 AJAX 和數據庫搜尋，到 Google Spreadsheets 近似 Windows 應用程序。再者，AJAX已緩步進入企業應用。除了User Friendly，安全、開發及維護成本、與現有應用服務器、服務和開發環境的整合度等更是企業應用的重點。這些都已跳脫早期框架的範疇。
目前 AJAX 在企業應用正處於 Geoffrey Moore 所謂的Chasm中，預期接下二年會慢慢大量投入使用。而在消費型網站的應用正走過高成長期，聚光燈的焦點將逐漸移到如Google Spreadsheets的應用。
在這種背景之下，AJAX框架如雨後春筍，層出不窮。很多開發者朋可能都有自己的偏好，但是仍有一些開發人員面對這麼多框架，可能會感覺無從下手。我們可以從多個面向來看這些框架。
從功能面來看，可分爲以下幾類：
1、瀏覽器端的底層鏈接庫，如 Prototype, script.aculo.us, jQuery 等。
2、瀏覽器端UI組件庫，如 Ext-JS, Dojo 等。
3、整合式框架，如 ZK, Backbase, IceFaces 等。
其中，底層鏈接庫應用最廣、輕巧易整合力但功能有限。整合式框架則包括瀏覽器端及服務器端的完整框架。
DWR和GWT則較難分類。DWR基本是JavaScript-to-Java 的 RPC框架，而GWT則是在RPC 加上瀏覽器端開發工具。
從應用面來看，可粗分網站應用和企業應用。底層鏈接庫多用於網站應用或當其它框架的基礎。UI組件庫則二者都有，而整合式框架側重在企業應用。
從系統架構來看，可分Client-centric和Server-centric。所謂 Client-centric 是指你寫的程序代碼(UI部份)主要執行的地方在客戶端 (即瀏覽器)，而 Server-centric 則在服務器端。大部份框架多是 Client-centric，如Dojo, Prototype，GWT，Ext-JS，Backbase等。而Server-centric則以ZK爲代表。
一般讀者不太注意架構的差別，但它是決定開發及維護成本的關鍵。
讀到這裏，可能仍有人心存疑問：到底哪種框架適合我的應用？事實上，沒有單一個框架適合所有應用。對於強調簡易直覺接口的Web 2.0網站而言，通常只有幾個需要 AJAX化的功能，可藉由瀏覽器端的底層鏈接庫的幫助，並投入相當資源，以使這些AJAX 化出衆奪目纔是最重要的。對於現有Web應用程序，如架構於Struts、JSP或JSF等，則可依其對JavaScript熟悉度而選擇瀏覽器端UI組件庫或整合式框架。使用瀏覽器端 UI組件庫，需要較多定製化JavaScript程序代碼才能整合到原應用程序中。而使用整合式框架，則要視其是否支持現已使用的架構。例如，若使用.NET平臺，則只能使用 Microsoft的框架。若使用JSP則可使用ZK和Backbase。若使用JSF則可使用ZK，Backbase和IceFaces。
利用ZK框架設計的Web應用程序具備豐富的胖客戶端特性和簡單的設計模型。ZK包括一個基於AJAX可自動進行交互式操作的事件驅動引擎和一套兼容XUL (XML User-interface Language——基於XML的用戶接口語言)的組件。利用直觀的事件驅動模型，你可以用具有XUL特性的組件來表示你的應用程序並通過由用戶觸發的監聽事件來操作這些組件。目前，ZK 3.0 版本已發佈。提供了基於XUL和XHTML現成豐富的組件：網格、標籤頁裝飾器、樹形目錄、組合框、圖表、滾動條、分割條、音頻等等。此外，還提供了宏組件，能夠開發新組件像搭積木一樣簡單和方便。編寫腳本(Script)功能可以用EL expressions和你偏好的腳本語言，包含但不僅限於Java、JavaScript、Ruby、Groovy和MVEL的語言。值得一提的是，最新版本還集成了Google Maps, FCKeditor, Dojo以及 Timeline，並且提供對Google最新發布的手機操作平臺Android的開發支持。
有人預測，Silverlight、Flex等RIA框架的出現，將對AJAX框架構成嚴重威脅，我的看法剛好相反。Silverlight、Flex等是大型軟件公司企圖以私有 protocol 壟斷新興市場的老方法。然而因特網的巨大並不是任何人所能控制的。感謝Tim Berners-Lee等人無私的貢獻，因特網已成爲最公平最開放的平臺了。事實上 Flex 不久前纔剛轉爲 Open Source，這對定價超過一萬美元的軟件，算是個重大的挫敗。
陳金洲觀點
毫無疑問，AJAX被越來越多的接受。這不僅僅體現在技術的應用上，更體現在行業範圍內的需求提升上。Web應用這種類型不僅僅被用在企業業務系統，更多被用在Web2.0應用中。這些應用意味着以前只能被幾十人幾百人使用的系統，突然之間會有幾十萬幾百萬的用戶。用戶有了更多選擇，能夠吸引用戶駐留的，除了華麗的界面，那麼就是流暢的操作界面和快速的響應。作爲實現不打斷用戶操作的關鍵技術AJAX, 從吸引用戶這一點上，具有不可替代的使命。
意味着華麗、AJAX的Web2.0應用同樣也衝擊着企業應用的需求。雖然沒有統計數據，但可以看到越來越多的企業應用要求更直觀的界面，更流暢的操作，更少的延遲。例如，在前兩年，級聯下拉框的實現，大多數的框架（或者應用）的實現是選中一個時刷新整個頁面，然後根據選中的那個更新下一個下拉框的待選值列表。這個實現在今天看起來幾乎是完全不可接受的，無論對客戶還是對開發者。
開發者這邊，去年還有關於AJAX幾宗罪的討論，然而現在看來，更多的討論沉浸到了某一個具體技術中。在認清AJAX技術本質之後，更多的開發者或欣然接受，或用戶要求，開始了AJAX相關技術的學習和使用。從我周圍看來，曾經認爲JavaScript是不太入流的語言的程序員，現在已然逐漸發現，JavaScript很有趣，很強大；用JavaScript實現很酷的網頁效果，很有成就感，等等。
另外， AJAX這個詞本身，早已遠遠超越了它所代表的本來含義。AJAX原本是異步的JavaScript和XML。然而一看到一個絢麗的網頁（Web應用），幾乎大多數人，具備Web相關知識的，第一個問題往往是：這用的AJAX吧？──AJAX現在幾乎成爲圓角、拖拽、絢麗、無刷新的代名詞。當一個名稱上升爲一種概念、一種直覺的時候，我們應該知道，相關的技術應用到了什麼程度。
現在幾乎已經沒有人手工與XMLHttp對象打交道，絕大多數的開發者都使用Buffalo, DWR, Prototype等輔助庫、框架進行開發。
AJAX框架的選擇
由於現在很少有人只用一種AJAX技術，我將AJAX框架的範圍擴大一些，分爲偏重展現、偏重傳輸、工具型三個部分。由於我自己的Web工作語言主要在Java, Ruby以及Python之間，以下的評價不包含PHP, .NET下的一些工具。另外，對自己開發的和它的主要競爭者DWR有主要的比較，其他的僅作泛泛評述，估妄言之。
偏重展現：YUI, Qooxdoo, Dojo
·YUI ：目前設計比較完整，美觀，全面的界面工具庫。
·Qooxdoo: 開源的另一種選擇。
·Dojo: 比較完善的庫結構，豐富的界面控件。
偏重傳輸：Buffalo, DWR
Buffalo特性：
1、基於prototype。如果你的AJAX應用也是基於prototype，那麼可以減少重複加載prototype的帶寬，並且獲得相當一致的編程概念。
2、Bind: 提供了對結果數據的處理，直接將數據綁定到頁面對象並展示，這是一個動人的特性。在2.0中，Bind能力更加強大，能夠將值直接綁定到表單元素、表格、DIV/Span、甚至整個表單上。關鍵是這種綁定是無侵入並且與buffalo整體結構完全整合，對外表現只有一個簡單的{{buffalo.bindReply}}或者{{Buffalo.Bind.bind}}即可。
3、序列化：Buffalo支持任意對象，任意深度，任意數據結構的Java到JavaScript以及JavaScript到Java的雙向序列化，並且支持引用。
4、生命週期對象訪問：1.2.4之前需要繼承一個BuffaloService,從1.2.4開始就不需要繼承了，引入了線程安全的BuffaloContext對象，只需要通過BuffaloContext.getContext()即可獲得一個線程安全的引用，並且對Request的各種屬性進行操作。
5、對Collection/Array的模糊處理：Buffalo中提供了對Collection/Array對象的模糊識別能力。例如：服務器端有一個方法需要List參數，客戶端傳遞過去一個javascript數組就可以了，不需要費心的組裝對象。
6、客戶端組裝對象：Buffalo支持在客戶端組裝對象，甚至可以直接將整個表單序列化爲一個對象作爲參數傳給遠程客戶端。
7、對重載方法的處理能力：由於Java與JavaScript之間類型的不匹配，DWR的代碼生成無法對重載方法進行處理。例如，sum(double,double), sum(int, int) DWR很可能不知道你要調用哪一個。從2.0開始Buffalo支持了對重載的處理。
DWR特性：
1、支持Batch，可以將多個Service函數調用放在一個XMLHttpRequest請求中完成。
2、Converter：可以轉換任意類型的Java對象到JavaScript，並允許直接使用。例如：Customer類包含一個address變量，當AjaxCall返回Customer對象的時候，可以直接在Javascript中使用customer.address來獲得Address的信息。
3、允許Expose部分函數和屬性。（Buffalo無限制，可以訪問Service中的任意函數。）
4、DWR2.0中提出了Reverse Ajax，提供在Java代碼中來處理頁面上元素的功能。
工具型：Prototype, JQuery, Dojo
·Prototype：得益於Ruby語言的設計，它使得你能夠以幾乎類似於編寫Ruby的方式編寫JavaScript。由於綁定在Ruby On Rails的發行包中，它成爲近兩年最流行的AJAX工具。早期它小巧靈活，現在由於加入太多的特性，日漸臃腫。目前1.6版本大小已經超過120K。
·JQuery：Prototype的主要競爭者。簡單是它最大的優點。大多數常見的複雜操作、效果，JQuery的代碼量能夠比Prototype少50%以上。
·Dojo：採用類似於Java包的管理方式，實現按需加載JS。提供了全面的AJAX、DOM操作支持。然而需要在HTML TAG中嵌入額外的屬性，使得網頁不能遵守W3C標準，不少開發者對此耿耿於懷。
來自RIA框架的衝擊？
我並不贊同這種說法，恰恰相反，我認爲像Silverlight，Flex等這些RIA框架要考慮來自Web應用的衝擊。Web領域幾乎已經不存在技術壁壘，能做哪些，那些不適合，負載均衡等等已經有充分的資源可以參考。各種模式都可以靈活的應用到其中，各種測試工具（如Selenium網頁測試工具）、開發工具支持得非常出色。而RIA框架要考慮的問題遠遠要比現在的Web應用多得多。除了RIA所承諾的更容易的實現華麗的效果──在多種JS庫的支持下這些效果在Web下並非難事──他們有更多的問題需要考慮：資源的獲取和釋放，測試的支持，本地存儲的問題，事件機制，狀態的同步，客戶機、服務器數據交互機制（序列化反序列化）等等。RIA想如同現在的Web應用般大規模，遠不到時候。大多數基於RIA應用的考慮是讓應用能夠離線運行，然而與此同時瀏覽器也在發展，基於網頁的本地存貯已經在Google Reader中可以實際使用。也許某一天瀏覽器就是一個完美的RIA平臺，Web應用只需添加本地存貯支持就可以離線使用──類似於Flex、Silverlight的RIA技術，與Web應用，哪個更容易被接受，還真難見分曉。