[drblast]

"Best performance" is irrelevant if the performance of javascript is good enough.

Maybe this illustrates the dichotemy between traditional engineering and computer science, but in most other forms of engineering you want just-good-enough-to-fulfill-the-requirements because any better means you are spending extra money or doing extra work uneccessarily.

If javascript lets you write a game that runs at a solid 30 frames per second, and write it easily and portably for free, any additional performance is overkill.

For many of the simple types of games people play in a web browser, javascript has been good enough for years. Increased hardware performance will only help javascript.

http://drblast.sourceforge.net/tetris.html

[justncase80]

I'm sorry but tetris isn't exactly state of the art in game design these days. We already have tons of games that javascript/html simply cannot even come close to handling. Naturally people are starting to think about how we can get there, while maintaining all the benefits of a dynamic runtime. So the point is that what javascript is today is not good enough, thus the exploration into how to make it faster.

[talmand]

Just to expand, in most cases 30fps is considered the minimum while 60fps is your target. Most people cannot see the benefit above 60fps. As browsers start using the GPU available on the device in hand then 60fps should be easily attainable; unless you're doing something crazy complicated.

[jiggy2011]

I think the problem comes as soon as you need to do any floating point work within the Javascript VM , not sure what javascript FP performance is like but I guess it's not pretty.

[gvb]

In addition, it has no performance on all the devices that don't support ActionScript at all (iDevices and most Android devices) or where it is abandonware (a few Androids).