One more note --

I believe that the only time code generation should be used is when the source and target languages offer different abstraction levels. If the source and target language offer a similar abstraction level, then the intent of code generation more likely than not becomes to sweep something under the rug. And sweeping things under the rug is never good, imo.

It makes sense for compilers to translate high level languages into lower level ones. It also makes sense for decompilers to do the reverse. But if you're not jumping across abstraction levels, you really should not be generating any code, imo.

I don't hold to the above dogmatically/religiously, but when I hear "Java-to-Javascript compilation", then a red flag goes off in my mind.

I'm a little skeptical about this approach. The issue is that with GWT what you debug is not what you deploy. Yes, Java is easier to debug, I agree...but the point easy Java debugging is kind of moot if you don't deploy Java. So the feature is also a problem.

I think Javascript is a nice enough language that's worth learning and using directly.

Also, I read somewhere that GWT test browser phones home to Google when you use it. Maybe now that it's open source someone can patch that out. But it's a little fishy in my opinion, if it's true.

In my experience, frameworks that depend heavily on code-generation are crappy, because they are using generation to hide some kind of flaw that should be addressed directly rather than with a tool. So, my feeling is that this approach is "guilty until proven innocent". So I think I'll let other people be the guinea pigs for this one.

GWT seems like a heavy-weight framework, with its own test browser, compiler, etc.... You really have to buy it wholesale, it seems. I prefer light-weight yet elegant and clever approaches that are transparent and KISS-compliant. Just because something is written in few lines of code and doesn't come with a compiler doesn't mean it's not powerful. It's all about the amount of thought behind it, not in the amount of code and tools that ships with it.

Leo's concern about code generation reminds me of my early experiences with COBOL. Because of inherent insecurities in the language (e.g. no bounds checking on arrays), debugging sometimes required the ability to read assembly-language-oriented coredumps (write in COBOL but debug in assembly language). However, I do not have this problem with Java, even though the compiler is a code generator for the interpreted bytecode. So the appropriateness of the GWT's approach really depends on how well the abstraction was thought out.

Leo admits that it's valid to generate code from a higher abstraction level to a lower one. Though Javascript is indeed a high level language, the same cannot be said for XML, HTML and CSS -- which are key part of the browser's execution language. So code generation does seem to me to be the correct approach. There would be a value to this approach even if one doesn't care about AJAX. It has long been established that the abstraction facility offered by full object orientation with inheritance can facilitate code re-use. Browsers require HTML, which is NOT object-oriented. Webmasters deserve an object-oriented notation that eliminates the need to write in non-OO notations such as HTML, CSS and XML.

Instead of having the developer write in Java to generate the HTML, CSS, XML and client-side JavaScript, I suppose Google could have built tools that let the developer work in (equally high-level) server-side JavaScript. However, server-side JavaScript is much less popular than Java, so again I think they made the right choice.

I'm a web developer for many years.
It seems to me , that it would be best if there was an IDE which provided the following:

1. A real good javascript support (the same you get with other languages , like eclipse for java)

2. Client side widgets pallete (dojo for instance) with real WISIWYG

3. An easy integration of your server side objects to your widgets

4. A "debug mode" and "production mode" (production mode will compress and optimize your javascript)

I think the place for browser specific code is inside the widgets , dojo , for instance does a beatiful job.

I think that making the whole suff to be in java is to extreme! I would much rather the aproach I suggested

Very cool to be able to unit test my javascript code before it ever hits a browser.

My main complaint is that the tool-chain is very limited in it options (output for instance).

For instance, a Maven 2 plugin has been developed (can be found in the codehaus sandbox), although its not very mature... however because the compiler is so limited its very hard to get it to do things "The maven way"...

GWT converts java code to java script,
What would be the size of the page when we convert 5kb of java file, because the efficiency of page is always on the loading time.