The difference between asm.js with and without special optimizations is not necessarily that big. See benchmarks here, showing it can be anywhere from 1x (almost no change) to 5x. It depends a lot on the benchmark. And in a demo like this, the GPU matters a lot too, which makes asm.js matter less.
So all modern browsers should already work on this demo. But this is a very large codebase (over 1M lines of C++ compiled to JS), and it pushes the limit of what browsers have tested on. Now that this demo is public, that should make it easier for other browsers to fix what they need so the demo can work on them.

It doesn't require special asm.js optimizations (asm.js is a subset of JavaScript, so it already runs properly in all modern browsers). The demo works fine in the stable release of Firefox for example, which has no special asm.js optimizations. It is faster in Firefox nightly though which does have those optimizations. But how much faster depends on the CPU and GPU, it might matter a lot or it might matter a little. In this demo a lot of time is spent in WebGL, so a fast GPU and good WebGL implementation matters a lot too.

The demo should work in any browser with WebGL and JavaScript support. For example the only reason it currently fails in Chrome is due to a bug related to memory use. Hopefully that will be fixed soon.

You can compile C++ to JS and run it on the web, using Emscripten. It supports SDL.

Here is an example 2D game ported that way: http://www.syntensity.com/static/mams/mams.html

Linux, NVidia drivers. 3D games and WebGL work perfectly here, so it isn't a problem with the hardware or drivers, must be something with their support I guess as you said.

Even if this ran, it took 600MB. That's huge, if it's ported from an iOS game it must take much less memory there. So I am very unimpressed by the quality of this port.

Looks broken. Takes very long to load, then takes 600MB and something seems to happen, but no polygons are rendered. Looks like just one ugly repeating texture for the ground, and a few bushes. I can pan around though but there is nothing to actually see no matter how long I wait. http://imagebin.org/206217 This port doesn't look very successful.

They ported it, but how well does it run? Until we see the demo in the wild, so we can test it ourselves, I am skeptical. Their demo machine is likely not a typical one.

The important bit is "eventual". Right now, NaCl is CPU specific, and it is indeed fast. But making it portable may diminish the speed, it is not clear how fast PNaCl will be when it is finished, there are numerous challenges - for example, the LLVM bitcode that is shipped is very large (bitcode is much larger than object code because it contains higher-level information), and it takes time to optimize before it is run.

Supporting NaCl now when it is CPU specific, in the hopes of it fixing its problems some time in the future, is a big leap of faith.

As for PPAPI, yes, it is BSD licensed. But open source doesn't mean it is an open standard, nor does it mean it is usable without an extreme amount of engineering; for practical purposes, it isn't in its current state - it's tied to Chrome internals, and cannot just be dropped in Firefox or Opera; worse, it is constantly changing to fit Google's needs (mainly driven by NaCl and Flash) - it's a moving target with no spec.

There has been a lot of talk about this in the past, the main issues that I recall are

• Pepper's goal is to enable plugins to do more things. But all web browsers except for Chrome are moving away from plugins and towards HTML5, there are no plugins in iOS nor in Windows 8 Metro for example. Implementing Pepper would take a lot of effort, other browsers prefer to look to the future and optimize HTML5 technologies. Even WebKit doesn't want Pepper in it.
• Pepper has a single implementation and no formal standardization documentation. Trying to implement it now means reproducing whatever behavior Pepper has in Chrome. Since Pepper has lots of methods and is quite complex, this would be a very hard and perhaps impossible task (since Chrome can keep changing Pepper when it needs/wants to).
• Pepper has been driven by two main use cases: Flash and Native Client. Both are technologies that only Google supports, all other browsers prefer HTML5 over Flash and oppose Native Client because it is CPU arch specific. With those two use cases out of the way, it isn't clear there is a reason for other browsers to implement Pepper at all

Actually if you download the Chrome and Firefox installers, you will see that Chrome is twice as large.

There are various definitions of "slimness", each browser wins on some, unsurprising because both of these are good browsers.

In addition to the ESR Firefox (which is basically like an Ubuntu LTS in how it works), Firefox 10 also marks addons as compatible by default. These two things solve much of the update annoyances.

FF11 will remove the UAC prompt on Windows, which will be a further improvement in 6 weeks from now.

A null pointer, if you dereference it, leads to a crash or possibly to a security vulnerability (imagine if you access a structure element, so it is an offset from 0). Whereas an actual, complete object who is treated as "the end" will not cause such problems.

Without null pointers, you avoid a lot of security risks and runtime failures, which are why null pointers are called "the billion $ mistake".

NaCl works through the Pepper plugin interface, which is a plugin API just like NPAPI is. So NaCl is most definitely a plugin, even if it is bundled in Chrome. For comparison, Flash is also bundled in Chrome, but it is of course still a plugin (it works through NPAPI).

You can't run them on anything that isn't x86 or x86_64, and it isn't clear whether we ever will.

But it is *not* designed to be portable to different CPUs. Try running NaCl MAME on your ARM or MIPS phone or on your PowerPC game console's browser - it won't work. This by itself makes NaCl unsuitable for the web. Not only can't we run it on non-x86 hardware now, it would make life harder for new CPU archs in the future.

(Yes, there is a research project trying to make NaCl portable to different CPUs. It is too early to tell if it will succeed, and what tradeoffs it will have in terms of speed, portability, code size, etc.)

LLVM is not portable, see for example http://thread.gmane.org/gmane.comp.compilers.llvm.devel/43769/focus=43770

It is very hard to try to make LLVM portable, which is what PNaCl is attempting. Maybe they will succeed, we will see in time.

Which is an interesting research project, but it's too early to say if it will achieve the goals of complete portability and full performance.