Playing with Programs

I spent a morning playing with GWT – the Google Web Toolkit at spa2009, during We like GWT, we think you will too by Stuart Ervine and Franck Rasolo.

I promised Sushrut Bidwai to write about my experience. Did I like it? Lets’ see.

What I liked:

• We (I paired with Marc Evers) completed a number of quite usable features in the span of a morning (thankfully we did not have to write much back-end database code, with java verbosity / xml-osity  or anotation-osity seems unavoidable).
• Writing javascript in java feels a bit odd (as a language, I am taken more with javascript’s flexibility than java’s mid-level-language ‘you must spell everything out n times’, but being able to apply merciless refactoring tools on the client side was quite nice.
• Realizing whether the piece we were working on was on the server or client side was a bit confusing at first.
• Having programmed with Wicket quite a bit lately, and writing a GTK desktop application in C#, the programming model was quite familiar. Having all the behaviour that is (part of) a screen in one place feels convenient (as opposed to e.g. ruby on rails where behaviour tends to get spread out over controller code, view code and javascript files here and there).
• The client side code provided by GWT for formatting currency and dates was elegant and easy to use (take that Java API! )

Puzzles:

• Marc felt the AsyncCallbacks instances that are needed to glue front to back – end were at the wrong level of abstraction. I feel that may be, but it is already a step up from having half of the mechanism in javascript and the other half in the server side language.
• When working on a user interface, I like to be able to see changes instantly, so that I can play around and see what works best (and yes, tests will be written at some point, before, after or during). Some changes we could try instantly, in the special GWT toy browser, others needed a lengthy compile.

Things I liked less

• Even for the sample application, the compile times (when we changed some parts of the code, otherwise we could reload in the special browser) were already quite long. I am used to instant modifications (ruby, perl etc.) or very fast compiles (java with wicket) and have no desire to go back to the days of program-compile-coffee-run . Apparently it can be reduced by generating client javascript for just one browser (and generate everything in the build for instance)
• Unit Testing the client side code is ’special’ – can not use JUnit apparently. (this is me being a customer – I want more! testing javascript code is special otherwise as well).
• The ide (intellij idea)seemed necessary to magically tie bits of client and server code together that belonged together.

Verdict: I am a bit conflicted. For AJAX-heavy (more likely: AJAX-only, GWT does not seem to be meant for unobtrusive javascript) web applications it seems quite productive. However I would worry about the long compile times (maybe less if I knew how to rapidly testdrive the whole thing – this may be a beginners’ perspective. However I also heard some of my tweeps complain about compiles that take a couple of minutes).

If you are curious and want to go out and play for yourself, the example code is accessible through the Spa Conference wiki.