4 ms·

From the asm.js FAQ: Q. Why not NaCl or PNaCl instead? Are you just being stubborn about JavaScript? A. The principal benefit of asm.js over whole

From the asm.js FAQ: Q. Why not NaCl or PNaCl instead? Are you just being stubborn about JavaScript? A. The principal benefit of asm.js over whole new technologies like NaCl and PNaCl is that it works today asm.js however wasn't good enough to actually be useful, as evidenced by the lack of adoption and the move to wasm. So now we have wasm which is not backward compatible. We would be further along now if Mozilla/Eich would have gotten behind Google's more mature effort, this really was stubbornness IMO.

Analemma_ 9y ago
"Stubbornness" in refusing to let Google unilaterally decree web technologies and standards is stubbornness I support fully.
bobajeff 9y ago
Actually, the AOT optimization path for asm.js has been supported by Internet Explorer/Edge for quite some time. Chrome also supports AOT asm.js path now through their wasm implementation[1]. Before that Chrome and Safari did optimizations that just happened to make asm.js faster ;) It's likely that if WebAssembly didn't happen everyone would've implemented AOT optimizations for asm.js and all the new features (shared memory threads, simd, 64bit int etc.) would be targeting that instead. [1] http://benediktmeurer.de/2016/12/20/v8-behind-the-scenes-december-edition/ http://benediktmeurer.de/2016/12/20/v8-behind-the-scenes-dec...
roca 9y ago
PNaCl had two big problems Google never attempted to solve: * No spec, just import some particular version of LLVM and it does what it does * Dependence on Pepper for its platform API --- just a big pile of Chromium code that does what it does and duplicates all the standard Web APIs
- jhpriestley 9y ago
  I don't have any insider knowledge, but my sense is that Google never tried to solve these sorts of issues because Mozilla made it very clear that they wouldn't support it. Now they're backtracking and building a non-js asm system too. Do you think wasm apps will always use slow JavaScript ffi to call opengl say? We'll get a new pepper in like another decade.
  - roca 9y ago
    I personally told Google people that the Pepper platform API situation was unacceptable to Mozilla years before PNaCl even appeared. That didn't stop them pushing ahead. So if your theory is correct then Mozilla opposition was not strong enough to stop PNaCl development, and not strong enough to stop them exposing it to the public Web, but strong enough to stop them trying to turn it into a proper Web standard. Wasm is only superficially non-JS. AFAIK every browser vendor is implementing Wasm by reusing the optimizing compilers in their JS engines. I think we might see some extensions to WebIDL and Web platform APIs to improve Wasm app performance. We're sort of already seeing that with [AllowShared]. But there's no need to develop entirely new platform APIs, because fundamentally there's no reason calls from Wasm through JS API glue to the browser should be slow; JS API glue can be inlined into the Wasm code, for example.

Analemma_ 9y ago

"Stubbornness" in refusing to let Google unilaterally decree web technologies and standards is stubbornness I support fully.

bobajeff 9y ago

Actually, the AOT optimization path for asm.js has been supported by Internet Explorer/Edge for quite some time. Chrome also supports AOT asm.js path now through their wasm implementation[1]. Before that Chrome and Safari did optimizations that just happened to make asm.js faster ;) It's likely that if WebAssembly didn't happen everyone would've implemented AOT optimizations for asm.js and all the new features (shared memory threads, simd, 64bit int etc.) would be targeting that instead. [1] http://benediktmeurer.de/2016/12/20/v8-behind-the-scenes-december-edition/ http://benediktmeurer.de/2016/12/20/v8-behind-the-scenes-dec...

roca 9y ago

PNaCl had two big problems Google never attempted to solve: * No spec, just import some particular version of LLVM and it does what it does * Dependence on Pepper for its platform API --- just a big pile of Chromium code that does what it does and duplicates all the standard Web APIs

jhpriestley 9y ago
I don't have any insider knowledge, but my sense is that Google never tried to solve these sorts of issues because Mozilla made it very clear that they wouldn't support it. Now they're backtracking and building a non-js asm system too. Do you think wasm apps will always use slow JavaScript ffi to call opengl say? We'll get a new pepper in like another decade.
- roca 9y ago
  I personally told Google people that the Pepper platform API situation was unacceptable to Mozilla years before PNaCl even appeared. That didn't stop them pushing ahead. So if your theory is correct then Mozilla opposition was not strong enough to stop PNaCl development, and not strong enough to stop them exposing it to the public Web, but strong enough to stop them trying to turn it into a proper Web standard. Wasm is only superficially non-JS. AFAIK every browser vendor is implementing Wasm by reusing the optimizing compilers in their JS engines. I think we might see some extensions to WebIDL and Web platform APIs to improve Wasm app performance. We're sort of already seeing that with [AllowShared]. But there's no need to develop entirely new platform APIs, because fundamentally there's no reason calls from Wasm through JS API glue to the browser should be slow; JS API glue can be inlined into the Wasm code, for example.