3 ms·
This article makes the mistake of buying into the idea that WebAssembly has anything to do with NaCl. It's not. It just had some NaCl people working on it (alon
by bobajeff 11y ago
This article makes the mistake of buying into the idea that WebAssembly has anything to do with NaCl. It's not. It just had some NaCl people working on it (along with emscripten Asm.js people and others).
When it's released it'll map to asm.js and have most of it's limitations. Many of the limitations he ran into (no raw socket access, system library access) were related to the API limitations imposed by the browser's security model.
Also WebAssembly is pretty far along as they have drafted a specification and have prototype implementations in all the major JS engines. They also have a LLVM/Clang backend.
- robbrown451 11y agoI don't think that is a mistake. The lessons learned from NaCl are being applied to WebAssembly, the idea being that WebAssembly will get the best of both of asm.js and NaCl.
- pcwalton 11y agoThat's right. wasm is just like asm.js, plus the possibility of shared-memory multithreading. It has far more in common with asm.js than it does with NaCl, contrary to the conclusions of the article. Threading and being a binary format instead of a text one aren't differences as fundamental as the difference between the Web APIs and NaCl's Pepper. Many of the complaints, as you point out, are about the Web APIs, and unlike NaCl Web Assembly is fully committed to the Web APIs (as it should be).
- azakai 11y agoTo be fair, asm.js already has significant progress towards shared-memory threads [1]. That will finish standardization and ship long before wasm has threads. I would say that the main difference between asm.js and wasm is, as you mentioned, that wasm is a binary format. That will allow far smaller downloads, and far faster startup times. The second main difference is that wasm is a new formal standard, with all vendors involved, so we should see consistent performance across browsers. Unlike asm.js which was a pure JavaScript optimization, so different browsers optimized in different ways, leading to large variability (which decreased over time, but remained significant, e.g. on specific things like memory growth, which was abandoned due to that). [1] http://kripken.github.io/emscripten-site/docs/porting/pthreads.html http://kripken.github.io/emscripten-site/docs/porting/pthrea...
- Renaud 11y ago>Many of the limitations he ran into I believe you mean "she".
- bobajeff 11y agoOops. No, I just made a gender assumption and overlooked the profile section.