GWT: Gotcha's

Question

My team is embarking on its very first GWT project. We are fairly strong with Swing applications, with almost all of our work involving significant Swing GUIs.

However, this is our very first foray away from the Desktop and to the Web, and the project requires us to use GWT. The project itself is pretty straight forward, the only unknown to us being replacing the Swing UI with the GWT UI.

What pitfalls should we watch out for?

Answer 1

I can think of a few:

• Everything is asynchronous. Well, anything service-oriented at any rate. While Swing sometimes acts like this via SwingWorkers and the like, Swing is fundamentally synchronous via the EDT (event dispatching thread). It can take a bit of getting used to;
• You're in for a world of hurt known as CSS and cross-browser compatibility. While GWT does mask many of the differences between browsers, it certainly doesn't mask them all and you can spend hours looking for the source of a line of pixels in GWT just as you can in a normal Web Site;
• There are far fewer resources for Swing than GWT;
• You can only use certain classes on the client-side. The one that used to always cause me issues was BigDecimal;
• Your choices of widgets is far more limited. Whatever you do avoid ExtGWT like the plague. Daryls is like the Jeffrey Dahmer of Generics;
• Make sure you use GWT 1.6;
• The compile-time on GWT is just horrific;
• If you're just making client changes (ie you're not changing any service interfaces), you don't need to rebuild to see those changes. Just refresh in the hosted browser;
• For changes to serverside code that doesn't change the interfaces, make sure you have an Ant or Maven task to rebuild and redeploy your classes without doing a GWT rebuild;
• You can point the hosted browser at something other than the hosted server and debug using it; and
• Make sure your machine has lots of RAM. My IDE on some apps would get out of memory errors if less than about a gig of RAM was allocated to it and these weren't huge apps. I would really recommend 2gigs system RAM absolute minimum, preferably 3 or more.

Answer 2

Not using GIN and Guice. Dependency injection is very, very useful. GIN (Guice for GWT) isn't documented very well but is worth the time investment spent getting it to work.

Answer 3

To expand on what Cletus said about "certain classes", you do not have a full JRE on the GWT client-side. (Remember, GWT Java client code is translated to JavaScript.) This means that third party Java APIs will often not work client-side. They need to be ported for GWT. So much for write once, run everywhere. See here for more information about this limitation.

Answer 4

Different browsers have quite different performance characteristics, so you'll have to test against different browsers even though GWT generates Javascript workarounds for browser differences.

Creating DOM elements can be very slow in some browsers. If you have large-ish tables (dozens of rows) that change frequently, the browser can become unresponsive if you just delete all the rows and recreate them. We had to write a diffing algorithm to efficiently update tables when new contents were fetched from the server.