<story><title>Asm.js: a strict subset of js for compilers – working draft</title><url>http://asmjs.org/spec/latest/</url></story><parent_chain><item><author>lucian1900</author><text>I&apos;d really much prefer something lower level, so anything can be easily implemented on top with predictable performance (including JavaScript).&lt;p&gt;I don&apos;t understand the resistance to PNaCl, it&apos;s plugins done right.</text></item><item><author>tachyonbeam</author><text>Sitting about 10 feet away from Luke Wagner right now. He has told me that asm.js is Mozilla&apos;s response to NaCl. You compile code with Clang (or another compiler) into the asm.js subset of JavaScript, which they know how to optimize well, and their JIT compiler will offer you performance very close to that of native C (they claim a factor of at most 2x). They use special tricks, like (a+b)|0, to force results to be in the int32 range, and avoid overflow checks. The heap views uses multiple typed arrays pointing to the same data to give asm.js code a typed heap of aligned values, avoiding the JS garbage collector (you can manage this heap as you wish).&lt;p&gt;They already have sample apps, including some using libraries like Qt (I believe OpenGL as well), compiling to asm.js. I believe it has potential, so long as they have good support for standard and common C libraries (i.e.: porting to asm.js is almost effortless).</text></item></parent_chain><comment><author>comex</author><text>It&apos;s plugins done right with the gigantic caveats that it duplicates a large swath of low-level DOM APIs, requiring a large amount of effort to write two implementations of essentially the same things, and has no direct access to the DOM or external JavaScript, meaning it lacks support for some APIs (WebRTC) and cannot really be used as a drop-in replacement for JS or to take advantage of the existing HTML renderer (it&apos;s all or nothing).&lt;p&gt;That is, it&apos;s plugins done right if you insist on living in a separate process, despite the adequacy of both NaCl and JS engines&apos; ability to keep code within the inner sandbox/VM, and what should be the adequacy of the sandbox of renderer processes even if someone manages to run native code in it.&lt;p&gt;Me, I&apos;d prefer to just run emscripten on the Python interpreter, take advantage of a very small VM that nevertheless is apparently able to run code at half native speed, and start using a new language on top of all the nice existing stuff.</text></comment>
<story><title>Asm.js: a strict subset of js for compilers – working draft</title><url>http://asmjs.org/spec/latest/</url></story><parent_chain><item><author>lucian1900</author><text>I&apos;d really much prefer something lower level, so anything can be easily implemented on top with predictable performance (including JavaScript).&lt;p&gt;I don&apos;t understand the resistance to PNaCl, it&apos;s plugins done right.</text></item><item><author>tachyonbeam</author><text>Sitting about 10 feet away from Luke Wagner right now. He has told me that asm.js is Mozilla&apos;s response to NaCl. You compile code with Clang (or another compiler) into the asm.js subset of JavaScript, which they know how to optimize well, and their JIT compiler will offer you performance very close to that of native C (they claim a factor of at most 2x). They use special tricks, like (a+b)|0, to force results to be in the int32 range, and avoid overflow checks. The heap views uses multiple typed arrays pointing to the same data to give asm.js code a typed heap of aligned values, avoiding the JS garbage collector (you can manage this heap as you wish).&lt;p&gt;They already have sample apps, including some using libraries like Qt (I believe OpenGL as well), compiling to asm.js. I believe it has potential, so long as they have good support for standard and common C libraries (i.e.: porting to asm.js is almost effortless).</text></item></parent_chain><comment><author>dherman</author><text>There are good and bad things about PNaCl. But overall, the resistance to PNaCl goes beyond Mozilla -- it&apos;s a really hard standardization/synchronization problem. Our goal with asm.js was to produce something that could work today (because it&apos;s 100% compatible with existing JS semantics) and work even better tomorrow as engines optimize it even better.&lt;p&gt;&lt;i&gt;&lt;/i&gt;Edit&lt;i&gt;&lt;/i&gt;: Re: predictable performance, that&apos;s exactly what asm.js is about. The performance model is much closer to that of C or PNaCl/LLVM.</text></comment>