Google Web Toolkit對開發復雜的javascripts有用嗎？

Question

我非常喜歡javascript框架，特別是jQuery。我一直想設計像“plurk.com”這樣的網站，但我知道它需要非常龐大的javascript.so關閉我。但是因為我來了解GWT，我我真的想測試它，並想問你是否使我們的工作比使用javascript或其框架更容易開發復雜的東西。你更喜歡哪一個？

Answer 1

我認為這個問題的一些答案是非常不明智的，我懷疑回答他們的人從未在大型項目中使用過GWT。 是的GWT是一個很好的方式來做大型AJAX網站，對於大型復雜網站，也包括后端，它在公園上下踢JQuery之類的東西。 我一直看待它的方式是它自己的javascript非常適合做小客戶端的事情。 當你需要做一些更復雜的事情（比如動態字段，彈出窗口，動畫）時，你會帶來像JQuery或Prototype這樣的東西。 如果你想更進一步，你可以選擇GWT。

人們認為，因為你用Java編寫它，它是專為后端開發人員進行前端開發而設計的。 不是。 Java只是他們選擇的語言，主要是因為它被廣泛使用，靜態類型，並且有很多優秀的編輯器。

我也不購買漏洞抽象理論，它不會試圖完全抽象出HTML元素，因為它可以讓你直接訪問本機javascript和DOM，如果你選擇使用它們。

簡而言之，我們在GWT中構建了非常復雜的站點（其中一個在GWT博客上有特色），並且還使用了其他庫，如JQuery。 我完全可以告訴你，一旦你了解了GWT，它就會殺死那些因復雜任務而死的其他框架。 它還有一些很棒的內置功能，有助於使事情變得更好，甚至可以做一些其他框架不支持的東西（比如它可以用圖像做的魔術）。 有關詳細信息，請參閱此博客文章：

http://googlewebtoolkit.blogspot.com/2007/10/epo-builder-built-with-gwt.html

Answer 2

很少有東西像“生成的Javascript”一樣嚇唬我。 在這些情況下，“漏洞抽象法則”必須更加真實。

編寫有效的跨瀏覽器javascript是一個持續改進的棘手過程。 試圖破譯一些生成的，模糊的Javascript出錯的地方是一個令人頭疼的問題。 修復純JS庫中的錯誤已經夠糟糕了。

對我來說，GWT是一個旨在允許后端開發人員編寫前端瀏覽器代碼的技巧。 不幸的是，現代網絡應用程序的現實意味着你只需要知道Javascript和DOM。 有些東西會破裂，你需要知道原因。

我認為你最好選擇一個像jquery或原型這樣的好的javascript庫，並且學得很好。 這些庫抽象出那些應該被抽象掉的東西，並且不太可能在邊緣情況下破解，比如數組操作和AJAX請求。

Answer 3

是的，確實如此，因為你將使用Java而不是Javascript。

卓越的IDE，靜態代碼分析，搜索和重構 - 所有這些都將使您在大型項目上的生活更加輕松。

Answer 4

不，它沒有。

它不會消除復雜性，它只是使您可以從Java Perspective處理它。 因為它為您提供了Java提供的所有工具......僅此一點就可以使它變得有價值。

JavaScript IDE越來越好了，通常如果你使用像jQuery或Prototype這樣的框架，那么你可能會發現它比處理像GWT這樣的重量級抽象層更容易。

我個人的偏好是采用純JavaScript方法，但那是因為我喜歡能夠更接近金屬工作，而且我有足夠的紀律來馴服我的JavaScript貓。

Answer 5

使用GWT，你實際上並沒有編寫JavaScript; 它的全部價值主張是你可以編寫Java，它將為你編譯成JavaScript。

Answer 6

我正在研究一個使用GWT效果非常好的項目。 這對我們來說是一個不錯的選擇，因為我們都是主要從事內部工具的Java開發人員。 我不能說它對大型最終用戶網站有多大用處。

我特別欣賞的一個優點是無縫對象序列化和反序列化。 XML-RPC的細節不僅被抽象出來，而且由於相同的Java代碼被編譯為服務器的字節代碼和瀏覽器的javascript，因此您可以編寫代碼，就好像服務器和客戶端在單獨的類加載器中運行一樣相同的JVM。 例如，您可以在服務器上構造Java對象，將其作為RPC服務調用的返回值發送到瀏覽器，然后瀏覽器代碼可以使用相同的Java類來操作剛剛返回的對象。 同樣，RPC調用的參數可以構造為Java對象，服務器在另一端接收相同的Java對象。 所有這一切都沒有在（de）序列化的細節。