55

I'm considering use of GWT on a major in-house web app development project, namely it's major advantage in my eyes is the cross-compilation to Javascript which would (at least theoretically) help my team reduce the size of tech stack by one.

However, having been burnt before (like most devs), I would like to hear from programmers who did actually use it on any problems with GWT which would hamper, or limit, it's use within a certain problem domain.

What are the arguments against using GWT, and why?

Improve this question
11
  • 11
    I thought GWT died.
    – Aaron McIver
    Commented Jan 20, 2011 at 17:54
  • 1
    @Aaron, really?
    – Jas
    Commented Jan 20, 2011 at 17:55
  • 10
    I don't recommend GWT personally. The mindset it forces you into works for desktop applications, but will give you problems trying to think that way in HTML functions. I'm a fan of matching the coding paradigm to the problem at hand, and the abstraction gets in my way. Which is why every time I started evaluating it, I decided not to use it.
    – Berin Loritsch
    Commented Jan 20, 2011 at 18:12
  • 2
    @Jas Experience was couple years back; in it's infancy and it felt very raw at the time. Has it changed? Perhaps....but I am slowly attempting to learn the underpinnings of frameworks instead of relying on the frameworks themselves. At the end of the day it is a meat grinder for churning out JS; not that it is a bad thing but not somewhere I want to put my effort. Many of these frameworks are chosen due to lack of technology X knowledge or something thereof...but you will eventually need to become knowledgeable in technology X at some point in time....might as well go that route first.
    – Aaron McIver
    Commented Jan 20, 2011 at 18:29
  • 10
    I am very knowledgeable in JS, wrote some pretty serious stuff there, however I am now running a very time-critical project and I cannot afford to have junior staff waste time because of errors induced by context-switching from say Java to JS. So please, if you have some real world example of why GWT did not work for you, then please describe it, otherwise let's not waste each other's time with hypothetical and highly subjective-colored discussions.
    – Jas
    Commented Jan 20, 2011 at 18:33

2 Answers 2

Reset to default
85

I am both good and bad to answer this question - good, in that I've actually used it before, and bad, in that I was quite experienced with HTML/CSS/JavaScript prior to working with GWT. This left me maddened by using GWT in a way that other Java developers who don't really know DHTML may not have been.

GWT does what it says - it abstracts JavaScript and to some degree HTML into Java. To many developers, this sounds brilliant. However, we know, as Jeff Atwood puts it, all abstractions are failed abstractions (worth a read if considering GWT). With GWT, this specifically introduces the following problems:

Using HTML in GWT sucks.

As I said it, to some degree, even abstracts away HTML. It sounds good to a Java developer. But it's not. HTML is a document markup format. If you wanted to create Java objects to define a document, you would not use document markup elements. It is maddeningly verbose. It is also not controlled enough. In HTML there is essentially one way to write <p>Hello how are <b>you</b>?</p>. In GWT, you have 3 child nodes (text, B, text) attached to a P node. You can either create the P first, or create the child nodes first. One of the child nodes might be the return result of a function. After a few months of development with many developers, trying to decipher what your HTML document looks like by tracing your GWT code is a headache-inducing process.

In the end, the team decided that maybe using HTMLPanel for all HTML was the right way to go. Now, you've lost many of GWT's advantages of having elements readily available to Java code to bind easily for data.

Using CSS in GWT sucks.

By attachment to HTML abstraction, this means that the way you have to use CSS is also different. It might have improved since I last used GWT (about 9 months ago), but at the time, CSS support was a mess. Because of the way GWT makes you create HTML, you often have levels of nodes that you didn't know were injected (any CSS dev knows how this can dramatically affect rendering). There were too many ways to embed or link CSS, resulting in a confusing mess of namespaces. On top of that you had the sprite support, which again sounds nice, but actually mutated your CSS and we had problems with it writing properties which we then had to explicitly overwrite later, or in some cases, thwarted our attempts to match our hand-coded CSS and having to just redesign it in ways that GWT didn't screw it up.

Union of problems, intersection of benefits

Any languages is going to have it's own set of problems and benefits. Whether you use it is a weighted formula based on those. When you have an abstraction, what you get is a union of all the problems, and an intersection of the benefits. JavaScript has it's problems, and is commonly derided among server-side engineers, but it also has quite a few features that are helpful for rapid web development. Think closures, syntax shorthand, ad-hoc objects, all of the stuff done by Jquery (like DOM querying by CSS selector). Now forget about using it in GWT!

Separation of concerns

