Yeah it’s ridiculously complicated:
http://www.pulpgames.net/milpa/pulpcore.js
It’s quite nice.
Personally, though, I’d never put a serious effort into making a serious game in HTML5. Think about it. It’s limited to running in browsers, the source code is readily available by simply doing view-source in the browser, and future-proofing your game will be a nightmare as years go by since browsers are continuously changing.
With Java you’re not limited by where you run your game, application or applet. The code is a lot safer. And if you bundle your application in a EXE+JRE you’re safer the game will run 10 years from now.
HTML5 is fine for most flash games out there, smallish web games, and that’s really where the fight will take place, between flash and html5. Java will be on the sidelines, pretty much unaffected, because if flash hasn’t already wiped java out by now, html5 won’t either.
I do wonder about the portability of html5 games/apps. I guess there’s no single embeddable package file, it’s all just html and javascript, that depends on the environment where it was loaded from? Flash has the advantage of being easily distributable and embeddable anywhere.
Btw. before posting screenshots/videos of your browser, be sure to clear out the Google searchbox in the browser 
It’s not limited to running in browsers. All you need is a JS engine, a Canvas/Audio/input implementation, and a little bit of wrapper code. The guy who made Biolab also wrote such a thing (it’s OpenGL accelerated and runs on iPhone). And of course there are other easier options like PhoneGap or XULRunner, which basically just turn some website into a stand-alone application.
If the code is minified it’s about as “save” as minified Java code. Not having to run it through a decompiler first doesn’t really change much. Actually, this step is replaced with running it through a formatter.
It’s the same thing, really.
The bare minimum is one script file and one resource file. But usually there will be at least 2 resource files. One which contains everything with audio as Ogg/Vorbis and another one which contains everything with Audio as MP3 (or AAC). The former is for every browser and the latter is for bloody Safari and f-ing IE9. Depending on the browsers capabilities one of those files will be downloaded.
The script file can be bootstrapping + game code or just bootstrapping (and the game code is in the resource file).
Actually, it’s the other way around. Put there some crap on purpose to get more views, comments, and publicity.
For bonus points open some extra tabs and run something like this:
javascript:document.title='filthy%20stuff';void(0)
to create some ominous looking tabs.
So, yea. It’s just some kind of guerrilla marketing. But it still works pretty well. I highly recommend it.
PulpCore is really great, both in API, design process and deployment (does half the job of Java Applet system). But still I had issues when I loaded the same applet in two tabs at once (in old applet system before 6u10+). I suppose now you could use the separate_jvm option in new applet system (now it’s probably much more widespread) and everything would work well 
I also recently looked at javafx.com and looked much more functional than before, they’re even not afraid to use JavaFX applet to select the demos (previously they used some DHTML crap).
Mind you Apple have done their level best to completely break applets anyway. Grr.
What, realistically, is the performance difference between Java 6 and the fastest JS engines out there at raw compute power and memory writes?
Cas
Dunno about realistically, but for at least some comparison look here, compare V8 with Java6 -server. Sadly there is no Java6 -client (but that’s probably not much relevant these days). The difference is still very big and I doubt it will be comparable to Java because of the dynamic nature of Javascript language.
It can be a pain to get javascript code to work the same in different browsers, let alone on totally different platforms. There will always be those hacks to get around variations between browsers, e.g. if(ie) { … } else if(firefox) { …}.
I’ve written a lot of javascript code for two different legacy set-top-boxes, who supposedly have the exactly same browser, but there are plenty minor differences that matter a lot. For instance, one box can run anonymous functions in a timer, the other cannot. One cannot handle a long integer, the other can, so if you were to use timestamps in milliseconds, you’d be out of luck on one of the boxes.
I’ve written a GUI platform in javascript that works great in Firefox, but I’d need months to get it working in Internet Explorer.
But perhaps that is all worth it. Javascript is pretty portable considering. It’s the most used and widespread programming language out there.
After writing it for 5 years, I still hate how bad the OOP support is. It’s like they’ve gone out of their way to not evolve javascript. It was never intended to be used so much, but it’s #1 out there, it was supposed to be used as a “helper” scripting language for forms and stuff, and therefore doesn’t even have basic OOP support. I’d really like to have classes, abstract classes, inheritence, polymorphism. I know you can simulate a lot of this stuff, but it just doesn’t feel right.
Hm I still wonder why no-one’s just made (experimentally) a browser that simply executes Java code instead of Javascript.
I see the benchmarks put Java at roughly 10x faster than Javascript which means I won’t be making Revenge of the Titans any time soon in JS. I’m already trying to figure out a way of using more than one core to get more performance out of it (just to achieve 60fps)
Cas
Unfortunately it’s the one of the first things that manifested the “java is slow” legend
that was a long time ago (16 years ago) in the dark days of dial up internet and slow low memory and cpu computers, I reckon it’d be much more successful if attempted nowadays especially with modern browsers.
Something like, just embed a headless VM in Chrome (ie. without AWT and Swing). Pop in a decent API for DOM twiddling. Maybe Jikes, to allow actual Java source to be used as script as well as bytecode. Allow script tag to reference a jar and a class with a main method. Fiddle with security to ensure pages are sandboxed. Add LWJGL canvas for good measure That’d be seriously amazing really and make Javascript based applications look like the slow and crappy bugridden bits of shite they currently are.
Cas
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=v8&lang2=java
Regular expressions are super fast with V8. Generally Java (server) is at least 3 times faster. On average Java is about 5 times faster. And if you do something JS is pretty bad at, Java can be over 40 times faster.
I rarely have any problems. JSLint helps a lot.
http://code.google.com/p/joose-js/
“[…] classes, inheritance, mixins, traits, method modifiers and more.”
Well, you can have classes and you can also have inheritance. Prototypal-inheritance, that is.
Ah yea… DOM manipulation. This wouldn’t be any faster with Java, C or C++. It’s so slow because it’s a super heavy operation. Reflowing (recalculating the layout) and redrawing are the slow parts. A faster language won’t help there.
(Thankfully you don’t have to touch the DOM for Canvas-based games.)
I was under no illusions about the speed of DOM manipulation, but what would be doable in Canvases would be, well… Minecraft
Cas
Well, that’s what I mean, it’s a shitmix. Horrible syntax in that joose, just look: http://code.google.com/p/joose-js/wiki/BeforeAndAfter
I don’t blame joose, I blame javascript.
Also, this doesn’t run on all JS engines.
Also, this doesn’t run on all JS engines.
http://code.google.com/p/joose-js/wiki/JooseAndOtherFrameworks
It even works in IE6. Why would anyone use an engine which is even worse than IE6’s? It’s over 9 years old and f-ing slow.
Well, I don’t use Joose. Prototypal-inheritance is enough for me, but I don’t even need that.
Java is great for big stuff, but most individual tasks I need to code with JavaScript is typically no more then half a page long. Like querying a page and displaying an error if it fails. With JQuery (or one of the other many JS frameworks) that’s a trivial number of lines (and I’d argue it’s far easier to read then using a Java alternative).
I personally would like to see a bytecode engine, probably similar to the JVM (plus it’s dynamic extensions) in the browser. JavaScript, Java or something else would then just target that bytecode. But I believe for most games the speed issues are currently with the canvas (especially on my Linux laptop) and not with JavaScript. Like placing certain content on top or even behind the canvas can have a severe impact on it’s performance in Chrome, FireFox and others (or at least for me). But all of the major browsers should be fully hardware accelerated (both canvas and the page) and adopted by the majority of people by mid-way next year.
Although there are still plenty of issues writing cross-browser JavaScript, I’ve yet to find any in regards to the canvas (although I’m sure some are out there).
Over the last year alone there has been plenty of development for using and improving; Flash, HTML+JavaScript and Silverlight. Over the next year I’ll predict that all of those (including even Silverlight) will get more improvement then Java applets (even if it’s just browser speed improvements). That is my main issue with using Java applets.
I’ve yet to find any [cross-browser issues] in regards to the canvas
The image returned by Chrome’s Canvas got pre-multiplied alpha. Fortunately this doesn’t really matter. If you want off-screen rendering you’d just draw that off-screen Canvas onto your on-screen Canvas (see: Off-Screen Rendering (Render to Texture) with HTML5’s Canvas Element).
createPattern and drawing that pattern is very slow in Firefox. If you translate and then draw some image it’s still pixel-snapped in Chrome. Both issues will disappear with hardware acceleration, however.
I go on and on about this… but by combining GWT with the HTML 5 canvas you can keep your Java, which is great for big things. The only major problem seems to be performance for non-hardware accelerated stuff.
Already discussed here:
http://www.java-gaming.org/index.php/topic,23216.0.html