Using Google Web Toolkit: A Year in the Trenches
tech.dayzipping.com
tech.dayzipping.com
Of course, that leaves open a larger question: Do you, personally, want to write web apps in Java? If not, then you'll find GWT to be a clever solution to a problem that you didn't want solved.
That's not to say that it can't be used in a more "social" context (Rypple uses GWT for their app, and I have yet to see problems there), but I'd imagine that it has greater use for data miners and enterprise applications.
stevey: I hear you guys are using GWT, how's that working out for you?
buddy: It's kind of like programming while wearing mittens.
stevey: Mittens are good, right?
buddy: Not if you're trying to type.
Make of this what you will.
(I also hope scala-gwt will become real-world-usable some day :) )
I can't say it is bad. Actually, it has been pretty good. But, somehow when I look at all the other development environments out there, some of them look better. ekidd put it pretty well, actually.
The best side effect of using GWT has been a lot of business logic on the client side.
The worst side effect of using GWT has been a lot of business logic on the client side.
The error I see is: Uncaught TypeError: Cannot call method 'init' of undefined
In particular, compilation to javascript should not be inside of your basic edit->compile->test loop. Instead, you should be developing in DevMode (formerly known as "HostedMode") where the code runs in a JVM. The step of compiling to javascript should only happen once or twice as your code starts going towards a production environment.
To put a finer point on it: GWT does not require you to structure your app that way. If you do choose to structure your app that way, then you're making the same tradeoff that you would make if you were to go down that same path in any toolkit.
The technique here is using URL fragments for history management in AJAX applications.
This tool (GWT) does not require that technique any more than JQuery does (or myriad other examples), so the comparison of the tradeoffs of using/avoiding the technique is orthogonal to the choice of tool.
If I were facing their problem (where they had already chosen to use URL fragments for navigation but also didn't want to miss out on crawlability) I would use a different approach than maintaining a separate set of static pages.
Instead of static pages, I would create a single servlet/cgi that would handle the URLs to these pages. The content for each URL could be created on-the-fly on the server side using some server-side browser (like HtmlUnit, Cobra or Crowbar...) to receive the requests, translate the URL into the fragment-format, run your actual javascript application (which is already written to handle such fragments) and capture the resulting DOM to send back to the actual browser that arrived via the Google search. Of course the HTML could be persisted so that this process would only need to happen once per URL. The benefit of doing it this way would be that when you deployed changes you could simply invalidate the HTML cache and let your system build them again automatically.
But it would probably be better to avoid the problem entirely by thinking about SEO needs up front.
Also, You can now use GWT Designer, an Eclipse plugin that lets you build UIs graphically.
On the other hand, if you are a familiar with html and css layouts, this all might seem like a big mess, and too much work to do something simple. And you will not like the generated code (many many tables, often).
That's why they created GWT's UIBinder. You can use a html-like code to design the UI. This is much easier than making all the panel.add(widget) stuff in code. And it is a nice compromise, because your front-end designers will understand it. The big downfall is that it needs to be compiled to view the results, and believe me, this can be a cumbersome task.
I have been using it in the scenario where we get all the html and css from the designer, along with the jquery to add some effects. It wasn't easy porting the whole (working!) design to something usable by GWT. But, in the end we got the GWT to generate exactly the same markup.
All in all, there's no such thing as a free lunch.
You don't have to, and you're not necessarily even supposed to. You work with DOM elements and CSS styles just as you would anyway. Every Widget in GWT inherits from the UIObject class. Each instance corresponds to exactly one tag in your DOM, and has methods for getting/setting styles. Your java code would just handle putting the element where you want it in the DOM, and setting the style(s). The layout is in your CSS, just as usual.