I've been using Google Web Toolkit for some projects at work, and I've been quite impressed with it. I think that for many classes of web apps, GWT (or something with the same general model) is really the "right" way to build your app.
(Disclosure: these were the first nontrivial web apps I've written since before the term "AJAX" came into common parlance, so I've not been totally in the loop for some time with respect to web programming or any of the major JS libraries.)
For the uninitiated: GWT is a free software development stack that lets web developers write apps entirely in Java. GWT provides various UI and utility libraries, as well as a compiler that compiles your Java code to a combination of Java servlets and client-side Javascript— including the XMLHttpRequest serialization/deserialization code needed at the client/server boundary.
I don't have anything against Javascript or dynamic languages. But I think that for certain web apps it can make sense to trade away some of the flexibility of Javascript. In many web apps today, the app is just the frontend to some database, and the client's responsibility is mainly just to manipulate the DOM and shuttle data around. Not a whole lot of business logic— although, to be fair, JS apps will likely become more and more sophisticated in the future. I suspect many of these apps might be better served by a strongly typed language. The GWT Java compiler prevents entire classes of errors right off the bat, including the most common type in JS apps in my experience: typos. (Yeah, unit tests and tools will also mitigate these problems a bit.)
However, I think the most important idea at the core of GWT is that of a language-to-language translator. The problem with pure Javascript is that the code you want to be writing and maintaining does not look at all like the code you want the browser to be executing. The idea of an intermediate translation step is not new: people have been using Javascript minifiers/obfuscators for years to speed up loading and execution. But GWT takes this further: in addition to shortening identifiers, it aggressively inlines code and eliminates dead code (unused variables, fields, methods, classes, ...). Now you're free to introduce indirection in your code to make it more readable and testable (for example, refactoring to the model-view-presenter pattern) without feeling guilty that you are making your app slower. (Testability! Hooray!) This eliminates some of the usual tension between speed and maintainability.
Actually, GWT takes its translation process even further: it compiles multiple browser-specific versions of your app— something that few, if any, humans would bother to do— so that no client ever has to load or execute switch-on-browser logic and each client gets a variant optimized for its platform.
When all these optimizations are considered, Google claims that GWT-generated code is "often ... faster than equivalent handwritten Javascript." That shouldn't be surprising: code that is to be maintained has to meet some minimum standard of readability, but code that is to be executed has no such requirement. This really drives home the importance, and the power, of having a source-to-source translation process in the pipeline.
(There are a number of other compelling reasons to use GWT that I haven't mentioned here. The GWT page gives a pretty good overview of them.)
