我喜歡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