我喜歡JavaScript。 隨著jQuery和Mootools的出現，我對JavaScript的熱愛僅增加了很多倍。 只要有選擇，我就可以將上述框架中的任何一個用于我開發的任何Web應用程序。 但是進入服務行業后，我不得不一次次屈服于客戶的壓力，并在他們選擇技術的過程中努力-這是否是正確的選擇（ 向吹笛者付款的人叫the。不是嗎？ ）。 一位這樣的客戶使我了解了GWT的世界。

在發布GWT的那幾年，我給了他們幾槍。 那時我不那么喜歡它，所以我將其關閉，再也沒有回來。 但是，在過去六個月的時間里，我對該項目框架有一個稍微不同的印象。 我仍然不能說GWT是切成薄片后的下一件大事，但至少它沒有我想的那么糟糕。 我剛剛記錄了我在項目過程中的好與壞的觀察結果，并認為一些其他開發人員可能會在評估GWT時發現它有用。

優點：

如果您是Java的資深人士，并且具有Swing或AWT的經驗，那么選擇GWT應該是明智的選擇。 在這種背景下，學習曲線最少。

即使您沒有Java GUI開發方面的經驗，多年開發GWT應用程序的經驗也會對您有所幫助

您可以創建高響應性的Web應用程序，以減輕客戶端的負擔，并減少與服務器端的閑聊

盡管有很多JavaScript庫供人們參考，并且其中大多數都值得一試，但許多傳統開發人員并不了解它的真正功能。 請記住，像JavaScript這樣的強大語言是一把雙刃劍。 如果您不知道如何使用它，即使您將無法清理自己創建的混亂

您可以迭代地從典型的Web應用程序遷移到GWT應用程序。 這不是一個全有或全無的主張。 您可以使用一個名為JSNI的巧妙技巧與已經擁有JavaScript函數進行交互。 但是總是最好盡快將它們移至GWT

IDE對GWT的支持再好不過了。 Java IDE在過去十年中已經成熟，已成為世界上最好的IDE之一，GWT可以直接利用它

您可以殺死集成的調試美女。 成熟的Java IDE提供的出色的調試支持是一項功能，該功能可能會影響任何人的支持GWT的決定。

可以直接很好地利用內置的IDE重構Java代碼來始終保持簡單的設計。 用JavaScript進行此操作并非出于內心的虛弱

至少可以說，IDE語法突出顯示，錯誤檢查，代碼完成快捷方式等不勝枚舉。

Google正在積極開發GWT。 我們知道該項目不會很快消失。 到目前為止，他們對項目的承諾充分說明了該行業的未來。

該項目背后的社區也是一個巨大的優勢。 每天在Stack Overflow，討論論壇，Wiki和個人博客中進行討論。 使用正確的關鍵字進行簡單搜索可以為您指明正確的方向

GWT是一個經過深思熟慮的API； 而不是趕時間的東西。 這可以幫助您作為開發人員快速理解抽象并使其真正直觀地使用

您可以使用GWT的內置協議在客戶端和服務器之間傳輸數據，而無需任何其他有關如何打包和發送數據的知識。 如果您希望獲得更多控制權，則可以始終使用XML，JSON或您選擇的其他專有格式。 即使在那種情況下，在使用JSON時，您也不必使用非直觀的Java JSON庫。 您可以使用JSNI通過簡單的javascript“評估” JSON。 太酷了！

您具有可以使用標準Java靜態代碼分析器（例如FindBugs，CheckStyle，Detangler，PMD等）來監視代碼和設計質量的優點。 當您在經驗豐富的大團隊中工作時，這非常重要。

您可以使用JUnit或Test NG進行單元測試，可以使用JMock或另一個模擬庫來模擬依賴項。 如果您已經練習過，那么遵循TDD是很簡單的。 盡管有基于JavaScript的單元測試框架，例如jsunit和qunit，但還是告訴我有多少人已經知道或渴望使用它。

GWT編譯器生成跨瀏覽器JavaScript代碼。 今天，任何說這話的營銷人員都可能被擊敗。 現在，它已成為一種基本必需品，而不是奢侈品

GWT編譯器可以一口氣為您優化生成的代碼，刪除無效代碼，甚至為您混淆JavaScript

盡管編譯過程需要花費很多時間，但您在開發過程中不必經歷所有過程。 有一種特殊的托管模式，該模式使用瀏覽器插件并直接使用Java字節碼生成輸出。 這是您能夠使用Java調試器調試客戶端代碼的主要原因之一。

