Why GWT? Advantages and Trade-Offs of Using This RIA Framework [closed]

Question

I've been reading through a bunch of the "highest voted" questions for GWT. Several of these questions talk about the pitfalls or problems with GWT.

In the articles: Which Javascript framework (jQuery vs Dojo vs … )? and Biggest GWT Pitfalls?, some posters seem to suggest that GWT is not lightweight enough or that there are better alternatives that may be used.

Do most of you feel that there are problems with GWT that have not been fixed with GWT 2.0 -- which would make you inclined to suggest using a simpler framework for a new project?

To some extent, shouldn't GWT be somewhat future-proof (since you don't have to worry about it changing drastically from release to release and since it is backed by Google)?

I realize that the answer to this question depends greatly upon what you want to do or what you wish to make. I am looking at this from the perspective of starting a new web application that will eventually be used by millions of users.

Jezabel

I'll add #524228, reddit.com/r/programming/comments/aqsxq/… and cforcoding.com/2009/10/lost-in-translation-or-why-gwt-isnt.html – Vaso

Answer 1

Trade-offs

Let's start with all the trade-offs I can come up with:

• you're using Java - it means that your webdevs' proficiency in javascript won't come in handy as much (it will be helpful if you dabble in JSNI)
• problems with indexing by search engines - IMHO, this should be the biggest disadvantage of using GWT, or pure JS web applications in general. Since the content, layout, everything is created "on-the-fly" with JS, the search engine will only see a very short HTML page and that's that - you have to take care of this somehow yourself (for example, using cloaking). Google has finally started to work on a solution for this, however it doesn't seem to attractive to me.
  Update: Google has finally addressed this problem. However, I'll leave this as a trade-off because making the application crawable still requires more effort than in other frameworks. At least now we have a "standard" to follow and don't have to use some dubious techniques (like cloaking).
• it's easy (especially for a beginner in GWT, especially when that person comes from a HTML/JS background - without too much object-oriented experience) to go all "wow, these 'object' things are so cool, let me make all my <div>s into separate objects, that will make the code all nice and neat". Of course, I'm over-exaggerating it, but you get the point - it's easy to imagine that an unexperienced programmer could put a full-blown Widget with lots of Handlers in every cell of a FlexTable... And then (s)he'll waste a lot of time wondering why the application feels sluggish ;) tl;dr: it's easy for beginners in GWT to make their applications "bloaty" by writing code that seems in line with what the documentation/samples/common sense ;) suggest

That's all for the trade-offs I can think of - if anyone wants to add something, please add comments.

Advantages

Now for the advantages. I'm gonna skip some like internationalization, cross-browser compatibility for free, easy integration with other Google's libraries, etc, because they are kinda obvious and easy to grasp. I'll try to focus on the less emphasized but still very important features:

• the compiler - now, most people I've talked with about GWT doesn't realize just how amazing this part of GWT is - for starters try this presentation from last year's Google IO. The compiler has the view of the whole application.

So it can optimize such a something like this:

public class ShapeExample implements EntryPoint {
  private static final double SIDE_LEN_SMALL = 2;
  private final Shape shape = new SmallSquare();
  public static abstract class Shape {
    public abstract double getArea();
  }
  public static abstract class Square extends Shape {
    public double getArea() { return getSideLength() * getSideLength(); }
    public abstract double getSideLength();
  }
  public static class SmallSquare extends Square {
    public double getSideLength() { return SIDE_LEN_SMALL; }
  }
  public void onModuleLoad() {
    Shape shape = getShape();
    Window.alert("Area is " + shape.getArea());
  }
  private Shape getShape() { return shape; }
}

..to this:

public class ShapeExample implements EntryPoint {
  public void onModuleLoad() {
    Window.alert("Area is 4.0");
  }
}

And then obfuscate this and minimize. Additionally, this is done in such way, that makes the resulting files more compressible via gzip.

• you're using Java - whether or not you like Java, there's no denying that it's a very good object-oriented language, that allows to write easy to maintain and testable code (something I don't think is possible to such extent with JavaScript). If you follow some good guidelines, you'll arrive at a code that is understandable not only for you, but for other developers as well. Another thing worth mentioning is that all those nice design patterns, etc, that work in "pure" Java, work here too.
• one nifty thing about GWT is that you get performance gains and new features for free with almost every new release of the framework. Since it's Java compiled to JavaScript, it takes only a recompile to benefit from the optimizations made in the new compiler or get new features (like the accessibility support introduced in GWT 1.5).
• debugging - it is worth mentioning that you can (and should :)) debug your GWT apps just like any other Java application, using your IDE's debugger. And, in general, the Java debuggers I've seen are more advanced then their JavaScript counterparts.
• UiBinder - while it's still not "perfect", UiBinder let's you design your Widgets in an easy and intuitive way using XML (as opposed to the pre-2.0 way that forced you to do this in Java). Mixing HTML and GWT's Widgets has never been so easy and fun ;)
• working with CSS - GWT has always, of course, embraced CSS, but with the introduction of GWT 2.0 (and UiBinder) they took it to another level. Let's look at a CSS file from a "normal" web application - hundreds, if not thousands of lines, hard to navigate, some styles are redundant but it's hard to notice that, some aren't used at all, add to this mix the need to please IE6/7 and you get yourself a nightmare. With GWT, you can instruct it to perform the similar tasks it did for the JS code for CSS - so it will prune all the unused CSS styles, merge where appropriate, minimize and obfuscate the class names, and many more (including conditionals, constants, etc in your CSS files). You are encouraged to keep your styles in their respective UiBinder's XML files - makes organizing and finding them so much easier. Last but not least, you get an error when you misspell a CSS style name - less hassle then trying to do the same via Firebug or a similar tool
• OOPHM - Out of Process Hosted Mode, with this, they fixed one of the biggest disadvantages of GWT - now, you get to use Hosted Mode in the browser of your choice (if that choice is Firefox, Safari, IE or Chrome, but at least you can use any version you want). The design of OOPHM also allows you to do cool stuff like run Windows in a VM, and connect from the IE there to the Hosted Mode running on the host OS (Linux/MacOS) - no need for hacks, copying files after every compile, etc
• you get to say /ˈɡwɪt/ a lot ;) (this is a quote from one of the presentations on Google IO 2009, IIRC)
• many more.. Take a look at the videos from Google IO 2009 and browse through the GWT wiki to see more stuff that makes creating RIA easier and less error-prone with GWT :)

