What is the best approach towards styling GWT applications?
General approach in GWT is to use Panels and then apply custom CSS themes to get a customized look. While I can achieve a certain extent of personalization of my GWT app through CSS tinkering, I was wondering how others generally approach styling.
Some of the suggestions I came across the web were to manage layout with plain HTML, through use of HTMLPanel's. This way one can straightaway use the HTML mock-up within the application without having to code all the layout.
So what in your opinion is the best and least painful way to approach layout and custom styling of GWT application?

It all depends - on you, your experience, your team, etc:
  1. The usual/older approach of Panels, Widgets and Compositing will be easier to work with/more familiar:
    • If you are a Java programmer experienced with frameworks like Swing, etc. (I think that was the point of the GWT team),
    • Or if you come from the "desktop world" in general.
  2. The UiBinder approach is the newer one:
    • Recommended if you are just starting your experience with GWT (it seems UiBinder is here to stay, and it allows more flexibility than the above approach),
    • Recommended if you have experience with web development (or desktop frameworks that use markup, like .NET's XAML, etc), since you'll be working in the familiar world of HTML/XML,
    • If you are working in a larger team, where you have designated designers in charge of the look of the web application (and they don't know/care about GWT). Cutting up the layout into HTML code should be pretty straightforward for them and you can, with little work, convert those templates into UiBinder's XML templates.
None of the above approaches is perfect - that's why it's worth to know their strong and weak points - but the end decision should be yours alone, since you know your/your team's capabilities best :)


Does UiBinder internally uses HtmlPanel to embed raw HTML?
Short answer: no :) UiBinder is just a templating language - it's up to you if you want to use only HTML in your template or to embed some Widgets in some sort of Panel. Your template will be output just as it is - without and extra "wrapping" around it (so if your root Panel is HTMLPanel you'll get a div, etc). HTMLPanel is often used as a root Panel for UiBinder templates, because it has some special treatment by UiBinder - you can mix HTML and Widgets in it (you can't, for example, put raw HTML in a VerticalPanel). See the UiBinder docs for more info.

When not to use Google Web Toolkit?
I'm considering use of GWT on a major in-house web app development project, namely it's major advantage in my eyes is the cross-compilation to Javascript which would (at least theoretically) help my team reduce the size of tech stack by one.
However, having been burnt before (like most devs), I would like to hear from programmers who did actually use it on any problems with GWT which would hamper, or limit, it's use within a certain problem domain.
When do you not recommend using GWT, and why?

I am both good and bad to answer this question - good, in that I've actually used it before, and bad, in that I was quite experienced with HTML/CSS/JavaScript prior to working with GWT. This left me maddened by using GWT in a way that other Java developers who don't really know DHTML may not have been.
GWT does what it says - it abstracts JavaScript and to some degree HTML into Java. To many developers, this sounds brilliant. However, we know, as Jeff Atwood puts it, all abstractions are failed abstractions (worth a read if considering GWT). With GWT, this specifically introduces the following problems:

Using HTML in GWT sucks.

As I said it, to some degree, even abstracts away HTML. It sounds good to a Java developer. But it's not. HTML is a document markup format. If you wanted to create Java objects to define a document, you would not use document markup elements. It is maddeningly verbose. It is also not controlled enough. In HTML there is essentially one way to write <p>Hello how are <b>you</b>?</p>. In GWT, you have 3 child nodes (text, B, text) attached to a P node. You can either create the P first, or create the child nodes first. One of the child nodes might be the return result of a function. After a few months of development with many developers, trying to decipher what your HTML document looks like by tracing your GWT code is a headache-inducing process.
In the end, the team decided that maybe using HTMLPanel for all HTML was the right way to go. Now, you've lost many of GWT's advantages of having elements readily available to Java code to bind easily for data.

Using CSS in GWT sucks.

By attachment to HTML abstraction, this means that the way you have to use CSS is also different. It might have improved since I last used GWT (about 9 months ago), but at the time, CSS support was a mess. Because of the way GWT makes you create HTML, you often have levels of nodes that you didn't know were injected (any CSS dev knows how this can dramatically affect rendering). There were too many ways to embed or link CSS, resulting in a confusing mess of namespaces. On top of that you had the sprite support, which again sounds nice, but actually mutated your CSS and we had problems with it writing properties which we then had to explicitly overwrite later, or in some cases, thwarted our attempts to match our hand-coded CSS and having to just redesign it in ways that GWT didn't screw it up.

Union of problems, intersection of benefits

Any languages is going to have it's own set of problems and benefits. Whether you use it is a weighted formula based on those. When you have an abstraction, what you get is a union of all the problems, and an intersection of the benefits. JavaScript has it's problems, and is commonly derided among server-side engineers, but it also has quite a few features that are helpful for rapid web development. Think closures, syntax shorthand, ad-hoc objects, all of the stuff done by Jquery (like DOM querying by CSS selector). Now forget about using it in GWT!

Separation of concerns

We all know that as the size of a project grows, having good separation of concerns is critical. One of the most important is the separation between display and processing. GWT made this really hard. Probably not impossible, but the team I was on never came up with a good solution, and even when we thought we had, we always had one leaking into the other.

Desktop != Web

As @Berin Loritsch posted in the comments, the model or mindset GWT is built for is living applications, where a program has a living display tightly coupled with a processing engine. This sounds good because that's what so many feel the web is lacking. But there are two problems: A) The web is built on HTTP and this is inherently different. As I mentioned above, the technologies built on HTTP - HTML, CSS, even resource-loading and caching (images, etc.), have been built for that platform. B) Java developers who have been working on the web do not easily switch to this desktop-application mindset. Architecture in this world is an entirely different discipline. Flex developers would probably be more suited to GWT than Java web developers.

In conclusion...

GWT is capable of producing quick-and-dirty AJAX applications quite easily using just Java. If quick-and-dirty doesn't sound like what you want, don't use it. The company I was working for was a company that cared a lot about the end product, and it's sense of polish, both visual and interactive, to the user. For us front-end developers, this meant that we needed to control HTML, CSS, and JavaScript in ways that made using GWT like trying to play the piano with boxing gloves on.

http://www.ongwt.com/post/2007/11/14/GWT-Pros-and-Cons
Need to design presentation layer architecture very carefully. When building large complex web application with GWT you end up with a huge number of classes. To be able to maintain and extend application code you will have to use some architectural patterns for building GUI (like HMVC, PAC etc).

When using GWT
Scenario 
 - You are starting a new Web app
 - You want a large pure-Ajax app
    • Looks like a desktop application
    • Has complex client-server communication
- For client-side code, you want strong typing, many data structures, and few runtime errors
    • You want Java, not JavaScript for the client!
Best approach
 - Use the Google Web Toolkit
    • Client-side Java code gets compiled to JavaScript
    • Powerful RPC mechanism for talking to server