Cross-compilation to Javascript is the only mechanism for getting new languages on the client VM. Javascript is the only available entry point to V8/TraceMonkey/SquirrelFish’s underlying JIT/VM infrastructure. You don’t just see this with GWT, there are projects that compile Python to JS, Ruby to JS, hybrids like Objective-J. “JS as assembler” is not going to go away until this issue in the browser platform goes away. We are wedded now to decisions made in 1995, which may have been the most efficient way back then, but in the era of super-advanced VMs like V8 look silly. Why should V8’s internals remain tightly bound to a single input syntax when it could be used for other languages?

On GWT, it is a cross-compiler, and in that regard, there is nothing stopping the GWT team from adding new frontend languages in time. I could forsee a future in which GWT can compile Scala, and other languages to Javascript as well, but not until the Java compilation has reached its limits, which it has not.

I don’t see the issue between HTML5 and GWT. HTML5 covers the markup, and DOM APIs. GWT can interface to any of these and do so with no overhead whatsoever. The fact that it made feel weird to you is an emotional or aesthetic observation, not a practical one. There are people who may feel that certain constructs in Javascript are ‘weird’ too. I don’t see any legitimate criticism.

The reason why you don’t ship down a JAR and run it in the Java VM is precisely because of the way GWT works. It is a static ahead-of-time compiler that operates on a closed-world code base, which allows it to perform optimizations that can’t be done on Java bytecode traditionally. This means GWT can prune dead code away that would normally be shipped in the JAR.

GWT is all about end user experience, reducing latency. Shipping down a JAR full of byte code which can’t be optimized until runtime loading would defeat the purpose of saving bytes on the wire and startup time.

And, as I talk about in my latest post (http://timepedia.blogspot.com/2009/04/gwts-type-system-is-more-powerful-than.html) GWT is actually more powerful than Java. I can do things with GWT that you can’t do in Java, like add extension methods to types with zero-overhead.

App Engine isn’t a virtualized server, nor is it a v-host. It’s a different animal altogether. That being said – I don’t think you’ll be prevented from using DSLs, and going the lightweight route.

http://techblog.appirio.com/2009/04/early-peek-at-google-app-engine-for.html

I see where you’re coming from here — it *does* seem a bit odd to cross-compile from one “high-level” language to another. But at the same time, I don’t see GWT and HTML5 evangelism as being in any way antithetical to one another. GWT is simply a tool to help get leverage over a complex Java[script] code base. HTML5 is a collection of browser APIs that we either have already created abstractions for, or will be doing as soon as they’re prevalent enough to be useful. We *love* most of the HTML5 features here on the GWT team, because their adoption will increase the number of cool things we can do in the browser.

To reiterate a point I keep trying to get out there: GWT doesn’t use Java as a source language because we think it’s the greatest language in the world. It uses Java because (a) it has extremely good tools, and (b) its type system allows us to perform a lot of optimizations that would otherwise be impossible.

To your point about “other Javas” we could support, I’m pretty excited about Scala support, though at this point it’s more of a twinkle in Lex’s eye than anything else. The other languages you mention would seem less useful in this context, because their dynamic type systems would preclude most interesting optimizations — without a monolithically optimizing compiler in the mix, I’d just as soon write Javascript (opinions may of course differ on that last bit; you’ll find I’m the sort who will happily write code in any language that allows me to get the job done).

Allow me to humbly submit my blog post from last year for your consideration:
http://gwt-unofficial.blogspot.com/2008/12/gwt-javascript-and-correct-level-of.html

Cheers,
joel.

I would say that Google’s support for the would-be standards of HTML 5 is optimistic and forward thinking at best. GWT is realistic. Web standards remain a romantic notion. You could give Google credit for backing different strategies, or you could just rack it up to Google being a big company with a lot of different groups who do their own thing.