3 ms·
I don't get why binaries should be more bandwidth-intensive than JS. I guess in a sense you already have the JS engine installed with, say, Chrome, which is es
by asdfman123 7y ago
I don't get why binaries should be more bandwidth-intensive than JS.
I guess in a sense you already have the JS engine installed with, say, Chrome, which is essentially a runtime.
Why can't other runtimes come prepackaged? What am I missing here?
- bhaak 7y agoNobody wants another fat runtime that is as entangled with the browser engine as the JS engine is. Getting the JS engine to be fast was a tremendous trouble and you wouldn't want to sink as much engineering power into another runtime that will have a smaller reach than the JS engine. Rather use that skills to make WASM faster.
- krapp 7y ago> Nobody wants another fat runtime that is as entangled with the browser engine as the JS engine is. Why would it need to be? There's no reason to assume the architectural decisions for javascript have to be repeated for WASM. The runtimes themselves could be WASM binaries cached like any other resource, or managed like packages. Javascript could be disentangled from the browser by doing the same - just treating it as a resource that ships by default with the browser. I don't know if that's feasible - maybe not - but I bet there are possibilities other than "ship the entire runtime with each script" that can be considered.
- bhaak 7y agoI thought you meant adding other scripting languages to the browser. Not a WASM runtime. That's likely still not a good idea. A specific runtime is likely to be outdated fast. That's like asking why the JQuery library wasn't shipped with the browsers themselves. For runtime with a significant size, it's probably going the same way as JQuery. Have a CDN host it so different websites can use it and leverage the browser's cache.