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.
V8 is implementing optimizations for asm.js, as highlighted in Google I/O. (It is ignoring the "use asm" directive, though.) So there is some measure of buy-in from other browser vendors.
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.
V8 is fixing bugs they had that caused asm.js-style JavaScript to be slower than it needs to be. I doubt they'll honour the "use asm" directive in the near future.
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 :(
> V8 is fixing bugs they had that caused asm.js-style JavaScript to be slower than it needs to be. I doubt they'll honour the "use asm" directive in the near future.
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.
Winning what? If 500+ million NaCl enabled Chrome users couldn't set off a revolution in web gaming, why would asm.js? Reality is, gamers don't really care about what the implementation details are, and whether someone is distributed as web, or as installable download, or via Optical Disc.
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.
Well, for one thing, NaCl was a stunning failure because it required platform-specific compiles. For another thing, it only worked on the Chrome Web Store, and nobody gives a shit about the Chrome Web Store. It also didn't work on Android...
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.
> For another thing, it only worked on the Chrome Web Store
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.
I'm not going to criticize their thought process behind locking NaCl to CWS; from a standards and 'open web' perspective, that was a sound choice. That doesn't change the fact that it largely contributed to its failure in the market. The game devs I talk to on a regular basis wanted to use NaCl, but couldn't, because it was tied to the CWS.
> That doesn't change the fact that it largely contributed to its failure in the market.
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.
I'm pretty sure PNaCl was created to solve the disconnect between ARM based Chromebooks and Atom based Chromebooks. If it also works for Chrome on Android, I think that is a happy side effect, especially since PNaCl was introduced (through flags) in Chrome shortly after the Samsung ARM Chromebook was released. If you want to create packaged Chrome applications for the Chrome Store, you want them to work regardless of the machine architecture.
> I'm pretty sure PNaCl was created to solve the disconnect between ARM based Chromebooks and Atom based Chromebooks.
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.
asm.js is optimized for ahead-of-time verification and compilation. In this respect it's on an equal footing with PNaCl. Why would asm.js necessarily have worse performance?
Not really the same. Anything that implements standard javascript will be able to run asm.js code just fine, even if they don't implement the possible optimizations. The same isn't true for NaCL.
I know for certain that there are previous non-asm.js optimized builds of Firefox that run it fine (with a performance penalty, naturally.)
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.)
asm.js is a well-specified subset of things that are already pretty much standardized. PNaCl adds a whole lot of new stuff that has not been subject to community review, like (for instance) the entire input processing and rendering API. And it isn't yet clear which quirks are meant to be standard, as opposed to whatever happen to be accidents of the initial Chrome implementation.
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.
PPAPI itself is a Chrome only api at the moment. I'm really concerned about using a plugin api defined by its C/C++ behavior as some kind of standard. So we not only have the DOM apis but also another class of APIs that have their own quirks.
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.
