GWT in review: 18+ months later
Dec 23, 2011       8:45 pm

I work for a primarily-web development organization. We adopted and made a near-full transition to ExtJS some 4 years ago. Around the end of 2009, while I was away from my employer for a semester or so before I was hired full-time, we started writing some of our new features with GWT. I mention that I was gone so I don't have to take any part of the blame for the decision, but it doesn't really matter. I was hesitant about it, but in the end I too signed on and believed that it would be a good idea in the long run. We've spent a long time talking about whether technology has actually been a beneficial addition to our stack. As 2011 draws to a close, my opinion is fully solidified.

When you adopt a language requiring a compilation step (such as C over a low-level assembler), you sacrifice build speed in hopes of getting some or all of the following returns: A language that's easier to write and comprehend, a layer of abstraction, better runtime speed, and static error checking. GWT gives you almost none of these things.

Java is harder to use and less expressive than JavaScript. Our student employees and I may just have to agree to disagree on this point. The availability of first-class functions alone is enough to seal the deal on that one for me. And the GWT language is worse than Java - it's Java sans reflection.

The library component of GWT provides no more abstraction over the DOM than any native JavaScript library would; you still end up dealing directly with Element objects, writing CSS and HTML, et cetera. The abstractions it does provide are harmful. CSS obfuscation is a great concept in theory, but in practice it just makes for a UI that is harder to develop, harder to debug, and harder to test with Selenium.

RPC severely overcomplicates the communication layer. The ability to marshal an object graph with cycles is nice, but almost never necessary. JSON is more than sufficient for nearly all purposes, and Jackson performs the marshaling task admirably (and implicitly, with Spring MVC). In addition to requiring more cruft on your giant heap of Java code, this feature also obfuscates ajax calls, making them harder to read and debug.

As for performance, I have no hard data, but it seems to me that the artifacts we've turned out perform comparably to, if not worse than, our ExtJS-based products.

There is, of course, always something to be said for the value of static typing, but frankly it just isn't worth it. GWT library developers have realized this, too, because the purpose of anything that uses generators (Editor framework) is to help you circumvent type checking at every opportunity. Heavy use of non-Java files (gwt.xml, ui.xml, css) - which I see as an acknowledgement that Java is the wrong language for frontend development - cripples an IDE's ability to support what compiler checking is present.

The compilation cost is high, and growing, without support for modular compilation. Hosted mode helps, but is still a significant time sink compared to testing a webapp based on static js/css/html resources, and requires our non-standard Maven plugin to get hot-swapping to work across multiple projects. Worse, though, is simply the cost of writing Java. Again, I have no real metrics with which to back this up, but my estimated observation is that this technology has given us an increase in both development and maintenance time, has provided no bug reduction, and results in an inferior shipped product.

new comment >