4 ms·

Everyone keeps saying this, but it doesn't make sense to compile JavaScript to WebAssembly. Even if WASM had enough built-in APIs to allow you to implement JS w

Everyone keeps saying this, but it doesn't make sense to compile JavaScript to WebAssembly. Even if WASM had enough built-in APIs to allow you to implement JS without also implementing its runtime, you would lose all of the JIT performance optimizations. There is literally no benefit, aside from being able to implement non-backwards-compatible features (which doesn't feel like a strong reason to me, given the cost).

BinaryIdiot 8y ago
> you would lose all of the JIT performance optimizations I don't follow. Why would losing optimizations from one language prevent optimizations from being done in an IL? Are you saying that Web Assembly can't be as fast as JavaScript? If so, why? > There is literally no benefit, aside from being able to implement non-backwards-compatible features You ignored the benefit I outlined above. Why would you want a single scripting language to be the only one to ever be used in a web browser? Heck, web assembly can even make the ECMAScript iteration loop tighter if you really wanted to. I'm having trouble seeing the downsides to this approach.
- MikeHolman 8y ago
  Browsers are already very optimized for JS. Wasm is not currently a good target for managed languages (you would need to implement your own GC on top of wasm memory), and AOT compilation in general is not good for languages as dynamic as JS.
- 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 ago
    Google just discussed WebAssembly 2.0 at IO, those APIs are coming. They also unveiled Autocad running on WebAssembly.
    - Jasper_ 8y ago
      I 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 ago
        Then 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.
- Jasper_ 8y ago
  The downside is that it's extraordinarily difficult to create a single runtime which has a satisfying object and GC model for all parties. The GC proposal which adds such a thing on top of WebAssembly is nowhere near complete and is currently being punted on, with the intermediate solution being host-bindings. And keep in mind that this GC proposal doesn't handle JavaScript's dynamic objects which can change shape at runtime. It only handles ones with known shapes. It will be a long time for it to be possible for JavaScript to "just be compiled" to WebAssembly while keeping the same performance characteristics, if it ever happens. [0] https://github.com/WebAssembly/gc/issues/32 https://github.com/WebAssembly/gc/issues/32 has some concerns from language implementors.
jerf 8y ago
I believe the .Net world does its JITing based on a bytecode that is at the conceptual level a lot like web assembly. They're not the same, of course, but the point is you can JIT on that sort of thing OK. I won't promise you won't lose some performance, but there's other ways in which that might still be a long-term win as you may be able to gain in other ways relating to exploiting the language you start with. (In the long run, and to be honest even today, if you really deeply care about performance, you don't want a dynamic language. They're slow. We've invested crazy amount of effort into optimizing them, made tons of progress in that optimization vs where we started... and they're still slow. At this point smart money has to be put on that not changing.)
- Jasper_ 8y ago
  They're nowhere near the same. WASM is based on linear memory and has no concepts of objects and methods. CIL bytecode as used by .NET has a full runtime which has objects, methods and GC. Even with the GC proposal, as currently spec'd, it would not be able to handle .NET's object model. The only similarity, really, is that they're both binary formats.
  - pjmlp 8y ago
    That doesn't stop Microsoft to keep improving Blazor.
    - Jasper_ 8y ago
      Blazor is a .NET interpreter written in C++ that's compiled to WebAssembly. You can think of it as being comparable to Duktape or another JavaScript interpreter being compiled to WebAssembly and running some JavaScript code. It won't JIT anything.
      - pjmlp 8y ago
        No it isn't JITing, but you missed the part they are improving CoreRT to use AOT compilation to WebAssembly instead. Just like Unity is already doing with their Lightweight Components and HPC#.

BinaryIdiot 8y ago

> you would lose all of the JIT performance optimizations I don't follow. Why would losing optimizations from one language prevent optimizations from being done in an IL? Are you saying that Web Assembly can't be as fast as JavaScript? If so, why? > There is literally no benefit, aside from being able to implement non-backwards-compatible features You ignored the benefit I outlined above. Why would you want a single scripting language to be the only one to ever be used in a web browser? Heck, web assembly can even make the ECMAScript iteration loop tighter if you really wanted to. I'm having trouble seeing the downsides to this approach.

MikeHolman 8y ago
Browsers are already very optimized for JS. Wasm is not currently a good target for managed languages (you would need to implement your own GC on top of wasm memory), and AOT compilation in general is not good for languages as dynamic as JS.
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 ago
  Google just discussed WebAssembly 2.0 at IO, those APIs are coming. They also unveiled Autocad running on WebAssembly.
  - Jasper_ 8y ago
    I 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 ago
      Then 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.
Jasper_ 8y ago
The downside is that it's extraordinarily difficult to create a single runtime which has a satisfying object and GC model for all parties. The GC proposal which adds such a thing on top of WebAssembly is nowhere near complete and is currently being punted on, with the intermediate solution being host-bindings. And keep in mind that this GC proposal doesn't handle JavaScript's dynamic objects which can change shape at runtime. It only handles ones with known shapes. It will be a long time for it to be possible for JavaScript to "just be compiled" to WebAssembly while keeping the same performance characteristics, if it ever happens. [0] https://github.com/WebAssembly/gc/issues/32 https://github.com/WebAssembly/gc/issues/32 has some concerns from language implementors.

jerf 8y ago

I believe the .Net world does its JITing based on a bytecode that is at the conceptual level a lot like web assembly. They're not the same, of course, but the point is you can JIT on that sort of thing OK. I won't promise you won't lose some performance, but there's other ways in which that might still be a long-term win as you may be able to gain in other ways relating to exploiting the language you start with. (In the long run, and to be honest even today, if you really deeply care about performance, you don't want a dynamic language. They're slow. We've invested crazy amount of effort into optimizing them, made tons of progress in that optimization vs where we started... and they're still slow. At this point smart money has to be put on that not changing.)

Jasper_ 8y ago
They're nowhere near the same. WASM is based on linear memory and has no concepts of objects and methods. CIL bytecode as used by .NET has a full runtime which has objects, methods and GC. Even with the GC proposal, as currently spec'd, it would not be able to handle .NET's object model. The only similarity, really, is that they're both binary formats.
- pjmlp 8y ago
  That doesn't stop Microsoft to keep improving Blazor.
  - Jasper_ 8y ago
    Blazor is a .NET interpreter written in C++ that's compiled to WebAssembly. You can think of it as being comparable to Duktape or another JavaScript interpreter being compiled to WebAssembly and running some JavaScript code. It won't JIT anything.
    - pjmlp 8y ago
      No it isn't JITing, but you missed the part they are improving CoreRT to use AOT compilation to WebAssembly instead. Just like Unity is already doing with their Lightweight Components and HPC#.