In between

Depending on your experience and/or preferences, the following might be an advantage (it is to me, but at times it's a PITA ;)) or not:

• the out-of-box collection of Widgets is kept small and simple. Now, if you're coming from some full-blown GUI framework (be it web or desktop), you might be surprised at how relatively small the number of Widgets GWT has. But according to the GWT's devs, it's kept like this on purpose - the basic Widgets are all the tools/"blocks" you need to build your own, customized to your needs Widgets. The alternative is to provide a variety of all-purpose Widgets that have to support many use-cases... The result is a kinda sluggish UI (at least IMHO - check out for yourself projects like SmartGWT or Ext GWT). That is to say, the GWT Widgets are quite nicely written - for example the SuggestBox has a lot places where you can override the default behavior with your own - you can specify a different way to display the suggestions (SuggestBox.SuggestionDisplay), fire a custom action when the user selects a suggestion (SuggestBox.SuggestionCallback) or just provide a custom SuggestOracle for feeding the SuggestBox with Suggestions...

---

Bottom line is - try GWT, chances are you'll love it and will never want to write in pure JavaScript ever again ;)

Gazpacho

More info on making AJAX apps crawlable: code.google.com/web/ajaxcrawling/docs/faq.html – Interjacent

Thanks, Matt, for reminding me of that - I've updated the post :) – Gazpacho

I'm not sure that indexing an application's screen is relevant. – Clerkly

@Christopher: depends on what your application is/does - if it's an ebook reader, like Google Books, then yes, it's very important. If it's an e-mail reader, then definitely no ;) – Gazpacho

Answer 2

We are building small (~2K Java classes) to medium (~6K) enterprise systems on regular basis using GWT since version 1.3 was out. I understand that there is a different set of problems to solve in public site having thousand clicks per second, but I will try to tell about our biggest problems in GWT 1.x and how GWT 2.0 approaches that.

Browser Memory Leaks IE6 leaks with GWT are tremendous, IE7 leaks can be compensated with periodic page refreshes, IE8 promises some stability in this area, but not yet widely accepted in enterprise. And yes, even valid GWT code without native JS calls leaks memory in certain cases. Especially when UI is complex and you are doing a lot of Panel.clear() calls. There are no useful tools to identify the real cause of the leak at the moment. Unless you know how to hack into browser itself.

Rendering Performance you have to write your UI code very carefully, especially when building commonly used custom widgets. Deep JavaScript, CSS and DOM knowledge is still required. There is a lot of materials in internet on this topic. You need to know how and when to get down from GWT widget level to direct DOM manipulations.

Size of Downloadable Content it was impossible prior to 2.0 to split module onto different downloadable pieces without having "hard" navigation built in the application. But that will clear JavaScript context and require window reload.

UI Developers Mind Shift Experienced UI developers just don't know Java and OOP. Experienced Java developers don't know CSS,JS,HTML and don't like building UI. UI Binder goes into right direction.

We have done migration 1.3 -> 1.5 -> 1.7 and it was always just a recompile and a couple of CSS fixes. GWT 2.0 removes a lot of deprecated code and initial approaches (project structure, GWTShell) and may be tricky to migrate quickly. But all features looks promising and its good that Google have dropped legacy code at some point. I am not sure about the stability of 2.0 though, as we have not used it yet in real projects.

Hope this helps.

Erwinery

Answer 3

We have a GWT app with a bunch of Selenium acceptance tests. I thought (like you) that it would surely be safe to upgrade GWT from 1.7 to 2.0. And it was - mostly. The app still worked the same for "human" users, but the selenium tests all broke. There's a newer version of Selenium in preparation (at alpha release, with many UnsupportedOperations), but if we want to stay with GWT 2, it seems we have to give up some testability. So be careful about "future-proof" assumptions.

Our decision to use GWT was made months ago, after comparing YUI and ZK. I'm still glad we chose GWT. The level of support on the GWT website and the general quality of the documentation seems very high.

GWT does module splitting and provides performance profiling which help to counter arguments that it is not lightweight enough.

Picture