gwt格式

我喜歡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創建的事實，則可以輕松地使成熟的程序員哭泣。 隨著UI綁定程序從2.0版開始的引入，該問題已得到解決，但是現在您需要學習一種新的語法。

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）相比，您通常需要花三倍到五倍的代碼才能完成簡單的工作

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

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

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

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

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

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

gwt格式

總結

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

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