GWT仍然適用於新項目嗎？

Question

問題為什么我應該使用jQuery而不是GWT？ 可能已經過時（作為答案）。 和大多數 的 的其他SO相關問題，也可能是當今過時。 所以，讓我們更新最先進的約GWT相關的新項目。

GWT現在更加成熟

自2009年問答以來，GWT已經發展，一些JS框架可以用Java：

• GQueryQuery for jQuery（gQuery）
• ExtJS的GXT （前ExtGWT）
• Smart GWT取代了GWT-ext
• ......當然還有更多...（請隨意附上）

甚至更多，Java代碼可以轉換為獨立的JS庫： gwt-exporter

但是低級JS框架可能就足夠了

但是我閱讀的內容越來越多，我看到Web開發人員建議他們退回GWT並直接使用JS框架（ Firebug ，JS框架的IDE插件......）。

生產率

但是，我喜歡使用相同的IDE（Eclipse，Netbeans，IntelliJ IDEA ......）進行開發和調試的想法。 我想我會更有成效......我也應該考慮文檔和社區（論壇反應性，這個SO問題）......

問題

1. 對於什么樣的新2014項目GWT應該（或不考慮）？
2. 是否有相關的 GWT替代方案可以輕松實現AJAX Web應用程序的開發和部署？
3. 目前的模式和趨勢是什么？

我的具體情況

我剛剛完成了基於Python3（ http.server.HTTPServer ）調用（POST） bash腳本（在C ++中進行一些處理）和檢索JSON數據的POC（內聯網Web應用程序）。 網頁中的一些JS（無框架）用於渲染。 所以我想知道下一次迭代的最佳選擇。

但是也請回答關於其他案件的這個問題。 我希望一般性問題/答案對更多人有用。

---

2015年10月更新

GWT看起來不太活躍，因為自11個月以來沒有新發布。 但是在版本2.4和2.5之間的過去直到13個月 。 Git repo鏡子仍然非常活躍。 此外，GWT是可擴展的，並且新功能可以來自GWT庫而無需新的GWT框架發布。 例如，參見最常見的移動GWT庫以及相應的發布周期。 與此同時，趨勢是在任何地方使用Node.js！ 新項目采用GWT實際上取決於開發人員的技能/動力和項目生命周期（周轉/培訓/維護）。 還可以考慮其他一些標准，如重用可用的源代碼和上市時間......請參閱下面的優秀答案。

Answer 1

對於第1點，我可以給你一些我會使用的標准：

使用基於JavaScript的框架時，通常在初始創建代碼時非常快。 根據我的經驗，在維護（錯誤修復，新功能，重構）方面你要慢得多，因為工具支持不如靜態類型語言那么好。 因此，對於更大或更長時間運行的項目，我總是會選擇GWT，因為Java和它的編譯器檢查/生態系統/工具。 我認為隨着時間的推移，您將受益於更高的效率和擴展，因為動態類型不會出現奇怪的問題。 對於不會長壽或不需要大量重構的小型項目，JavaScript框架可以大大提高開發速度。

在目標平台的上下文中調試需求也是我的標准。 調試GWT代碼非常好，只要您擁有DevMode支持的瀏覽器或至少可以與基於SuperDevMode的新源映射一起使用。 例如，不支持MacOS X上的Safari。 對於移動設備，您可以在Android Chrome上遠程調試JavaScript，但據我所知，這對GWT來說是不可能的。

我的另一個標准是球隊規模和離職率。 基於Java的工具（IDE，代碼質量檢查器......）可以幫助開發人員，尤其是新開發人員瀏覽其他開發人員的代碼。 對於其他靜態類型語言也是如此，但是您要求使用GWT / Java。

下一個是堆棧問題...如果在服務器端使用servlet容器，GWT可以輕松解決客戶端和遠程通信部分。 將它與成熟的Java企業技術（JPA，EJB，Spring框架......）結合起來也很容易。 如果您需要/想要擁有堆棧，這是一個很大的優勢。 如果您要在服務器端使用沒有JVM的多語言（如上所述），那么這個不適合您。

當然，GWT和JavaScript框架都有更多標准。

最大的問題是偏好。 JavaScript有非常好的概念（例如Closures），但由於它是動態類型，因此也是一種風險。 你更傾向哪個？

關於第2點：

我不確定是否有一個真正的替代GWT提供類似的功能和工具。 大多數其他框架只關注一個方面（小部件，優化，數據綁定，遠程通信，瀏覽器支持，I18n，...）。 這並不意味着，其他框架都很糟糕，但您通常需要不同框架的組合來獲得GWT提供的功能。

關於第3點：

• 我肯定會看看TypeScript，因為它改進了與JavaScript的打字和互操作性
• 據我記憶，Dart也有類似的目標
• 常青樹是JQuery，但依賴於你的需求有很好的選擇。 但這是非常主觀的
• 對於小部件，Twitter Bootstrap（ http://getbootstrap.com/ ）很好，如果它的方式對你來說沒問題。 甚至還有它的GWT版本（ http://gwtbootstrap.github.io/ ）

Answer 2

Steffen的答案很棒。 我開始輸入它作為對他的評論，但發現我輸入的內容超出了我的預期，因此將其作為一個單獨的答案。 不尋找分數......

我只想添加1個主觀點。 現實情況是，大多數開發人員都是所謂的后端開發人員，他們沒有任何知識，經驗，最重要的是希望開發Web前端。 美國IT市場的現實是，大多數人更喜歡Java的簡歷，而不是JS，PHP，Python和其他外來語言。 原因是補償。 Java開發人員平均得到更多報酬。 不確定其他國家。

