This sounds like a terrible idea. It shouldn't be necessary to put so much crap between the language I write in and the code being run.

If you want to write games that use the new HTML 5 stuff and avoid Javascript, I think it is well worth it. Since the WebGL and all that will be part of (or at least available in) every major browser it will make the distribution easier (in my utopian fantasy world).

Why do you even care about the "crap" between? It's just cross-complilation (or really source to source translation). If you just want that part you can extract that from the GWT source code.

Yay! Looks promising indeed.I changed the first demo to use 200 sprites -> ~ 3 fps. But I don't think performance is very important at this stage.A service like 'compile 'n shrink' would be cool, where you paste some Java code and get the translated JS page... (and Exceptions).

Why do you even care about the "crap" between? It's just cross-complilation (or really source to source translation). If you just want that part you can extract that from the GWT source code.

In general, I would like to avoid overly complex solutions to non-problems. I would just use JavaScript before something like this. It is just simpler and closer to the metal. Simple apps are probably fine using this crazy stuff, but then why bother with this crazy stuff? I would hesitate to use it for large apps because the commitment is large and the complexity seems unnecessary. The risk I would ever have to debug or profile code generated JavaScript turns me off.

I would just use JavaScript before something like this. It is just simpler and closer to the metal.

That's the first time I've heard "javascript" and "close to the metal" in a sentence before.

Although I agree with your main point - this kind of things just adds yet more layers of pointless, performance-sucking crap between code and actual execution. Javascript is already waaaay too removed from the actual computer to be useful for anything other than visual frippery and toy apps.

Javascript is already waaaay too removed from the actual computer to be useful for anything other than visual frippery and toy apps.

It's really no different than Java. The functionality of the language is powered completely by the evnironment/libraries given to it. E.g. the WebGL-based Quake demo running on Google's JIT'd v8 engine runs faster for me than Jake (which it is ported from).

It's really no different than Java. The functionality of the language is powered completely by the evnironment/libraries given to it. E.g. the WebGL-based Quake demo running on Google's JIT'd v8 engine runs faster for me than Jake (which it is ported from).

Except that Java has a huge standard library that actually lets you do system-level tasks, and isn't hobbled by trying to run inside a 3rd party browser (applets not counting, they're only superficially in a browser, not tightly coupled to it like HTML5 + JS). And even then you still need to dip into native code to actually get things done (ie. LWJGL, JInput etc.). WebGL isn't a viable alternative yet and probably will never be for high-end graphics (ie. not just vanilla GL 1.4 or whatever), and you don't have the alternative of dropping down to the OS layer for when you really need it.

The risk I would ever have to debug or profile code generated JavaScript turns me off.

You don't have to debug the generated code. You just use the regular debugger in for example Eclipse (if you use the GWT Eclipse plugin).You just do whatever you do when you develop normal Java applications. A lot of the classes from the standard class library are supported like collections etc.

The official version from Google: All this effort from Google is because they like to use IDEs like IDEA, Eclipse, Netbeans etc. They simply love the tools that are available for Java and they want to abstract away most of that browser-specific Javascript. It is not because they don't like the Javascript language. It is because of the lack of good development tools and the issues with several different browser implementations.

HTML5 and JS in it's present state, while technically interesting isn't practical for any serious development work IMHO.

I disagree. GMail, Google Maps, Google Docs (pretty much anything with Google in the name), Microsoft Office Online and lots more are examples of very sophisticated sites and web-applications which run without HTML5.

With HTML5 there is no reason why lots of the excellent sites that heavily use Flash (such as the BBC iPlayer and Grooveshark) couldn't be built with it (and certainly will be in the future regardless of what happens to Flash).

The problem with my examples is that they are in the minority. The average desktop application today does tend to run better and be more sophisticated then the average HTML+JS powered web-application. Part of this is performance but part of it is also a lack of good frameworks and libraries. But I believe we are on the verge of seeing this change.

I've been unimpressed with the speed of javascript when using Google docs spreadsheets. It's dog slow, even a paste takes about 2 seconds. And that's on Google Chrome browser. MS excel is way quicker...

The average desktop application today does tend to run better and be more sophisticated then the average HTML+JS powered web-application. Part of this is performance but part of it is also a lack of good frameworks and libraries.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org