我想創建一個數據庫支持的交互式AJAX webapp，它具有自定義（特定種類的事件，編輯）日曆系統。這將涉及到很多JavaScript和AJAX，我想到了用於接口的Google Web Toolkit和用於服務器端的Ruby on Rails。我應該爲我的新webapp使用Google Web Toolkit嗎？
Google Web Toolkit的可靠性和良好性？如果我選擇Google Web Toolkit，可能存在哪些隱患？可以輕鬆地將它與服務器端的Ruby on Rails結合起來嗎？或者我應該嘗試直接使用像jQuery這樣的JavaScript庫？我有沒有web開發經驗，除了一些HTML，但我是一個有經驗的程序員（c + +，java，c＃），我想只使用這個項目的免費工具。
您可以使用GWT在Java中編寫所有代碼，並且可以將現有的第三方JavaScript庫與它集成。這很好。雖然我從來沒有使用過RoR，所以對此無話可說。
如果你有Java的經驗，但不是Javascript/CSS，那麼GWT將成爲一個救生員（當然，除非你想學習它們）。 CSS有那麼多小小的細節。花費半天的時間修復只發生在IE6中的2像素錯位並不罕見。
我不確定在後端使用ROR會是多麼容易......我相信這是可能的，因爲GWT ajax通信只是servlet。但是它們提供了一些非常好的功能來傳遞Java對象，如果您的服務器不使用Java，那麼您將無法使用它們。
你也可以考慮Grails（「Groovy on Rails」），它給你帶來了Rails框架的好處以及Java VM的使用。
如果你知道JAVA，並且有一個地方可以託管它（比如一個tomcat或者glassfish容器），那麼我會推薦這比使用Ruby做後端更多。主要原因是你可以共享你的所有對象，並使用內置的RPC機制。我已經完成了很多項目，這是一個巨大的時間段，更不用說代碼不太容易出錯，因爲您不會將Java對象轉換爲任何東西，然後再返回。
我已經將我的GWT與Rails鏈接起來，在Rails中使用to_json函數，然後閱讀GWT中的JSON。這一切都得到了支持，但它比在JAVA中做後臺更麻煩。
當然，如果你有便宜的主機，那麼Java容器幾乎是不可能的，在這種情況下，我會認爲Rails會成爲下一個最好的東西。
GWT是一個非常優秀的社區。然而，如果你想調整事物的外觀，你確實需要知道CSS - 如果你願意，CSS可以做很多佈局，就像普通的web一樣。像GWT-ext或ExtGWT這樣的圖書館可以提供一些幫助，因爲它們具有令人驚歎的「開箱即用」外觀，但價格較高（適用於您應用的尺寸）。
如果您希望將GWT與非Java後端（如ROR，PHP等）集成在一起，那麼您應該記住GWT 1.5現在支持JavaScript Overlay類型。利用此功能，您可以編寫可以映射到本機JavaScript對象頂部的類，以輕鬆爲這些對象的屬性和其他擴展功能提供訪問器方法。
請參閱此鏈接瞭解詳情： JavaScript Overlay Types
所以，你可以從你的後端返回JSON編碼的數據通過AJAX調用，它解析爲JavaScript對象，然後通過自己的GWT的Java代碼使用覆蓋訪問數據你創建的類。或者，當您渲染頁面時，您可以將靜態配置數據呈現爲JavaScript對象，並通過此機制讀取它，而不必執行AJAX調用來獲取數據。
我最近寫了一些關於the disadvantages of GWT的一些。主要缺點是：對應用程序的某些部分進行更改的部署週期較長，學習曲線相當陡峭。作爲經驗豐富的Java程序員，第二個應該不是什麼問題，如果使用單獨的後端，第一個也會減輕（因爲當您更改應用程序的「服務器」部分時，主要需要完成重新部署）。
GWT是一個很好的框架，有很大的潛力。請記住，它仍然是相當新的，但。有一些未解決的錯誤可能會讓你感到困擾，並且他們通常需要醜陋的解決方法才能過去。這個社區很棒，但你可能遲早會遇到一些Google無法回答的問題。
但是，嘿，我說去吧。 GWT的潛力非常棒，我敢打賭，未來將是光明的。
你應該使用GWT來創建一個新項目（在舊項目中使用它也很容易）。
我的經驗是學習和使用非常快。編譯後的JavaScript代碼比你手動編寫的任何東西都要好得多，而且它的工作速度也很快。
另一個好處是可以調試你的代碼（這是地獄單獨的JavaScript）
這個博客有許多經驗豐富的GWT的用戶輸入，有一些很棒的討論點的能力。我個人對各種UI框架有豐富的經驗。我會補充我的兩分錢。讓我們看一下根本優勢和GWT
基本優勢
GWT需要在網絡層編程JAVA的缺點。所以，Java的明顯優勢開始發揮作用。它將提供面向對象的編程。它還會提供很好的調試和編譯時間檢查。由於它生成HTML和Javascript，因此它也能夠隱藏其生成器中的一些複雜性。
主要缺點
缺點來自相同的語句開始。 GWT將Web層編程轉換爲JAVA。如果你知道JAVA，那麼你可能永遠不會選擇另一種語言來編寫你的業務邏輯。這是自給自足的，很棒。但是當涉及到爲JAVA應用程序編寫配置時。我們使用屬性文件，數據庫，XML等。我們從不將配置存儲在JAVA類文件中。想一想，那是爲什麼？
這是因爲配置是一個靜態數據。它通常需要層次結構。它應該是可讀的。它從不需要編譯。它不需要JAVA編程語言的知識。總之，這是一個不同的球賽。現在的問題是，它與我們的討論有何關係？
現在，讓我們考慮一個網頁。你認爲當我們寫網頁時，我們寫了一個業務邏輯？絕對不。網頁只是一個配置。它是分層容器和字段的配置。我們需要爲將從網頁捕獲並顯示的數據編寫業務邏輯，而不是創建網頁本身。
上一段做了非常強烈的陳述。這將解釋爲什麼基於HTML和XML的網頁仍然是最受歡迎的網頁。 XML是編寫配置的最佳業務。框架必須允許將網頁與業務邏輯（MVC框架的目標）清晰分離。通過這樣做，網頁設計師將能夠運用他的可視化和藝術技能，通過配置XML來創建精美的網頁，而不用擔心編程語言的錯綜複雜。開發人員將能夠在商業JAVA中使用他們最好的商業邏輯。
最後，讓我們直接討論其影響。 GWT打破了這個原則，所以它必然會失敗。開發GWT應用程序的成本會非常高，因爲您需要multiskill程序員來編寫網頁。所需的外觀和感覺將很難實現。由於不必要的編譯，修改網頁的轉身時間將非常高。最後，由於您正在使用JAVA編寫網頁，因此使用業務邏輯很容易破壞它。不知不覺中，你會引入必須避免的複雜性。
我們的團隊最近問了同樣的問題，並且我們選擇使用GWT，特別是因爲設計者插件使得GWT更容易被團隊中的非Java專家使用。無論誰做出這個選擇，只要注意你不要使用GWT Designer插件！它沒有被更新（至少在一年內，顯然）創建一個與IE8兼容的GWT應用程序。
我們的團隊幾乎完成了我們的應用程序佈局，這些佈局在Chrome，FF和Safari中完美運行。然後他們在IE中爆發。 IE 7將加載部分頁面（但不包括複合包含），IE8甚至無法加載應用程序。它只是掛起來。
設計器插件具有按鈕，允許用戶添加與IE不兼容的CellTable小部件（CellTable，DeckPanel，水平面板，垂直面板等）。當佈局必須在沒有設計人員協助的情況下用java重新完成時，這些會造成很大的痛苦。
有經驗的GWT用戶喜歡它，但設計者插件會殺了你。
這不是以破碎的英語來哄騙你的技術的地方 – Yarin 2010-06-20 12:27:24