This past weekend I had a chance to upgrade a GWT/GXT project earlier than expected. We’ve had considerable pain on the current version of GXT and hoped this might lessen it; sadly, the grass was not much greener on the other side.

GWT for its part was a fairly straightforward process, even with all the significant “breaking” API changes like a new war-based project layout, new eventing model, new compiler, and revamped hosted mode (see the complete list here). The steps involved were essentially:

• Bring in the new jars
• Move resource directories and web.xml into the new preferred war location
• Fix compile errors (mostly new event/listener type and getters/setters replacing public members)
• Change the compiler and hosted mode classes to the new ones, with the new args
• Toy with the hosted mode and build classpaths so that Selenium is in the classpath first for unit tests, but GWT is first for hosted mode (because our project uses Selenium for UI tests and both Selenium and GWT are nice enough to bundle Jetty – and different versions, no less – as dependencies; Selenium, please move to Jetty 6 already!)

Additionally, each developer on the project had to disable/re-enable their GWT profile in Eclipse to have it detect 1.6 mode and re-create any run targets (not a big deal really, since the GWT Eclipse plugin makes this much easier than before!).

We have run into one intermittent problem worth noting: When attempting to run our client with a mock services stack (simple web.xml with local servlets that return test data), hosted mode will occaisonally freeze on startup. Debugging has revealed that our RPC calls are initiated but never returned. Base on the randomness and timing of the freeze it almost looks like a race condition where the mock services aren’t deployed as fast as the client, and hosted mode gets stuck in a loop waiting for the return on a call that was never received. Since our application has a rather custom setup where we run RPC against a different context in production (separate services war inside the same container), and this is also something we’ve attempted to mock, it’s not bad as a single issue; our workaround is to simply run the mock service stack externally on Jetty via an ant task and use hosted mode solely for deploying the client.

GXT on the other hand was a nightmare. GXT issues were the main driver behind our early upgrade – since the 2.0 release date keeps moving we decided to bite the bullet now and try M1 in hopes that it would fix more than it breaks. The obvious breaking changes were minimal – just some type changes, event differences, and slight re-arrangement of classes. But in terms of functionality the visual layout of the application was immediately wrecked on upgrade due to a number of blatant bugs (or very questionable behavior changes). Note that after our initial run-through we downloaded the very latest 2.0 snapshot from svn (as of 4/26/2009) and built that with similar results:

Percentage/pixel sizing problems
On components using a CardLayout (like TabPanel), height and width percentages get changed into raw pixels. In other words, calling setHeight(“100%”) results in HTML with height=100px embedded in it. This is incredibly annoying and I can’t overstate how thoroughly it breaks an application. Since our application sizes very dynamically and we intentionally avoid fixed size like the plague, it immediately became a mangled cluster of 100×100 boxes. Entertaining yes, but difficult to fix. We’ve ended up implementing a mixture of fixed heights/widths on the affected components and trying to delegate more explicitly to parent sizes until there’s a permanent fix.

Tighter coupling
Components seem less designed for extension, or at least more tightly coupled to each other and the DOM; for instance, several components that we’d extended and overridden onRender() for specific functionality blew up spectacularly, requiring that we override and assuage other methods to make them content again. The changes aren’t bad, but a framework doesn’t feel well thought-out when I’m forced to hack things one way in release x, then hack them a different way in release y.

CSS changes
To the GXT team’s credit the CSS tags used by objects are largely unchanged, however the css behavior and default values of many components are different; this was mostly an impact where we’d intentionally hacked things in CSS to make them look correct cross-browser and the hack was no longer necessary (or worse, now causing an issue). Our bad for hacking, but again, it sucks when a framework forces you into this, then keeps changing it.

New features incomplete
Any of the big “new” features we tried like HBoxLayout and VBoxLayout seem incredibly incomplete or broken. For example, attempting to use a VBoxLayout resulted in a panel rendering partially in the correct spot with its children lined up at the bottom of the screen, below the rest of the application; source inspection revealed some serious div madness going on. Based on this state of fail we’re not planning to dive further into any new features until it’s GA.

All in all the net change in GXT 2.0 as of M1 seems to be slightly better performance and a mild set of new features, yet with most of those new features broken and some very serious and annoying core bugs such as the percentage/pixel issue. I really hope they’re hard at working fixing these, as the pushed release date may suggest, and that the final release has some honest documentation on ALL breaking API changes and known issues, especially since documentation is something GXT has always lacked. I would highly recommend against anyone taking 2.0-M1 unless pain is something you enjoy, considering the serious issues and the fact that none of the new features feel usable yet.

GWT 1.6 by contrast is a no-brainer; if you’re lucky enough to be building an app with core GWT and homegrown components and/or another library this will probably make your life much easier. The war layout makes for even tighter integration with Java and is great for projects that are a mix of GWT and static content or other UI technologies. And the new configurability of the compiler makes parallel compilation or even disabling some browser permutations as easy as a few compiler args or lines in your .gwt.xml.

To the Ext guys: I really hope you have something better in store for us by 2.0 GA! The team I work on has many developers who’re new to GWT development and have backgrounds in custom AJAX, Flash, or C# UI’s. GXT 2.0 is continuing to build their impression that this technology is a hack that brings the “worst of both worlds”: they see a complex framework that’s lacking many features, yet is difficult or impossible to extend in a way that will be a) consistent cross-browser and b) not break completely on upgrade. Combined with the lengthy build/deploy time to test small changes in real browsers, it’s feeling like a net loss vs. straight AJAX (in JavaScript) or, better yet, another RIA technology completely such as Flash or Silverlight.

It’s worth noting that none of the pain points I’m belaboring, especially when it comes to CSS weirdness and cross-browser testing, are anything unexpected for traditional web application development. But they should not be the norm for GWT: a library on top of GWT that experiences all these pitfalls with regularity seems to miss the point. We expect something in return for long compile times and difficult-to-debug generated code; certainly more than just the convenience and familiarity of Java versus JavaScript.

But as someone heavily vested in a GXT project, here’s hoping even more that it shapes up a bit by 2.0 GA!