We all know that as the size of a project grows, having good separation of concerns is critical. One of the most important is the separation between display and processing. GWT made this really hard. Probably not impossible, but the team I was on never came up with a good solution, and even when we thought we had, we always had one leaking into the other.

Desktop != Web

As @Berin Loritsch posted in the comments, the model or mindset GWT is built for is living applications, where a program has a living display tightly coupled with a processing engine. This sounds good because that's what so many feel the web is lacking. But there are two problems: A) The web is built on HTTP and this is inherently different. As I mentioned above, the technologies built on HTTP - HTML, CSS, even resource-loading and caching (images, etc.), have been built for that platform. B) Java developers who have been working on the web do not easily switch to this desktop-application mindset. Architecture in this world is an entirely different discipline. Flex developers would probably be more suited to GWT than Java web developers.

In conclusion...

GWT is capable of producing quick-and-dirty AJAX applications quite easily using just Java. If quick-and-dirty doesn't sound like what you want, don't use it. The company I was working for was a company that cared a lot about the end product, and it's sense of polish, both visual and interactive, to the user. For us front-end developers, this meant that we needed to control HTML, CSS, and JavaScript in ways that made using GWT like trying to play the piano with boxing gloves on.

Improve this answer
8
  • 2
    I recognised some of the reasons we chose Wicket over GWT, hats off to the presentation.
    – biziclop
    Commented Jan 20, 2011 at 19:30
  • 12
    -1 for FUD, my experience with GWT used for small and large scale applications has been way more positive than negative. And I haven't encountered a single one of these "problems" thus the FUD comment. We successfully embed GWT generated widgets into very complex HTML pages with very little effort. If you know what you are doing it is wonderful, if you don't want to consider there might be a new better way of doing things then follow this "answer" and ignore this comment.
    – user7519
    Commented Nov 23, 2011 at 21:15
  • 10
    @Jarrod These are not "problems" to encounter, but plain descriptions of the nature of GWT. Where relevant, I further qualified them as being negatives specifically within the lens of our project's goals. If you have an alternate experience feel free to write it up. Until then, the only unproven information is your claim that GWT is "new and better". By the way - since I wrote this answer, the company (I no longer work for) threw out over a year of several engineers' work, and rewrote the project without GWT. In less time.
    – Nicole
    Commented Nov 23, 2011 at 21:41
  • 1
    @JarrodRoberson I agree with NickC, would be great to read an equally detailed write-up of your experiences.
    – funkybro
    Commented Aug 28, 2012 at 8:57
  • 8
    @NickC "In less time" for rewriting a project doesn't count as a huge blow to GWT IMO; any project where you're basically repeating what has been done before even in a different framework or language ought to take "less time".
    – funkybro
    Commented Aug 28, 2012 at 8:57
25

We use GWT for a big eGovernment web application (SOA in the backend) which has a heavy usage. The old UI was in DHTML but we had issues with browser compatibility, performance optimization and the development process, so we looked for alternatives.

Our requirements have been:

  • client side UI layer to minimize server load
  • browser compatibility
  • web based RIA
  • Easy performance optimizations
  • No client plugins installation necessary, should work with a plain windows installation

We choosed GWT and I never regret it. The new team had no or less DHMTL experience and therefore the Java dev process of GWT was very helpful. What you get of the box is:

  • browser compatibility
  • Java based development process and code reuse
  • easy minimizing of requests (image bundle, ...)
  • easy agressive caching (new apps are completely cached at client side)
  • easy compression of all ressources (even with js on older buggy IEs)
  • and a lot more, to much to mention here

Our application issues only one request to the server on startup. On the negative side is that GWT (and also Android) have a poor design out of the box, but anyway if you apply your own look and feel you have to adapt the CSS. Alternatively you can use various component libraries for GWT which make it easy to apply proper styles and theming.

For me there is no point that maybe the HTML DOM is not as good as handcrafted, this was never an issue. When I develop in C++, I do not look at the generated assembler code. When I develop in GWT there was never a reason for me to look at the JS code and only once a reason to look at the DOM and do some refactoring.

For me GWT is the only choice when it comes to RIA development and I hope that GWT has a bright future. See the mission statement at:

[1] http://code.google.com/intl/de-DE/webtoolkit/makinggwtbetter.html#introduction

But it should not be unmentioned that Google don't use GWT on many of their internal projects and that at the moment there are some rumors around about the future of GWT, see

[2] http://googlewebtoolkit.blogspot.com/2011/11/gwt-and-dart.html
[3] https://plus.google.com/105933370793992913359/posts/bLfSagtziBC

Improve this answer
0

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.