Nice. Who has experience working with GWT? Is it easy to get stuff done in? To work around its limitation (whatever they may be?) We're considering it for a project, but I've never worked with it.
I think it depends on your perspective. If you like being a web developer, then I strongly suspect GWT is not for you. A (non-comprehensive) list of things that are likely to bother you if you're a web dev (and like it):
* Things like progressive enhancement and semantic markup might not be totally impossible, but they're definitely not the focus of the framework.
* The back button is broken by default; there's a work-around but you're probably used to getting that functionality for free.
* The GWT compile cycle is LONG.
* You pretty much NEED to be using Eclipse (or possibly IntelliJ) instead of your text editor of choice.
* The final product probably won't feel like most web applications.
To be fair, people have written things like [quake2-gwt](http://code.google.com/p/quake2-gwt-port/), so you can get something pretty awesome in exchange for these tradeoffs. Also, if you loathe HTML and JavaScript, but you still need to get something up on the web, then GWT might be just your ticket.
The default compile cycle is long as GWT is compiling for multiple clients targets (and potentially localisations). You can speed this up a great deal by reducing compile permutations to 1 (http://code.google.com/p/google-web-toolkit-doc-1-5/wiki/FAQ...). You should probably also mention that you don't need to recompile in development mode.
While there is a straightforward way to implement Back and History, the point is that traditional web dev technologies give it to you for free, so it's one more thing to think about.
Compile time definitely gets better if you reduce the number of targets, but it still totally dominates most people's build times.
Not needing to recompile in dev mode is definitely a big win.
Some of these criticisms are also true of all of the browser-side application frameworks - i.e SproutCore, Cappuccino etc.
FWIW, the compile time is still pretty long even with one compile permutation - and even while developing there is sometimes a need do do this (for example, changes to serialized objects.)
Regarding compile times, a few things I've found that help:
1) Reduce the number of targets (even if only while you are doing development)
2) Increase the number of threads doing the GWT compiling (-localWorkers).
Also, try running your compiles from a SSD. I haven't done this, but I've heard really good things about it (and GWT compiling sure is IO intensive so it's not surprising)
GWT's downside is that you're now making a rich client, and, IMHO, rich clients are a PITA compared to web 1.0/web 2.0 apps that just generate HTML on the server-side.
A rich client generally means you aren't sending HTML across the wire anymore, you're sending objects (json/xml/whatever), which adds a whole new layer of serialization and deserialization to your app. Even if GWT "solves" the technical side of serialization for you, you're (typically) still getting/setting data in/out of a lot of DTOs.
A rich client also generally means you're doing fancy validation/event driven coolness that, for me anyway, takes a lot more time to get right than just "here's a text box, have fun".
So, yeah, you'll get really slick apps with it, but I would be hesitant to use it if you're not certain you need a gmail-style one-page app.
One thing about your final point: you should probably be asking yourself why you need a web application that doesn't act like most web applications. If you don't have some really compelling story that you just can't (reasonably) tell in traditional HTML/JavaScript/AJAX applications, there's a fair chance you're just going to piss off a lot of your potential users, who expect a web site to act like a web site.
Our web app is exclusively embedded and hosted from an activex control within a desktop windows application. GWT really fits nicely with this admittedly awkward model.
I wouldn't have chosen GWT myself but I am working on a project with it and I have to admit it's very good.
You do have to be able to stand Java, of course. The upside of the use of Java is that when you're dealing with a large codebase the kind of tooling you get from Eclipse or IntelliJ is a big timesaver when refactoring. Things like CssResources and UiBinders are also very nice to work with, and do really help with keeping logic and presentation separate.
Some would claim that GWT is a bit of a crutch for enterprisey developers who "don't like working in the browser" but I'd say it's more for people who like working in the browser but don't much like Javascript. (FWIW I like Javascript, at least The Good Parts.) You do at the end of the day have to have a good understanding of how the browser works and what it is and is not good at to get the most out of it.
The biggest downsides for me are, in no particular order...
1) Very slow compiler when generating javascript. GWT compilation is the biggest chunk of our build time but not the majority of our code.
2) For a large application, load time in hosted mode is still pretty slow. Also hosted mode has some funky performance characteristics especially around serialization.
3) It kind of annoys me seeing lots of code working around a lack of reflection in GWT's version of Java, when the underlying Javascript runtime is completely dynamic and reflective.
I do have a lingering concern that GWT might be exposed to similar patent risks as Android, since it subsets Java and could not be considered a "compliant" java implementation. Not the same patents as in the Android case, obviously - since they were mostly VM related - but who knows what else Sun had in their cupboard.
While I agree that it's not a good idea to hand GWT to a bunch of <snip>enterprisey developers who "don't like working in the browser"</snip>, I think that's exactly how it gets used by a lot of companies (based on the questions I run into on the web).
Java is not ideal, we all know that, it just hasn't caught up (in fact that was true even when it first came out). But you can treat it as a target (like assembly) that is made for an IDE to read and write. Then just work with the IDE for a while you will find that a lot of the time the IDE provides the functionality of a more productive language (it even helps you to read the code). After a while the language starts to dissapear a bit and you can concentrate on the job itself, which is what it should be all about. I know this (language choice etc) is a contentious area so let me say that this is my personal experience and I have no way of knowing whether it would be true for anyone else.
I love GWT. I've been using it for 3+ years. However, I love it because when I write a large enterprise web app, Javascript just doesn't cut it. But, I'm also a C# developer, and so I feel that Java is holding GWT back - as Java bothers me.
I'm using GWT to build a html5 (excuse the buzzword) game engine. It's brilliant. The documentation is first-class and it works perfectly.
If you have experience working with java, and know your way around the web, you should be fine. The only real limitation I'd come across was developing UIs, but this solves that problem.
I have developed 8 apps now in GWT and have liked it a lot. Of course I come from Java background and have always liked the lang itself. You should also check out other frameworks such as smartgwt which enhance GWT further.
The only thing you're really missing out on would be the automagic serialisation you get with GWT-RPC and Java on the server.
On a side note, Sinatra would probably be a better fit than Rails given that you really only need lightweight web services on the server. Runs quite happily on App-Engine too!
Before AppEngine, that's the only way I would write GWT apps. I loathe Tomcat. (I know there are other J2EE servers). I used Rails on the backend. It worked amazingly well.
