It works just fine in Safari. You know, without any special treatment from Apple for asm.js optimizations.
I was sceptical but this shows that asm.js is a much better approach than Google's ActiveX wanna be solutions.
I was sceptical but this shows that asm.js is a much better approach than Google's ActiveX wanna be solutions.
Yeah yeah I get it. I like asm.js as much as the next person; I just wish this whole PNaCl-is-ActiveX meme would seriously go away. It's willful ignorance.
FWIW, I think it's fantastic that asm.js is turning out great. I also think that PNaCl is a worthy technical achievement. Two ways of solving the same problem given different constraints. I think Mozilla has a better chance and agree with their reasoning re- browser compatibility and third-party adoption. Still doesn't mean I'm going to go around calling PNaCl ActiveX when it clearly isn't.
https://developers.google.com/native-client/dev/pepperc/grou...
That said, I support using LLVM bitcode more than asm.js myself. I think asm.js is the dying breaths of JavaScript being hailed as its rebirth.
I think asm.js has technical advantages over LLVM bitcode. Neither were really designed for this purpose (for LLVM, you must strip the undefined behavior; for JS, you must strip the high-level semantics), but at least JS has a fully specified, multi-vendor standard specifying the execution semantics. Plus asm.js has a very minimal type system and is non-SSA (while retaining high-level loop constructs that can be easily used to construct SSA without dominance frontiers if needed), both of which I think are advantages for delivering bytecode over the Web.
I think that may be a false dichotomy.
Not sure that's fair: https://developers.google.com/native-client/dev/reference/pn...
But even if all of those things was true, that makes it ok to call it ActiveX? By that logic I can call Firefox IE because it implements extensions to JavaScript that have not (yet) been standardized. But that wouldn't be fair and neither is calling PNaCl ActiveX.