[azakai]

That can be true, but based on my experience in the game industry it isn't necessarily the case.

Often a game will be GPU-bound, in which case the JS, Flash and NaCl versions will all have the same bottleneck, GPU shaders (in fact for this reason more and more is done in scripting languages in game engines these days). If that is the case, you might as well use JS, since it will run in many more places than Flash or NaCl.

But again, there are situations where you are CPU bound, and in that case CPU speed does matter - you are very correct in those cases. Currently JS is indeed at a disadvantage compared to NaCl in that area, however, I believe that it will match it in time (through a combination of API additions like Intel's RiverTrail, and further improvements to JS engines like static analysis). The real question is then, will NaCl fix its problems (portability, adoption in browsers other than Chrome) before JS fixes its problem (speed). My bet is on JS.

[CyruzDraxs]

Yes, but NaCl provides direct access to GPU interface libraries. You can code for OpenGL directly, rather than running your graphics code through several layers of abstraction, slowing it down exponentially along the way.

There is, to some extent; hardware acceleration for canvas. But I don't expect that to be at all comparable to native OpenGL for awhile yet. JS has certainly had some significant advances in speed over the last few years, but there's only so much optimization you can do. It's still running in a VM, so there will always be that overhead.

Another important thing to consider is that the native API will always have to exist before a Javascript abstraction can. Many triple-a titles will use brand new GPU features to sell the newest line of graphics cards. That won't work if they are making a browser game and the required interface to do those things doesn't exist yet. Javascript will always be chasing the tail of native.

[azakai]

> Yes, but NaCl provides direct access to GPU interface libraries. You can code for OpenGL directly, rather than running your graphics code through several layers of abstraction, slowing it down exponentially along the way.

If shaders are the bottleneck, and not graphics calls, then NaCl and JS will be the same.

If graphics calls are the bottleneck, then sure, NaCl will be faster - but likely you need to do more batching in your GL code.

> JS has certainly had some significant advances in speed over the last few years, but there's only so much optimization you can do. It's still running in a VM, so there will always be that overhead.

NaCl is essentially also running in a VM: It's sandboxed, so it has performance limitations. There are types of code that run slowly in NaCl, just like in the JVM. However, VM code can be fairly fast in general, the JVM and NaCl are speedy on a lot of code.

The point though is that JS can be fast too - once it has as many years of effort put into it as the JVM and native compilers has, it will be. It's just still very new. "Being in a VM" is not the issue.