[JoshTriplett]

While I'd like to see asm.js implemented for compatibility, I greatly prefer native code over compiling to a JavaScript subset in the hopes of getting something vaguely resembling the original code back.

I understand why other browsers don't implement the Pepper API, because it's highly Chrome-specific; however, I'd like to see other browsers implementing the native-code sandbox, at least.

[vesinisa]

Asm.js has several benefits over NaCl. It's readily compatible with just about every browser in the market, and manufacturers just need to add some asm.js-specific optimizations to their JS runtime to fully unleash its execution power (but Chrome too already runs asm.js code very fast with just its generic JIT optimisations).

Secondly, it's based on a self-contained open source spec that constitutes a logical subset of another widely-supported open spec (ECMAScript) - no convoluted, versioned APIs coordinated by large, possibly competing and mutually incompatible engineering efforts. The asm.js spec is actually so simple it fits on a single web page: http://asmjs.org/spec/latest/

Yet it pretty much manages to achieve all that NaCl does by being also forwards-compatible with all the DOM-based extensions like HTML5 without needing any additional APIs (many asm.js demos for example bind to WebGL - this does not require any additional "asm.js API", as the browser's existing WebGL implementation suffices)

[JoshTriplett]

As mentioned in my previous comment, NaCl and Pepper are not the same thing. Browsers could support NaCl without committing to support Pepper.

> Secondly, it's based on a self-contained open source spec that constitutes a logical subset of another widely-supported open spec (ECMAScript) - no convoluted

I'm going to have to stop right there. asm.js is a lot of things, but "not convoluted" is certainly not one of them. asm.js involves compiling native code to JavaScript in the hopes that browsers will translate it back to some semblance of the same native code.

[vesinisa]

The level of "convoluted" depends on which level you want to look at. The asm.js spec is dead-simple, almost purely "mathematical" if you like. But if you require that whatever GCC/clang would have outputted for a specific C file is the exact same binary code that gets executed in the browser, then yes - you are not getting that. But then again, asm.js just - on a high level - specifies the primitive low-level constructs that C/C++ programs employ. Mapping them to instructions is a pretty straightforward job, but of course you are not getting 100% exact same results on every browser - just like you are probably not getting 100% exact same results from clang and GCC for the same C source code.

[JoshTriplett]

It's more that I'd like browsers not doing an absurd amount of unnecessary work and overhead. Leaving aside opinions on JavaScript as a scripting language for humans, it's not a sensible intermediate format for compiled binaries. It happens to work as a (very impressive) hack.

[acqq]

Even if it doesn't appear to be for those who don't consider the whole context it's a reasonably effective intermediate format. The current success of it among the vendors proves that.

[cwyers]

But supporting NaCl without Pepper means no existing NaCl apps will work, so you have to somehow hope that NaCl apps without Pepper will be written.

[JoshTriplett]

Have to start somewhere. In the interim, people will use it to build compatibility layers for the Pepper APIs, such as a better pepper.js (https://trypepperjs.appspot.com/).