可以通過許多項目（例如Smart GWT，Ext GWT等）獲得豐富的第三方控件。它們設計精良，易于使用且具有主題性。 因此，如果您有一個需要不僅僅削減現有控件的要求，那么您應該研究這些項目之一。 這些組件之一很有可能實現。 即使無法解決問題，您也可以隨時推出自己的解決方案。

GWT強調有狀態客戶端和無狀態服務器的概念。 這將導致許多用戶必須共存的服務器上的負載極少，而只有一個用戶在工作的客戶端上的負載卻很高

I18N和L10N在GWT中非常簡單。 實際上，基于語言環境的編譯由GWT編譯器本身負責。 關于常規的僅客戶端框架不能說相同的話

GWT內置了瀏覽器后退按鈕支持，即使在使用AJAX時也是如此。 如果您是AJAX開發人員，那么您幾乎可以放心。 這是無價的。

缺點：

GWT是一個快速發展的項目。 因此，周圍有很多版本。 不贊成使用許多功能，界面和事件，而當您要做其他工作時，跟上它們的步伐并不會太有趣

一開始有很多關于GWT的書。 這些天沒那么多。 例如，我沒有找到關于GWT 2.0版的很多書。 這只剩下Google的文檔。 我同意所有文檔都是不錯的，但是沒有什么能比寫得好的書更好

使用GWT并不有趣。 畢竟是Java，而Java不是一種有趣的語言。 如果您添加了整個布局和自定義控件都應使用Java創建的事實，則可以輕松地使成熟的程序員哭泣。 通過從2.0版開始的UI綁定器的引入，該問題已得到解決，但是現在您需要學習一種新的語法。

Java到JavaScript的編譯速度相當慢，如果選擇GWT，這是一個很大的缺點。

我個人更喜歡在HTML中定義結構并使用CSS對其進行樣式設置。 HTML中使用的概念簡潔明了，而我對此有多年的經驗。 但是在GWT中，我被迫使用專有方法來執行相同的操作。 再加上GWT不能解決我不兼容的樣式和對齊問題，這使問題更加復雜。 因此，我很想在GWT中編寫布局代碼。 但是從2.0版開始，有了UI Binder和HTMLLayout，我感到自己回到了自己的領域

進入GWT需要花費一些認真的承諾，在此之后，更改客戶端技術可能需要完全重寫您的應用程序，因為這與其他客戶端框架完全不同

沒有使用GWT進行應用程序開發的明確方法。 我們應該每個應用僅使用一個模塊，還是每個頁面一個模塊或介于兩者之間的某個模塊。 這些設計模式直到現在才在緩慢發展。 因此，通常人們傾向于在一個模塊中全部開發，直到模塊大小超出可接受范圍，然后將其重構為多個模塊。 但是，如果為時已晚，那么重構也不會那么容易

盡管典型的桌面GUI應用程序僅能做到這一點，但是聽起來和代碼的混合聽起來并不正確。 但是如今，即使像Flex和Silverlight這樣的桌面應用程序框架也采用了基于XML的聲明性方法來將表示與邏輯分離。 我認為GWT 1.x版本具有此缺點。 從2.0版開始引入UI Binder，我認為可以克服這一缺點，盡管它是另一種痛苦的XML語言，

與其他客戶端庫（例如jQuery）相比，您通常需要花3倍至5倍的代碼才能完成簡單的工作

您還應該記住，使用GWT時，從HTML的抽象并不完整。 您仍然需要了解您的應用程序正在生成的DOM結構以便對其進行樣式設置，而GWT會使在代碼中更難看到此結構。

GWT僅對Java開發人員是一個優勢。 具有.NET或PHP背景的開發人員在這里一無所獲

如果您已經體驗過JavaScript的強大功能，并且知道如何正確利用JavaScript來發揮自己的優勢，那么您將對Java這樣的缺乏表達能力的語言感到沮喪

我相信你們中的許多人會有不同意見。 差異很好。 因此，如果您有其他想法，請隨時發表評論。 我們將討論...

參考： GWT –我們的JCG合作伙伴 Ganeshji Marwaha在Ganesh博客上的優缺點。

翻譯自: https://www.javacodegeeks.com/2012/01/gwt-pros-and-cons.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的GWT –利弊的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。