3 ms·

I will go on a record that I never really liked WebAssembly. Google's Native Client allowed people to run safety screened native assembly at like 95% native spe

I will go on a record that I never really liked WebAssembly. 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. Accessing browser native classes is still an open issue - in fact, you have to go through JS to do anything, with all the associated performance issues. I don't get it why it's so bad - for every native JS class you find on MDN, there's an equivalent C++ class in the Chrome codebase, which somehow gets bound to the JS JIT. Couldn't we expose all the API through a marshalling/validation layer? Memory leaks are a non-issue, since you can leak native objects in both JS and in C, with the only difference being that in JS, the object is still reachable through a gc root. Another huge issue is the crappy multithreading support. First, the multithreading solution of JS workers + SharedArrayBuffer is horrible, second you aren't allowed to do it without draconian and impractical security measures, due to the security theather around side channel attacks. Which makes running heavy apps, like modern video games, practically impossible. I remember Epic demoing Unreal in the browser in the early 2010s and a lot of people predicted that in the future, most games will be playable via a website. Yeah, that didn't come to pass. Instead of becoming the default way of writing and distributing web apps, with the convenience of web deployment and the power of real desktop apps, it became a curiosity and a way of gaining tech clout.

flohofwoe 1y ago
> 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).

flohofwoe 1y ago

> 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).