5 ms·

> you would lose all of the JIT performance optimizations I don't follow. Why would losing optimizations from one language prevent optimizations from being don

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

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.