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.

This requieres Mozilla JS enhancements (asm.js) currently on nightly builds, It can work on other browsers but without the performance tuning made for the JS subset that is asm.js it will run slow. Chromium bug proposing to add support for asm.js http://code.google.com/p/v8/issues/detail?id=2599

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.

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.

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.

If it is, I'd like to see that pointed out on their Wiki pages. Right now, it simply mentions that they're not going to implement Pepper with no further explanation. When I go to the Pepper web site, I see all kinds of reasons why one would want to implement Pepper. If the Mozilla people just wrote a few words explaining the situation, it would make the situation much easier for confused users like me.

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

Firefox has launched a new version release system, creating an ESR for enterprises, organizations, etc. which is released once in 7 Firefox usual releases (Firefox 10, 17, 24, etc.), so that they don't have so much trouble (it must be horrible to find that two new versions have appeared as you are updating...). See a submission which didn't get to the front page for more details.

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).

Finally please note that you can't currently run NaCl properly on tablet devices.

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.)