There is no future in GWT. Even Google is running away from it and is working on Dart now.
Having worked with GWT for some time, it's a subpar model. Perhaps it's a flawed execution of the concept, but it has extremely long compilation times, the development mode crawls (so developing with it is slow)--at least for a sizable project. Furthermore, it's not as easy to use external JS libraries (you have to create wrappers) and, worst of all, there just is not a vibrant community around it. For example, it's inexcusable for a 2012-era framework to not have a quality form validation library available.
The other downside of GWT is that it's written in verbose Java, with plenty of non-DRY stuff. GWT compiler provides code generation for some things and the Maven plugin has code generation for others. In my opinion, when a framework, that advertises ease of client/server integration, asks you to create TWO same-but-slightly-different interfaces per one service to make remote calls, and does so with a straight face in the documentation, then you know that the authors are missing the point. (Oh and you have to define the new service in three places in two different files.) The point is that brevity of code and DRY are very important. When the authors don't champion this, there is little hope for the whole thing.
GWT was a good idea when it was created, but it failed to evolve in the face of jQuery's competition.
All you need is abstract away enough pain and complexity until things become manageable and it's easier to get the job done. This is what jQuery did by abstracting away browser differences. This is what other frameworks, such as Backbone.js, are doing at the next level.
>> but it has extremely long compilation times, the development mode crawls
When you go to create the deployment package it's slow. When doing development, which is most of the time, it's fast to me. I can change things in the client or server code, save and see the results instantly.
>> it's inexcusable for a 2012-era framework to not have a quality form validation library available.
>> The other downside of GWT is that it's written in verbose Java
That is a huge, major win dude. Seriously. What else would we all program the web in? JavaScript? The language that has to be excused for all the weird things it does when you thought your code would do something different?
>> ...Java, with plenty of non-DRY stuff.
DRY is a principle, you can repeat yourself or not in any language you choose.
I'd quote more and respond to more but most of your arguments are clearly in favor of JavaScript programming, it makes no sense to compare a Java to JavaScript technology to a simple JavaScript library (jQuery) because with jQuery I still have to program in the weird unpredictable, odd behavioral world of JavaScript.
While I think GWT is a pretty good project and has some way to go before it can be categorized as failing, some of your other remarks make me think that you have not given appropriate consideration to the alternatives to its approach.
First and foremost, you can write javascript in such a way that your code does nothing weird and only what you intended. A good place to start is still "JavaScript: The Good Parts"[1]. Then I suggest finding some examples of nicely written javascript code on GitHub or some such site. I personally think underscore.js[2] and backbone.js[3] are rather nice.
If you have really given javascript a fair shot, and still strongly dislike it, there are many other languages that compile into javascript, but match its style more closely that Java does. I have been enjoying working in CoffeScript[4]. There is an excellent interactive book[5] that shows the javascript generated by the constructs in the language, which is also a good resource for discovering idioms to do things that are not obvious in javascript, like creating classes. TypeScript[6] and Dart[7] are both interesting languages with syntax more familiar to Java. There are a lot more languages that compile to javascript that I haven't mentioned[8].
It's possible that GWT and Java are the best fit for you, but don't pigeonhole yourself by thinking that they are the only good options out there.
It's not that the project is about to fail, it's that even with that I still don't see a future. The project is mostly driven by the now-disinterested Google and a bunch of large companies with huge and different GWT-based frameworks (SmartGWT, Vaadin, Sencha GXT). The latter players only have an interest in keeping the core of GWT alive, not in advancing the regular GWT experience. Other players are small and on the whole don't seem to be contributing in promising ways (in my opinion). For example, the GWT-P framework, despite some good ideas, is quite verbose and provides false time savings.
>> I can change things in the client or server code, save and see the results instantly.
I work on a medium-sized code base (compared to some enterprise code I used to work on in the past). I am using 1-yr-old top-of-the-line MBP with best-available SSD and let's just say we disagree on the definition of the term instantly. I experience anywhere from 15 to 30 second waits on refreshes (that trigger recompilation), plus server restarts if server-side hot code deploy fails. That's far from instant.
>>>> it's inexcusable for a 2012-era framework to not have a quality form validation library available.
Have you written forms that had to be validated? GWT CellTables that had to have contents be validated?
There is another GWT validation library out there that helps with forms/tying into GWT controls, but it's quite lackluster.
>>>> The other downside of GWT is that it's written in verbose Java
>> That is a huge, major win dude. Seriously. What else would we all program the web in? JavaScript?
Java is verbose and you have to recognize that downside. I will often pay those costs of verbosity on the server-side in exchange for performance. Someone else here gave a good alternative perspective, but yeah, JavaScript.
>>>> ...Java, with plenty of non-DRY stuff.
>> DRY is a principle, you can repeat yourself or not in any language you choose.
The problem with GWT, and this applies to the non-DRY comment, is that they did not aggressively go after eliminating that. They just said, "it's Java, things are just going to have to be verbose." C'mon, you wrote a Java-to-Javascript compiler for Pete's sake, surely you can put some talent into making the core development experience better! Especially in the face of competition like jQuery or Rails.
Creating two files per page/view sucks (or 3 files with GWT-P, be warned), or coding up your views w/o UI binder, you end up coding the layout of the page in pure Java (verbose and far from directly relatable to the layout). I already mentioned the pain of doing GWT RPC calls in my previous comment. I could go on all day.
Having worked with GWT for some time, it's a subpar model. Perhaps it's a flawed execution of the concept, but it has extremely long compilation times, the development mode crawls (so developing with it is slow)--at least for a sizable project. Furthermore, it's not as easy to use external JS libraries (you have to create wrappers) and, worst of all, there just is not a vibrant community around it. For example, it's inexcusable for a 2012-era framework to not have a quality form validation library available.
The other downside of GWT is that it's written in verbose Java, with plenty of non-DRY stuff. GWT compiler provides code generation for some things and the Maven plugin has code generation for others. In my opinion, when a framework, that advertises ease of client/server integration, asks you to create TWO same-but-slightly-different interfaces per one service to make remote calls, and does so with a straight face in the documentation, then you know that the authors are missing the point. (Oh and you have to define the new service in three places in two different files.) The point is that brevity of code and DRY are very important. When the authors don't champion this, there is little hope for the whole thing.
GWT was a good idea when it was created, but it failed to evolve in the face of jQuery's competition.
All you need is abstract away enough pain and complexity until things become manageable and it's easier to get the job done. This is what jQuery did by abstracting away browser differences. This is what other frameworks, such as Backbone.js, are doing at the next level.