When should you choose Google's GWT for your web app?

Up until about ten months ago, very few people would have considered javascript as a language in which one could build significant portions of the UI of an enterprise application. If, say, I needed to display a table of information with support for sorting and filtering, I would have been far more likely to do this processing on the server than to write it in javascript - simply because clean, maintainable and testable javascript code is not very easy to write - in contrast to something in say Java, C# or Ruby.

I guess it's pretty obvious where I'm coming from. I'm talking about the classic enterprise application where the focus is developing a robust code base with excellent test coverage which allows for easy maintenance and where the language of choice has good tool support so refactoring is joy for all concerned. These constraints pretty much eliminated javascript. Why is this so?

• Javascript is a dynamic language. This requires that the developers be more disciplined.
• Javascript (and other dynamic language) tool support has improved dramatically over the last couple of years, but still lags far behind Java and C# (with ReSharper installed, that is ;-))
• Unit testing, while it exists, isn't very convenient.
• This is a bit of a repetition but whatever; good Object Oriented Programming is very hard to do in javascript. And while you can do some pretty powerful stuff with blocks and closures, it takes a certain kind of developer to do a good job of it.
• Cross browser compatibility. This is a complete nightmare. Of course I'll be the first to admit that on most enterprise projects there is just one target browser.

Bottom line - the life saving test-code-refactor cycle is far more difficult to implement when coding in javascript.

Once GWT comes into the picture, the scenario changes dramatically. GWT allows you to code in Java and compiles all that code into Javascript. What's more, the DOM element wrappers that GWT provides mimic Java Swing. As far you're concerned you are now in Swing territory with all it's tried and tested approaches and patterns. GWT also provides it's own implementation of JUnit which look and feels much the same as it's parent (no setUp(), but you can't have everything, what?) Most of the overheads of working with javascript for UI are removed (and yes, a few are added, what with Java not being dynamic :-))
You can now bring the awesome power of IntelliJ or Eclipse to bear on the problem. You can write all the unit tests you want. You're no longer worrying about that annoying javascript filterable table which five different developers have worked on and the customer really likes but which is now brittle and utterly unreadable.
You've now got a neatly separated domain model, presentation model, controller and view.
And it's all unit tested.
And you can refactor all you want.
And async calls/AJAX become utterly trivial.
And it's browser compatible.
No more muttering about having to manage with simple text renames instead of Alt+Enter/Ctrl+1. No more muddling around with explicit XMLHttp or JSON calls. The latter are now abstracted to simple RPC style method calls.

Of course, nothing is perfect. First, you need to choose between GWT layouts and CSS. Second, GWT apps are single page apps with all changes handled via DOM manipulations. If you're developing a site where users are likely to just drop by to view a single page for a short span of time (IMDB, Amazon - you get the picture...), then it doesn't make sense to dump 200KB of javascript on them - which is pretty average for a sample GWT application. The biggest danger is of course the temptation of trying to develop a full fledged thick client in the browser. Javascript executes pretty slowly compared to thick client UI written in managed languages - and this remains true even with the dramatic improvements in performance we see in Firefox 2.0 and IE7. Just try creating a simple application supporting the kind of complex drag-drop we see in many thick clients. Performance starts to degrade rapidly and soon the app practically freezes in the browser. The pitfalls are many and it is very important to keep in mind that GWT only offers the convenience of developing with a thick client paradigm and that your code is ultimately interpreted javascript which is going to be doing plenty of DOM manipulation. There are dozens of such nits one can pick - 'nuff said.

To summarize - thanks to GWT, we are now in a position to develop complex, rich, AJAX web-applications considerably faster and more reliably than we could using hand-coded javascript. The code base is more robust, easier to maintain and enjoys much better tool support. There will probably be some loss of performance, but one of the goals of the GWT team is to make the GWT compiler be to javascript what modern C/C++ compilers are to assembly. You just assume that most of the time the compiler can optimize far better than you can. GWT also costs you nothing and is completely OSS under an Apache licence and is being developed by a crack team of Google coders. It's just as important to remember what GWT isn't. GWT isn't a javascript library - it's a compiler. GWT also isn't a full stack solution - for that you'll have to whip up your own (I've had good experiences with Hibernate and XStream) or you can look at something like Spring.

Update: 2007-06-07
There were several thoughts which came out of this, one of them being that the whole model of web development is pretty messed up for certain kinds of applications. I've written a post explaining what I mean by this and why we should have our business models on the browser in javascript and use AJAX only to keep them synced with the server. You can find it here.

You may also want to read: The difference between a web application and a website
You may also want to read: Bringing business logic to the browser, or why you should develop in JavaScript
You may also want to read: JavaScript on Rails is here, and it promises to be as good as Ruby on Rails!