3 ms·

> they made bad technical decisions in the design Considering that the most important design requirement was to have a security model that's good enough for ru

> they made bad technical decisions in the design Considering that the most important design requirement was to have a security model that's good enough for running untrusted code in web browsers at near native performance, I think the WASM peeps did a pretty good job. Your requirements may be different, but then maybe WASM simply isn't the right solution for you (there are plenty of alternatives outside web browsers after all).

torginus 2y ago
PNacl also had the same sandboxing requirement, yet had many of the features still missing today from WAsm (threads, 3d graphics API support, access to other native APIs), and it didn't suffer from slow startup times. It had pretty nice and quick uptake considering the tooling was very similar to native toolchains. According to this benchmark (first Google result I found), it was even faster: https://apryse.com/blog/wasm/wasm-vs-pnacl https://apryse.com/blog/wasm/wasm-vs-pnacl While it might not have been perfect, WASM is yet to catch up in many ways, and some of its limitations might come from its design.
- flohofwoe 2y ago
  I had been working both with NaCl and PNaCl back then, and truth be told, once Google made the switch from NaCl to PNaCl most advantages just disappeared. The compilation of the PNaCl bytecode on start (which was more or less just a subset of LLVM IR) took longer than even the first WASM implementations. PNaCl definitely suffered hard from slow startup times because it ran LLVM for compilation from PNaCl bytecode to native code on startup, and LLVM is slow (I even noticed this compilation process on startup on my absolutely trivial test code). Only the predecessor NaCl didn't suffer from this problem. There was no 'access to other native APIs', PNaCl created its own set of wrapper APIs to access browser features, and while some of those were better than their standardized web API counterparts, some NaCl/PNaCl APIs were worse than the web APIs they replaced - and for the future, PNaCl would have to create more non-standard APIs for every little feature available in browsers, because: Integration with the webpage and Javascript was done via message passing, which was just terrible when compared to how easy and fast it is to call between WASM and JS. The NaCl/PNaCl multithreading feature would have been hit just as hard by Spectre/Meltdown as the SharedArrayBuffer based threading in WASM. Finally, when you look at the PNaCl toolchain versus Emscripten, Emscripten definitely comes out on top because Emscripten was much more concerned about integrating well with existing build systems and simplify porting of existing code, while NaCl/PNaCl had its own weird build system (in old Google NIH tradition). Working with NaCl/PNaCl felt more like working with the Android NDK, which is pretty much the worst developer experience in the world.
  - titzer 2y ago
    It's also worth noting that the NaCl and PNaCl teams were integrated into a large Wasm team at Google and brought their expertise to the project. While we didn't all 100% agree on every decision made in Wasm design, we were intimately familiar with the tradeoffs made by those prior projects. Ultimately the sandboxing requirement of running in-process with the renderer process and integrating with Web APIs like JS dictated hard requirements for security.

torginus 2y ago

PNacl also had the same sandboxing requirement, yet had many of the features still missing today from WAsm (threads, 3d graphics API support, access to other native APIs), and it didn't suffer from slow startup times. It had pretty nice and quick uptake considering the tooling was very similar to native toolchains. According to this benchmark (first Google result I found), it was even faster: https://apryse.com/blog/wasm/wasm-vs-pnacl https://apryse.com/blog/wasm/wasm-vs-pnacl While it might not have been perfect, WASM is yet to catch up in many ways, and some of its limitations might come from its design.

flohofwoe 2y ago
I had been working both with NaCl and PNaCl back then, and truth be told, once Google made the switch from NaCl to PNaCl most advantages just disappeared. The compilation of the PNaCl bytecode on start (which was more or less just a subset of LLVM IR) took longer than even the first WASM implementations. PNaCl definitely suffered hard from slow startup times because it ran LLVM for compilation from PNaCl bytecode to native code on startup, and LLVM is slow (I even noticed this compilation process on startup on my absolutely trivial test code). Only the predecessor NaCl didn't suffer from this problem. There was no 'access to other native APIs', PNaCl created its own set of wrapper APIs to access browser features, and while some of those were better than their standardized web API counterparts, some NaCl/PNaCl APIs were worse than the web APIs they replaced - and for the future, PNaCl would have to create more non-standard APIs for every little feature available in browsers, because: Integration with the webpage and Javascript was done via message passing, which was just terrible when compared to how easy and fast it is to call between WASM and JS. The NaCl/PNaCl multithreading feature would have been hit just as hard by Spectre/Meltdown as the SharedArrayBuffer based threading in WASM. Finally, when you look at the PNaCl toolchain versus Emscripten, Emscripten definitely comes out on top because Emscripten was much more concerned about integrating well with existing build systems and simplify porting of existing code, while NaCl/PNaCl had its own weird build system (in old Google NIH tradition). Working with NaCl/PNaCl felt more like working with the Android NDK, which is pretty much the worst developer experience in the world.
- titzer 2y ago
  It's also worth noting that the NaCl and PNaCl teams were integrated into a large Wasm team at Google and brought their expertise to the project. While we didn't all 100% agree on every decision made in Wasm design, we were intimately familiar with the tradeoffs made by those prior projects. Ultimately the sandboxing requirement of running in-process with the renderer process and integrating with Web APIs like JS dictated hard requirements for security.