But I thought the future was now ;-)

I question whether it's really a matter of optimization. Even on the best modern desktop browser with the most modern JS runtime, JavaScript is going to run 5-10x slower than C. On top of that, consider increases in memory usage.

Mobile hardware is likely to keep getting better, but it's not magically going to make HTML5 games run well on mobiles. For that to happen, a few things are needed:

Magical improvements in JS runtime performance to bring JavaScript closer to native languages. You can at least count on JavaScript to continue getting faster, but there may be a wall somewhere. You may also have to rewrite your JavaScript to use new features and libraries to approach native performance, which isn't free.

Reductions to the amount of work mobile JS runtimes need to do. Right now all the JS for your HTML5 game has to be loaded, parsed and compiled on every run, and doing that is pretty slow on a mobile CPU.

JavaScript and related libraries (like WebGL and Canvas) need to provide good support for concurrency so that you can utilize the multiple cores available on bleeding-edge mobile devices. Clock speeds on individual cores of mobile devices are not likely to reach desktop heights and if you look at desktop trends, even if they do, they won't ever get much higher. Right now, you've got web workers, but they're too limited to be of much use in games (especially if you care about power consumption).

Improvements to power consumption in mobile HTML5 implementations. Even if you can barely hit 60FPS with your pure-javascript algorithm in a mobile browser, it's going to drain your battery a lot faster than a native app that's running 5x faster and letting the CPU/GPU sit idle when they have no work to do.

Yeah, some good points I guess. But the fact we make an engine lots of games use makes it a bit easier: if magical improvements in JS appear which require some tricky changes to take advantage of, we can do the hard work in our engine and all the games benefit from it. But yeah, probably will always be a bit slower. 2D games don't tend to have really complicated logic though.

> 2D games don't tend to have really complicated logic though.

Your demo asteroids game certainly doesn't, but what about a 2D game that's actually worth playing? Things like physics or flocking algorithms are going to be very expensive in JS.

Exactly. People think that because we can have some completely unimaginative stuff with ideas from the 1980's that HTML5 is ready to be the future of browser gaming. And then when presented with the problem of complex physics, the solution is of course to add a special extension to browsers to handle physics. It's no wonder the browser is decades behind the desktop with myopic thinking like this.

You're right physics uses a lot of CPU, but I don't think games not using physics are automatically not worth playing. Did you see this platformer? http://news.ycombinator.com/item?id=3192719

I don't think presenting a retro platformer (which, FWIW, crawls here in FF 8) really argues your case much. Why should developers go back to making simpler games to get adequate HTML5 performance when they could develop directly for the target platform and use the hardware to its full potential?