The choice of using GWT was nearly natural once we defined the need for a very dynamic "single page" application.
Our Flex developers found themselves in a known environment (Eclipse) - developing a webapp with a strongly typed language. It took them 2 weeks to learn the GWT Framework - together with the Java language itself!
We were delighted to see the number of high quality libraries already available, as well as the vivid community around GWT. Finally, the determination of Google to keep the project updated was a convincing factor for adopting this technology.
From the beginning, we started using a MVC framework to keep our code well-structured, and it soon paid itself off in development. The predictability of the framework was a big plus: you write code, you reload, it works. All the bugs we encountered were documented, so finding workarounds was pretty straightforward. We were a bit anxious about legacy Javascript bridging, but JSNI proved to be a very easy way to use 3rd-party libraries.
We started development with version 1.5.3 of GWT and we just ported the app to 1.7. The porting process was a breeze and we’re very happy to be able to use the Eclipse plug-in for GWT.
I guess one area of departure is that we did not follow the classical RPC way for our server-side interactions. Instead, we built a REST API to keep our back-end services agnostic from the client used. We’re using Restlets to interact with our REST API, which once again worked flawlessly, as expected.
Our overall experience using GWT has been very positive. The fact that we develop in Java has a lot of advantages, such as being able to use java debugging tools - instead of just Firebug - if you’re in pure JavaScript. GWT has a few things we would like to see, like being able to load code dynamically instead of compiling everything in a large .js file, but it seems that GWT2.0 will bring forth some new possibilities.
