3 ms·
Nobody 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 an
by bhaak 7y ago
Nobody 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.