Why spend cycles doing work on the shared resource (the server), when you can leverage the (hopefully) millions of CPUs used by clients?
Smart clients reduce server load, and allow increased scale; why pay to make your server turn models into HTML when you can just send the model to the client and let it deal with it however it wishes.
For us at Appian, we use the same models and APIs for web, android and IOS; by having a smart client, the server only has to care about the shared model and executing requested instructions; it doesn't care how the client renders the result, nor should it.
Threading support in gwt is still just a glorified Timer. I haven't had the time / a reason to actually implement a multi-compile to web worker to make them function correctly. If you can think of a good test project, I'd be glad to add it to my backlog after the gwt.create conference, where I'll be speaking about web components, java 8 and JsInterop. Basically, in my latest projects, about 90% of the implementation is annotated interfaces and default methods that get stitched together into web components...
I'm not sure how the other transpilers expose native javascript, but in the future of Gwt, interacting with plain javascript is dead simple; you get the best of both worlds; typed java code, and low-level js performance. The JsInterop stuff makes wrapping native js super easy, just define an interface that matches the JS, and it "just works" (tm). Even web components, just create an annotated interface, define default methods, and the compiler attaches them to custom element definitions. I could go on and on, but I'll save it for the correct forum (i.e., the gwt.create conference). :D
My implementation in GWT lets you control how much is retained by using annotations to control the retention level. It even gives you the option to defer loading reflection until a future code split, such that you only download the extra bytes for reflection support when you will actually need it. See above for link.
I actually have fully functioning reflection in GWT in a branch of my own, and will be getting it merged to master shortly after the GWT.create conference.
If you want to support complete reflection across the board it greatly swells compile size, but I have made it so you can be selective about what supports reflection, in order to avoid code bloat.
Funny you mention docs... The new Google Sheets (y'know, that awesome spreadsheet app that lets you write javascript macros with a full in-browser debugger), is written in GWT.
Note that GWT 3 will see the birth of incremental compiler plus super dev mode, which will actually be FASTER than Dev Mode.
I don't know about you, but the dev-mode lag of jumping back and forth between browser and jvm actually makes dev mode painful to use, especially on very large projects that can take many seconds to reload fresh code.
As someone who does work a lot on raw js projects using GWT (including Collide, as mentioned by Ray), I can say I'm very happy to see widgets de-emphasized in favor of using html5 features, like web components.
When I'm building a view, I rarely care about a widget hierarchy; rather, I just want to construct some html, inject some css, and attach some event listeners.
Writing my business logic in java means I can share it with web, android and ios (via j2objc); for that web view, I'm building html, and rarely need the abstractions provided by widgets. If I do need widgets, I usually use a composite with ui binder so I can control the html myself anyway.
If you want IDE based debugging for sourcemaps, please see http://github.com/sdbg/sdbg which is a sourcemap (super dev mode / draft compile) based eclipse plugin, for making java debugger speak chrome debugging protocol.
The project needs more users to try it out, report reproducible issues, and drive its development.
Smart clients reduce server load, and allow increased scale; why pay to make your server turn models into HTML when you can just send the model to the client and let it deal with it however it wishes.
For us at Appian, we use the same models and APIs for web, android and IOS; by having a smart client, the server only has to care about the shared model and executing requested instructions; it doesn't care how the client renders the result, nor should it.