miscoded

...and I used to think THIS was stupid

WTF!
I failed to find anything in 10 minutes span...
Yeah, not funny at all.

Holy Moses! You got to be kiddin'?

I found http://code.google.com/webtoolkit/documentation/examples/helloworld/com.google.gwt.sample.hello.Hello.nocache.html and then http://code.google.com/webtoolkit/documentation/examples/helloworld/8570D0CEE2F6DB7621202B4453ABF021.cache.html which seems to be the page for Opera, but then I got lost...

It is located within the script tag within the hidden iframe. This iframe is apparently injected into the page by the gwt.js script. Correct? :)

well this is what you get when you tell people:

It's okey to write java code and we will transform that into js code.

Originally posted by Jere:

...and I used to think THIS was stupid

!!!!!!!!

I know that some people prefer to write in Java over JavaScript but this is just stupid. How hard could it be to translate:

import com.google.wtk.browserom;

class Test extends WebPage {
public static void main(String[] args) {
window.alert('Hello World');
}
}

to

<script>
alert('Hello World');
</script>

Well, I do prefer JS but please consider that GWT is much more than just a "Hello World" example. My company is already evaluating GWT as it has nice set of widgets (not to be confused with Opera widgets) and is easier to connect Java-faked Javascript frontend with Java-based backend.
Anyway please do not make statements right after seeing one silly example.

Well, I'll probably use it for intranet app so only Opera and Firefox are considered
What I say is that I also prefer pure Javascipt, which I know better that Java. But webapps are getting complex than one could imagine few years ago. Maybe it's time for frameworks, another abstraction layer, magic box. Maybe one day one will write in his CV that he knows GWT, propotype, jQuery, not the Javascript. I hope not but the future will tell.
I do not understand exacly what's "under the hood" of PHP to use it. And when I discover bug in PHP I go to bugtracker not to C sources. So when GWT will not work in IE8, Google should be the one who will fix it not me. Heh, but this world isn't perfect

Anyway I understand that GWT sources debugging can be a hard work. And seeing how different Google services work in Opera I could only wish you luck...

At least this is easier to understand than the 81KB of obfuscated javascript that ships with ASP.NET AJAX

When I present GWT at conferences (including one recently in Oslo, which seems like a very cool place, btw), I always make sure to mention that you wouldn't really gain anything by writing something as simple as "Hello, world" using GWT. Out of context, the output does indeed seem silly. But it is a mistake to extrapolate from that a conclusion as to how effective GWT is for larger AJAX apps. That seems to be happening here, which makes me want to clarify a little bit about the engineering philosophy of GWT.

When you start to build up a larger code base, GWT compiler optimizations really start to have a very positive impact on size and speed that couldn't be achieved easily with handwritten script. There is an entire class of optimizations (e.g. dead code elimination, polymorphism removal, inlining) that stem from starting with the Java language (because it has a static type system). So, while "Hello, world" is ~25K (hilariously large, granted), please also note that "Kitchen Sink", which includes *all* of the GWT widgets, is only 95K in the latest version of GWT. Because of compiler optimizations, the marginal size cost of additional code is very small. This benefits the code you write with GWT, too.

If you actually want to understand what makes GWT tick, please take a minute to read "Making GWT Better", our open source charter at http://code.google.com/webtoolkit/makinggwtbetter.html

I'd like to think that people are at least evaluating GWT relative to its actual aims rather than in a vacuum.

I'm sure toolkits such as GWT and ASP.NET AJAX have their merits: for instance for serverside developers that don't want to bother with clientside technologies but still want to slap on a Web2.0 label on their products because it sells better

All in all these toolkits are still a big black box when it comes to the clientside code; nothing more than mere code-generators. Essentially at the end of the day it doesn't really teach you anything or stimulate you to actually learn a new technique. It's just point and click et voilá (look Mum, I can do javascript!).

Although these generated javascripts probably do a pretty good job at abstracting most differences between browsers (although browser-sniffing is an absolute no-go, Microsoft has already made that mistake before) there is absolutely no guarantee that it does a perfect job nor that the compromises made are really necessary (why does GWT use iframes iso XMLHttpRequest? To support browsers like IE4?) or that it actually plays nice with other javascript libraries. The clientside environment (browsers) is not homogenous like the serverside so eventually you are bound to run into a problem (abstractions leak) and then you get the QA nightmare Halvord is talking about and no-one there to solve it for you (because with GWT management decided not to hire a clientside expert since the serverside boys can do javascript just as well - how does that add to the stigmata?)

In that sense javascript libraries like DoJo and Prototype are the real toolkits: they provide you with the hammer and saw and you use them to create something nice out of a piece of lumber. GWT is more like a box of Lego that comes with a manual that tells you what you can create and how to create it, but when you want to create something different you will soon run out of suitable building blocks.

It's totally understandable to fear, upon first impression, that GWT's compiled JS may be hard to debug. We've all rightly become suspect of naive "code generators".

However, the GWT team has gone to a lot of trouble to make sure that this is not the case with GWT: we *never* want developers to have a problem and be stuck. I'm happy to say that we hear few complaints from users regarding debuggability of the compiled JS, and it's because once you actually use GWT, you realize a few things:

1) It is extremely rare that you ever do *need* to debug the compiled JS. Robert Hanson explained his experience in a GWT Round Table podcast (http://javaposse.com/index.php?post_id=140955). The first week you use GWT, you're constantly afraid that something is going to blow up and leave you very confused. But it really does work as advertised, so after that, you start to relax and actually enjoy the additional leverage.

2) A big reason people seem to be worried about GWT emitting debuggable JavaScript is that (a) they like being able to debug and (b) they have always written in JavaScript, so they equate "debugging" with "debugging JavaScript". But when you use GWT, you can debug using powerful full-featured Java debuggers to debug the same code (as Java source) that you would have otherwise had to debug using a JS debugger. So, the question is not "Is my GWT app debuggable?" The question is, "Do I want to debug mostly using a Java debugger or a JavaScript debugger?" GWT gives you the option to do both, focusing on whichever you prefer. (Of course, when explaining GWT, we emphasize Java debugging since it's hard to deny the richness of the typical Java debugging experience.)

3) You can instruct the compiler to emit unobfuscated JavaScript. (After all, how do you think we debug the compiler :-)? You can use
- style OBFUSCATED [nice and small]
- style DETAILED [verbose but very precise]
- style PRETTY [a good mix: readable without overwhelming detail]

4) Abstractions leak, we know that. This is how we described it in "Making GWT Better",

"GWT is not an attempt to abstract away the browser from you. Neither is GWT an attempt to prevent you from writing JavaScript when you want to. GWT is simply a way to give us developers some extra leverage in the form of productivity tools and the ability to create higher-level abstractions when it's useful. If you're a JavaScript guru, we hope you'll find GWT is a great way for you to package up your best JavaScript work and make it easy to reuse."

So, by explicitly not trying to hide the details of the GWT UI from you, you hopefully don’t feel surprised about the how the JS code works under the hood. This helps you use GWT more effectively and reduces the odds that you’ll feel stuck when you encounter bugs.

5) You can write as much JavaScript as you want to and integrate it easily into your Java code base. See GWT’s JavaScript Native Interface (JSNI) at http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.JavaScriptNativeInterface.html

6) The GWT compiler is a real compiler, not a dumb source-to-source translator. We even parse the handwritten JSNI code, check references between Java-to-JavaScript and vice-versa. (Parsing the JSNI code also lets us safely obfuscate your handwritten JS.)

Here's a decent way to summarize all of the above: we view GWT as a form of leverage, not "Java language vs. JavaScript language".