4 ms·
Years of development have gone into making JavaScript in the browser really, really fast. If you re-implement a JS engine on top of WASM, you lose all of that w
by RussianCow 8y ago
Years of development have gone into making JavaScript in the browser really, really fast. If you re-implement a JS engine on top of WASM, you lose all of that work—unless you do something crazy like compile V8 into WASM, but then the client is going to have to download an enormous payload just to run your app.
Even if WASM had APIs for GC, interaction with the DOM and browser APIs, interop with JS, etc, you would still have to compile the JS ahead of time into a static binary, and so the browser would not be able to apply its JIT magic to your code.
I'm all for the dream of running any arbitrary language in the browser, but it's simply not realistic for any language that has a large runtime, which is most dynamic languages.
- pjmlp 8y agoGoogle just discussed WebAssembly 2.0 at IO, those APIs are coming. They also unveiled Autocad running on WebAssembly.
- Jasper_ 8y agoI haven't seen any work from any browser implementers working towards host-bindings or GC. I just skimmed through the I/O talk, as well: AutoCAD was running in a 2D canvas through emscripten in a WebWorker, while the rest of the code was a custom-built React/TypeScript app. Hardly the desktop AutoCAD everyone is thinking of... ... and I didn't spot any mention of "WebAssembly 2.0", whatever that might mean...
- pjmlp 8y agoThen watch it properly, pay attention to the announcement of the upcoming APIs like direct references to DOM nodes, bypassing JavaScript. Or how the Autocad guy explains the C++ code is exactly the same as on the core product. We might loose the battle against Electron, but in the end the browser will be just yet another general purpose VM.