I'm so psyched by the idea of games in HTML/JS. I've made a few games in Canvas myself using Processing.js: http://games.zetabee.com/ but frankly I'm amazed at the Akihabara games. I realized Processing.js was cool but I don't think it lends to raw speed as well as these games. I think I'll be making a lot more games in JS in the near future. Thanks for this link sandaru1.
Edit: Having looked into the source code... wow! For the "capman" game, he's creating the game map using ascii art and his "help.js" library has a function just for that: asciiArtToMap. This takes me back to the early 90s when making games meant you had to bitblt sprites and worry about every byte in the RAM. His library is great if you want to make sprite-based 2D scroller-type games but I don't know if it is easier to roll your own mini-library or use his for other types of games (e.g. puzzles). However, the source code itself is very extensive and I can certainly see the gamebox.font library being very useful for JS games.
Doing anything in JS and Canvas seems exactly like programming in the early 90s. I think Commander Keen on a 386 may have had more performance headroom than this! This is what is supposed to save us from proprietary tools like iPhone and Flash? I really don't get it.
Programming in the early 90s felt like the Wild-West - anyone could strike gold, anyone could make pickaxes, and anyone could build a town around a set of rail-tracks. Almost all of the large game companies today started as small programming teams in the 90s. I don't know what could be more exciting for startup.
The fact that feature-rich tools, IDEs and libraries don't exist for JS/Canvas games is EXACTLY why I love it. There is so much opportunity here for those who love to build and innovate. If you don't believe that JS/Canvas has a future, I can't change your mind. But if you think that there is a future for browser-based games running JS, then this a very exciting field to jump into.
Before prototype, mootools, and jQuery etc., JavaScript frankly sucked. It was alerts, statusbar texts, and title bar changes. I see Canvas being in that category right now. There is a lot that needs to be done before you will see a thousand "Top 10 tricks to speed up your Canvas game" posts but that's exactly where the most exciting part lies.
> "JavaScript sucked until people figured out what it could do."
Actually yes. Do you remember any amazing JS apps from 2002? IE6 has been around since 2001 and even on slow machines, it can still run most of the JS apps (provided you make the fruitless effort to support it). Where were the JS apps in 2002? Only things people used JS for were form validation and annoyances.
I know these frameworks are written in JS. What I meant to say was that very few people had actually used JS to its full potential and capabilities till just 5 years ago when protoype/scriptaculous/RoR and apps like Google Maps started to show up. I wrote an Ajax-enabled app for IE6 in 2003 and it was so much more work than $.ajax({url:foo,callback:bar});
I think all the hubbub is because the browser has dominated computing in the past decade. Being able to play a game on both your web browser and your smartphone with only minor changes (input, screen scaling, and perhaps locked fps) is a big deal because everyone knows how to use a browser and the barrier to accessing your game is as trivial as currently possible. Having to actually install a game, even if it's just downloading and running an installer, is apparently a lot more annoying to users than you'd think.
Unless some kind of native backend is written to make HTML5 apps just as responsive as plugin-based ones, I don't really see how this is going to be successful for games. The performance hit is just too gargantuan.
I think the performance won't be a big problem in the foreseeable future. There's some great competition going on between Safari, Chrome, Firefox and Opera. With every new version their Javascript engines get faster and with the coming WebGL we'll have hardware accelerated drawing in <canvas>.
This competition is precisely what was missing for Flash.
I think that Javascript, the language, itself has barriers to performance. I think few programmer know, for instance, that a dictionary lookup is 100 times slower than a switch statement. (If you don't believe me test it! It's what I found under Firefox anyway.) The language absolutely begs for a real map type... Objects just don't cut it because of performance (it has to be concerned that someone might have extended the Object prototype) and because of their limitations, e.g. confusion if someone defines a key string called "hasOwnProperty".
If you actually try to use some of it's nice functional features, as well, you can forget about performance. Maybe you think engines can solve these things, but I doubt it will ever compare to any language built from the ground up to have reasonable performance.
Even so, browser games as-is are bottlenecked by render performance, not language performance; both platforms are capable of running Quake(1 or 2), but JS holds the advantage as far as running it at reasonable resolutions and framerates, while the Flash implementations are hobbled by software rendering.
This should be easy to fix with a 'configure my controller' option. They could let you choose which keys do what for their game, and maybe show the most common configurations as options before you make your own.
Between this and the Apple iAd demo in HTML5, which notably demo'd pressing the screen and getting an 'inline' audio response instead of throwing you into a media player, a basic feature of most simple games currently missing from Mobile Safari, I think this is just about to get interesting.
Was excited about trying a demo on my iPhone, but seems the demos are all keyboard only. A mobile demo would go a long way since that's a reasonably big use case.
Edit: Having looked into the source code... wow! For the "capman" game, he's creating the game map using ascii art and his "help.js" library has a function just for that: asciiArtToMap. This takes me back to the early 90s when making games meant you had to bitblt sprites and worry about every byte in the RAM. His library is great if you want to make sprite-based 2D scroller-type games but I don't know if it is easier to roll your own mini-library or use his for other types of games (e.g. puzzles). However, the source code itself is very extensive and I can certainly see the gamebox.font library being very useful for JS games.