Asm.js is no more an open standard than PNaCl. While I'm sure others disagree, PNaCl is much cleaner in design and with more predictable performance. It's the one I'd like to see win.
There is also a spec for asm.js and a relatively small API footprint, making it an open standard, albeit one not (yet) sanctioned by ECMA.
asm.js is indeed a smaller API. I guess extreme pragmatism is what has been driving the web, but it can be argued whether that's great or terrible :(
They want the best game that maximizes the bang for their buck. None of the proposed web solutions do that, although NaCL promises access to more system resources than asm.js does.
But yeah, I'm sure it's just because all code-in-the-browser technologies are doomed and asm.js is too, not because Google's execution was completely incompetent.
Why are all code-in-the-browser technologies doomed? I'd really like an explanation, especially since you have a stake in the game (JSIL).
I think PNaCl was announced (as a long-range project) before ChromeOS was, and I'm certain it was announced before there were any actual Chromebooks, muhc less a concrete disconnect between ARM-based and x86-based Chromebooks.
It was created to solve the problem of high-performance software being tied to a particular native platform, which was clearly an issue for Google's long-term vision of web-as-dominant-platform long before there were concrete issues of different platforms for Chromebooks.
Actually, it works outside of the Web Store, but turning it on outside of the CWS is behind a defaults-to-off flag in the Chrome's settings, because Google didn't want NaCl code getting deployed widely on the web, because they didn't want code that would be locked to one architecture being widely deployed when they knew the plan was for PNaCl to be the long-term replacement.
Yes, the fact that Google choose to limit it specifically to prevent it from being widespread in the market contributed to its limited use in the market. But then, since its purpose wasn't to be widely used in the market (hence the restrictions imposed) but to validate technology and components for PNaCl, that's not really that surprising.
They don't need to use the "use asm" directive. There are many ways to optimize the asm.js style of code.
The important part is that it is not something that needs standardizing. It is a subset of JavaScript, nothing more. The output of other compilers like GWT is also a particular subset of JavaScript, and for years now browsers have optimized in varying degrees for many such subsets.
Chrome currently crashes because Chrome can't handle enough variables per context. This is a bug with V8 that is allegedly getting fixed.
It wouldn't surprise me if mobile support is currently minimal to none though; but this is something that can and almost surely will change independent of asm.js optimization support.
(And this is the Unreal demo specifically - smaller projects should be supported by virtually any modern browser* as far as I know.)
* Caveats: IE doesn't support WebGL, etc.
If PNaCl were "just" coupling LLVM bytecode with some defined way of invoking existing browser APIs from within the bytecode, this would be a whole lot easier for browsers other than Chrome to support. But that's not what they're doing, or at least, not yet.
I'm not sure there is a great chance that other browser vendors will adopt LLVM, especially Microsoft. It will basically require them to not only reimplement the native compiler but also the frontend that compiles to LLVM bytecode and any additional SDK tools like a debugger.
Asm.js is a lot easier to implement on every level. It will be served compressed so there wont be a lot of size overhead compared to a bytecode format. If you just use asm.js to call into webGL or audio apis there shouldn't be any big performance difference over using something lower level like PNaCL. Additionally, different browsers may use different optimizations when compiling LLVM code, differing implementations will give different performance characteristics. PNacl is no different than asm.js in requiring that the compiler be optimized.