The answer is, I don't know. It seems like a toy at times, but a really powerful toy. It's hard for me to imagine creating a real website using it, and there is really no way to even use it just for prototyping. As I understood it more though, I realized that there was a real-world workflow possible with it, and maybe that's its biggest strength.
That's nice, really nice. I think having a good workflow between designers and developers is huge. Just look at what Microsoft has tried to do with Web Forms and now with XAML. Web Forms arguably inspired Java Server Faces, which is now part of the JavaEE specification. So maybe that's the real strength of GWT. Everything else is icing on the cake. That being said, here's my favorite and least favorite things about GWT.
- Nice HTML Abstractions -- Really like the FlexTable for example. It's also interesting to port layout managers to HTML. I can definitely see possible conflicts with CSS though. I'm not sure what would happen if your CSS specified a position that really conflicted with the layout algorithm. I'm sure CSS would win, I'm just not sure how bad it's going to make things look.
- RAD Tools -- Nice tools for setting up your project, etc. A lot of GWT was clearly inspired by Ruby on Rails, and this is one of the notable inspirations.
- Architecture -- Encourages UI logic being pushed to the client. Make use of the user's computer, and offload from your server.
- Cross Platform Problems -- All those RAD tools are OS dependent. In my experience they work really well on OSX, but are haphazard on Windows. I love OSX, but that's not good.
- Obfuscation -- The generated JS is dense and heavily obfuscated. Maybe that is useful for Google projects, but how is it good for the average developer? It creates a dependency. If you can't debug your client code in hosted mode, you have no chance of debugging it at all.
- Lots of boilerplate code to write -- To use a remote service, you have to write a client side interface for it (not too bad), an asynchronous version of the same interface, and the actual (server side) implementation of the interface. Then you have to write some obscure looking client side code for registering the service at runtime. Doesn't this all sound familiar? Doesn't this sound like creating remote and home interfaces for an EJB and then having to use JNDI to look it up at runtime? We all know how that turned out for EJBs.
- Better build support needed -- Hosted mode is great, but it's kind of a pain going from hosted mode to a real deployment. GWT can't solve this completely obviously, but they can do more. Hosted mode lets you switch to a "live" mode where GWT creates a Tomcat directory and installs the web application to Tomcat. So clearly they understand the deployment issues, like exposing the RPC servlet endpoint in web.xml.
- RPC is bad -- Ok, I'm not quite as convinced of this as I used to be, but I think it is mostly true. RPC encourages a lot of strong coupling between server and client. However, I think the distinctions between server and client are fading anyways, so this is becoming less of an issue. You're probably going to want the services called by the client to be facades to the "real" services anyways, just because you don't want your real services to be compiled into servlets (which is what happens because you have to extend the RemoteServlet class in GWT.)
I'd like to see GWT leverage Java 5 a lot more. It needs to support generics. It should not only ignore most annotations, it should use them to eliminate the boilerplate code that developers have to write and the redundant interfaces that have to be declared.