因此，公司中的大多數開發人員都是Java開發人員（或.NET，這不在此對話中）。 為了使它們在UI上工作，您必須使用Java兼容技術，即JSP或GWT。 JSP需要學習JS庫以使前端或多或少具有可呈現性。

顯然，如果你想用獨特的UI打動公眾，你必須使用JS庫來實現更大的自定義。 JSP和GWT都可以工作，因為大部分工作都將在JS中完成。 正如我上面提到的，很少有公司會在員工中體驗JS開發人員。

大多數申請雖然是為內部使用而寫的，不是面向公眾的。 根據您的描述，您的用例可能屬於此類別。

內部非公開工具通常具有比公共網站更復雜的功能，但只要功能存在且便於內部使用，它們的設計要求就更加寬松。

在這種情況下，您可以使用GWT，這對於Java開發人員而言比jQuery和具有標准主題的高級庫（如GXT）更少。

GWT with GXT對我們來說是一種簡單快捷的方法來創建一組內部應用程序。 有了我們公司的Java開發團隊，我們永遠不會在同一時期內接近項目的質量甚至完整性。

Answer 3

快進到：GWTs示例頁面， 展示GWT應用程序的真實世界示例

只需閱讀這些例子的超重量特性。

GWT本身並不輕，我懷疑它是為了創建一個日期選擇器而設計的。 GWT也是完全不同於jQuery的東西。 它可能更像JSF2而不是jQuery。 問題“我應該使用GWT還是jQuery”可以回答如下：

如果你想在這里和那里添加datepickers，一些效果，一個可排序表，一個自動完成。 你可能應該使用jQuery。

如果你想弄清楚是否要使用GWT作為前端模板/引擎機制，你應該考慮其他實際可比較的。 在討論java時，可能JSF2是你唯一的選擇。 而且JSF的學習曲線很陡峭。

我正在深入挖掘，我找到了一個悲傷的帖子：

http://polygoncell.blogspot.mx/2013/07/gwt-for-new-project-no-thanks.html

我來到這個頁面是因為我正在閱讀即將推出的項目，如AngularJS，Backbone，單頁面應用程序（SPA）：簡而言之，谷歌放棄了GWT。 GWT現在是開源的，因為他們剛剛放棄了它。 現在AngularJS得到谷歌的大力推動。

編輯我們親愛的安德魯告訴我“證明我的觀點”

這是用於評估技術是否具有競爭力的算法。

1）轉到您最喜歡的工作現場

2）搜索{感興趣的技術}工作

3）檢查開口數量，相關技術要求等

4）對競爭技術重復＃2和＃3

5）評估

今天是2016年5月19日，我正在尋找GWT工作。

工作：23。

我搜索了angularjs工作。

喬布斯：1338。那是對的。 一千三百三十八

點證明？

Answer 4

我想回答第1點，你必須看看你目前的情況以及你的目標是什么。

如果你有一個開發人員團隊，他們大部分時間都在使用Java，那么你可能希望他們有6個月的時間來學習JavaScript的范例。 如果有Groovy或Clojure等語言的經驗，你可能會把時間縮短一些。 所以，如果你不期望這個項目持續超過一年左右，那么GWT可能就是你要走的路。

相反，如果你有一個JS開發團隊，他們可能會發現靜態打字系統相當令人沮喪，並且學習有效地使用它可能需要半年時間。 因此，如果是這種情況，那么您可能不希望將GWT用於任何學習曲線超過生產率的新項目。

我不確定第2點在問什么。 如果你問整個堆棧框架，我猜你可以找到一些使用nodejs的東西，雖然我認為我沒有足夠的經驗來建議。

在第3點，我工作的地方，我們似乎正在轉向使用JS框架（特別是AngularJS）和一些用Python和Groovy編寫的（新）服務器/服務，遺留系統仍然使用Java。 我們還有幾個用Clojure編寫的服務。

Answer 5

GWT是相關的。 它有130,000名開發人員使用它。 如果你不相信我只看[GWT將在2015年重新開始] [blog.xam.de/2014/02/gwt-is-coming-back-in-2015.html]和另一個stackexchange問​​題談到這一點。 GWT不應該是你的第一選擇因為它增加了很多復雜性。

GWT對哪些項目有益？ GWT要復雜得多 ：

• Java是一種難以編寫錯誤代碼的語言
• 編譯為javaScript會增加復雜性
• GWT是為極其復雜的Web應用程序而構建的
• 與javaScript社區相比，GWT社區傾向於優先考慮用戶體驗和性能而不是開發人員體驗

但是， 它是更清潔，更易維護的代碼，它是java，它更快，如果你使用J2ObjC，你可以在jvm和ios上重用你的代碼

有一些非常令人信服的理由使用GWT - Java
- 從其他平台重用您自己的代碼。 例如，谷歌收件箱使用GWT在網絡上重用大部分的Android代碼，並在iPhone（感謝J2ObjC）和服務器上再次使用它的代碼（感謝JVM能夠在許多不同的平台上運行）。 - 使用java庫和工具，java開發人員 - 許多開發人員更喜歡java到js並且有充分理由喜歡它 - 從頭開始​​構建復雜，高性能的Web應用程序。 - Java代碼更清晰，更易於維護

根據谷歌的趨勢和工作趨勢， GWT一直在下滑，但javaScript和jQuery也在下降。 我不知道為什么這些技術都會崩潰。 我的理論是，有很多新的框架正在從GWT和javaScript中竊取開發人員。 我認為這並不一定意味着javaScript和GWT即將死亡。 這只不過是競爭激烈的結果。