Google Web Toolkit 已經(jīng)吸引了全世界無數(shù)web程序員的眼球，因?yàn)樗兄Z能夠使AJAX Web開發(fā)變得簡單。但是，它到底有多大的優(yōu)勢?而且，更為重要的是，我們有多需要它呢?
　　這是一個否認(rèn)的聲音——首先，作為一個開發(fā)人員和框架架構(gòu)師，我發(fā)現(xiàn)Google Web Toolkit (GWT)非常得迷人。它是那些非常有才能的人才能做出來的相當(dāng)棒的軟件。但是，問題是:在企業(yè)軟件開發(fā)的領(lǐng)域中，這種吸引力的作用好像并不大。我的意思是，量身定制的軟件中包含著成百上千個用例，而這些用例之間存在著極其復(fù)雜的交互業(yè)務(wù)和GUI邏輯。這種軟件對于大多數(shù)程序員來說非常重要，因?yàn)楣ぷ髦袝可娴健６疫@種軟件也是我下面要探討的Web應(yīng)用程序開發(fā)的類型。
　　首先，我們來總結(jié)一下GWT為(Java)Web 開發(fā)團(tuán)體所帶來的創(chuàng)新，有以下幾點(diǎn):
　　一個使用Java.lang API實(shí)現(xiàn)的從Java到Javascript的編譯器——雖然這個想法很棒，但是，這確實(shí)不能算是創(chuàng)新。因?yàn)椋辽儆幸粋€以上的方案(J2S)已經(jīng)提供了與此類似的特性，實(shí)際上，還提供了更先進(jìn)的JavaScript生成特性。
　　一個窗口組件庫，能夠在不使用HTML的情況下構(gòu)建用戶界面(UI)。這有些類似于Dojo中具備的功能，并且與J2S/RIA幾乎相同。除此之外，還有一些服務(wù)器端的框架也能夠提供相同的功能(如Echo2、wingS)
　　一個在HTTP協(xié)議上的遠(yuǎn)程過程調(diào)用(RPC)的實(shí)現(xiàn)，它能夠通過DWR在其他協(xié)議上實(shí)現(xiàn)。
　　一個允許在Java中調(diào)試應(yīng)用程序的容器。實(shí)際上，J2S確實(shí)不需要這個功能，因?yàn)樗軌蚪忉孲WT/RCP代碼，并且作為桌面應(yīng)用程序自動運(yùn)行。
　　在項(xiàng)目開始時，腳本是受到了Ruby on Rails的啟發(fā)(至少是類似的)。
　　因此，Google主要是陷入了這個嚴(yán)重的問題:重新實(shí)現(xiàn)所有這些可利用的項(xiàng)目。當(dāng)然，你可以爭辯說，他們實(shí)現(xiàn)得更好、用起來更加方便、使代碼更加文檔化(這通常是一個項(xiàng)目成功與失敗的關(guān)鍵)。但是，他們既然夠像重新實(shí)現(xiàn)無數(shù)的其他項(xiàng)目，那為什么不重新實(shí)現(xiàn)Eclipse項(xiàng)目呢?而且，他們?yōu)槭裁床焕秘S富客戶端平臺(RCP)或者豐富互聯(lián)網(wǎng)應(yīng)用程序(RIA)堆棧呢?
　　關(guān)于這個問題，我的回答非常簡單——Google希望解決他們自己的問題。為了理解GWT，我們首先需要理解Google創(chuàng)建它的動機(jī)。Google是不做商業(yè)軟件的——他們做桌面軟件，然后把它們放到web上(如GMail、Base、Spreadsheet、Calendar等)。這些軟件所包含的用例相對較少，而用例通常都是很復(fù)雜的并且需要響應(yīng)的。
　　Google需要一種開發(fā)新的web應(yīng)用程序的方式，這種方式應(yīng)該是:
　　1. 高度響應(yīng)的
　　2. 迅速開發(fā)的
　　3. 迷人的
　　其中，第二個目標(biāo)的障礙是:如果要在web上達(dá)到高度響應(yīng)，那么，你必須采用很多快速解決方案，而且更糟糕的是，你需要針對不同的瀏覽器采用不同的快速解決方案。正是這個問題使AJAX應(yīng)用程序的開發(fā)成本遠(yuǎn)遠(yuǎn)高于普通應(yīng)用程序的。
　　針對這個問題，一個顯著的解決方案是:把這些快速解決方案封裝起來，放到簡潔的界面背后。還有一個不很顯著的解決方案是:使用大量的集成開發(fā)環(huán)境(IDE)和調(diào)試器，把快速解決方案封裝到靜態(tài)類型語言中，然后，盡量避免在應(yīng)用程序中同時使用JavaScript。因此，GWT是解決快速開發(fā)AJAX類桌面應(yīng)用程序的最佳方案，并且，GWT能夠運(yùn)行在主流的瀏覽器上而僅需要相當(dāng)少的測試。
　　但是，剩下的開發(fā)人員應(yīng)該怎么辦呢(尤其是那些編寫大型商業(yè)應(yīng)用程序的開發(fā)人員)?我的觀點(diǎn)是:如果GWT不是100%純粹基于JavaScript的話，那么它將是一種非常棒的視圖技術(shù)。關(guān)于HTML和JavaScript的問題是:目前，至少有4種大型的不兼容的平臺實(shí)現(xiàn)機(jī)制。我們正在討論的就是:一種能夠配套四種虛擬機(jī)的語言，同時它能夠與事后制定的標(biāo)準(zhǔn)松散耦合——James Gosling的惡夢實(shí)現(xiàn)了。
　　Web在商業(yè)應(yīng)用程序中能夠得到如此廣泛的使用，其中一個主要原因就是:它是建立在Java承諾一次編程處處運(yùn)行的基礎(chǔ)上的(因?yàn)閣eb平臺比Java簡單得多，而且對客戶端環(huán)境的依賴較少)。而且web也能夠給我們提供這些可能的特性:易于混搭、整合、重新設(shè)計(jì)等等。但是，JavaScript卻使這個承諾變得毫無意義，因?yàn)樵跒g覽器中存在著:
　　對于腳本規(guī)模的限制
　　對于腳本存儲消耗的限制
　　對于腳本運(yùn)行時間的限制
　　交叉域的訪問限制
　　非常多其他類型的限制，程序缺陷和不兼容性，這些都在折磨著web程序員
　　所有的這些意味著你只能封裝這么多——遲早一些“有毅力”的bug會死灰復(fù)燃，或者，使用標(biāo)準(zhǔn)工具包的話，你可能完成更多工作，而現(xiàn)在，你還需要采用JavaScript快速解決方案。實(shí)際上，我?guī)缀跄軌虼_保:在所有規(guī)模足夠大并且復(fù)雜的應(yīng)用程序中，這種現(xiàn)象很快就會出現(xiàn)(我的意思是像內(nèi)存溢出這樣的bug，它們幾乎不可能在平臺中被調(diào)試出來)。確實(shí)，對于應(yīng)用程序而言，HTML和HTTP從來都是沒有意義的，它們的作用是用于在科學(xué)家之間分享信息的。不久，動態(tài)DOM、CSS、XML以及其他縮略語所代表的技術(shù)將運(yùn)用到這些應(yīng)用程序中來，雖然它們能夠適合，但是，并不匹配——你可以用，但是無法走得很遠(yuǎn)。
　　現(xiàn)在，結(jié)束對AJAX的討論，我們切換到應(yīng)用程序本身上來。一個典型的大型企業(yè)應(yīng)用程序有著各種不同的用戶界面需求，而不僅僅是一個典型的桌面界面。在商業(yè)應(yīng)用程序的圖形用戶界面(GUI)中，有許多大而復(fù)雜的工作流，但是，只是一小部分這樣的工作流是需要達(dá)到高度響應(yīng)的(典型地，某些查詢或者搜索)。而且，通過使用HTML并且添加一些獨(dú)立于瀏覽器的JavaScript，這些需求是很容易滿足的。實(shí)際上，如果我們對商業(yè)用戶的需求進(jìn)行調(diào)查的話，就能夠了解到他們所需要的軟件是:
　　滿足他們需要
　　能夠快速開發(fā)、價格合理
　　不要與單獨(dú)的開發(fā)商或者合作者綁定
　　易于與其他軟件整合
　　通過以上分析，能夠找到給商業(yè)世界帶來這些的軟件，并不是那些沒有使用AJAX的軟件。在web框架中，首先需要滿足的是高度響應(yīng)和整合——可能這就是為什么Struts如此流行的一個原因(運(yùn)用Struts的主要過程是解決大量的遺留代碼)。而且AJAX，如果有什么區(qū)別的話，那就是:加大整合難度、降低生產(chǎn)力。
　　但是，這就意味著我將永遠(yuǎn)宣傳簡單的web應(yīng)用程序么?當(dāng)然，不是!我只是認(rèn)為:基于IE來模擬桌面，這是商業(yè)客戶端所無法承受的。如果已經(jīng)做好了一個通用的豐富的GUI平臺，那么，我將成為第一個進(jìn)行試驗(yàn)的人。使Eclipse 豐富客戶端平臺(RCP)更加完美或者在Adobe Flash上編譯Java應(yīng)用程序(至少是穩(wěn)定的平臺)，甚至可能將Avalon運(yùn)行在Linux上。僅僅給我一些任務(wù)——讓我以此來編寫Java代碼、并且?guī)淼睦_比web應(yīng)用程序少，我就能夠無障礙地工作了。
　　因此，在未來的幾年內(nèi)，Google Web Toolkit至關(guān)重要么?我肯定希望是不，因?yàn)檫@將意味著，我們必須在本質(zhì)上具有破壞性的平臺上來構(gòu)建下一代的應(yīng)用程序。而且，不論我是否有偏見，在21世紀(jì)的前十年內(nèi)，我非常希望能夠看到更好的平臺發(fā)布。