> Google's Native Client allowed people to run safety screened native assembly at like 95% native speed and virtually no startup time, while having a tiny fract

> Google's Native Client allowed people to run safety screened native assembly at like 95% native speed and virtually no startup time, while having a tiny fraction of the engineering complexity. I worked both with NaCl and PNaCl, and they both had their own share of problems, like: - any interaction with the browser side had to happen via message passing (e.g. the people who today complain that WASM has no DOM access would have a complete mental breakdown if each interaction with the DOM had to go through message passing instead of direct WASM-to-JS calls). - NaCl had to invent its own APIs for 3D rendering, audio, and pretty much anything else which required any sort of performance (since the only alternative was the above mentioned slow message passing) - The 'main thread' was basically just an event loop, to get continuous rendering you had to spawn a separate thread (much like what you need to do on the Android NDK) - They had their own frigging build system which wasn't compatible with anything else. Good luck getting NaCl/PNaCl integrated with something more common like cmake (it works, but it was basically the same PITA like trying to integrate the Android NDK with a proper build system today). - PNaCl (which was essentially LLVM bitcode) had an enormous startup time, even slower than the very first WASM experiments which used AOT. Also, NaCl was quickly deprecated in favour of PNaCl, but PNaCl suffered from much worse problems than WASM ever had (especially in startup time and runtime performance was at best comparable to WASM).