3 ms·

>> The Reference Types proposal, shipped in V8 v9.6, allows using external references from JavaScript opaquely in WebAssembly modules. Does this mean we now ha

>> The Reference Types proposal, shipped in V8 v9.6, allows using external references from JavaScript opaquely in WebAssembly modules. Does this mean we now have direct DOM access from WASM and GC support?

paavohtl 5y ago
No, not yet. This is just the first step, which allows passing handles to JS/DOM objects to WASM, but they are opaque to WASM and they cannot yet be interacted with in any other way than passing them back to JS.
flohofwoe 5y ago
It just means that the Javascript API shim between WASM and web APIs doesn't need to translate between numeric handles and Javascript object references anymore, making those shims much smaller, and maybe in some cases the shims can disappear completely. (here's an example of such a shim for WebGPU in the Emscripten SDK: https://github.com/emscripten-core/emscripten/blob/main/src/library_webgpu.js https://github.com/emscripten-core/emscripten/blob/main/src/...)
- trzeci 5y ago
  This is something that I'm worry about: It forces Emscripten builds to be created differently in the way the build artifacts will be compatible only with that version of V8 - in practice it means a dead feature that looks nice, but we can't use for a long long time.
  - flohofwoe 5y ago
    Apparently it's already supported everywhere except Chrome: https://webassembly.org/roadmap/ https://webassembly.org/roadmap/ So with Chrome's quick release cycles it's probably not too bad (not sure about the 'branded' mobile browsers on Android though).
    - trzeci 5y ago
      Thanks for the correction and for the link! Unfortunately I'm still keeping my worry alive. The reality is that we still can't move fully even to wasm, as ~6% of our players have incompatible browser and we have to support asm.js fallback. My worry is that we end up with fallback cascade: - full featured wasm - wasm - asm.js I'm aware that's the reality of technology under development - and most likely we will just find a solution for that (like secondary build (or link if it's just link time)). It's just too bad we can't easy polyfill new features in old browsers for wasm. Still love WASM <3
      - coldtea 5y ago
        >Unfortunately I'm still keeping my worry alive. The reality is that we still can't move fully even to wasm, as ~6% of our players have incompatible browser and we have to support asm.js fallback Well, if that's a pain, then 6% is small enough to drop/force to upgrade.
pjmlp 5y ago
And eventually WebGL/WebGPU, one step at a time to have full Flash tooling back, and the plugins will be revenged. https://www.opensilver.net https://www.opensilver.net https://leaningtech.com/cheerpj https://leaningtech.com/cheerpj https://leaningtech.com/cheerpx-for-flash https://leaningtech.com/cheerpx-for-flash Looking forward to it.

paavohtl 5y ago

No, not yet. This is just the first step, which allows passing handles to JS/DOM objects to WASM, but they are opaque to WASM and they cannot yet be interacted with in any other way than passing them back to JS.

flohofwoe 5y ago

It just means that the Javascript API shim between WASM and web APIs doesn't need to translate between numeric handles and Javascript object references anymore, making those shims much smaller, and maybe in some cases the shims can disappear completely. (here's an example of such a shim for WebGPU in the Emscripten SDK: https://github.com/emscripten-core/emscripten/blob/main/src/library_webgpu.js https://github.com/emscripten-core/emscripten/blob/main/src/...)

trzeci 5y ago
This is something that I'm worry about: It forces Emscripten builds to be created differently in the way the build artifacts will be compatible only with that version of V8 - in practice it means a dead feature that looks nice, but we can't use for a long long time.
- flohofwoe 5y ago
  Apparently it's already supported everywhere except Chrome: https://webassembly.org/roadmap/ https://webassembly.org/roadmap/ So with Chrome's quick release cycles it's probably not too bad (not sure about the 'branded' mobile browsers on Android though).
  - trzeci 5y ago
    Thanks for the correction and for the link! Unfortunately I'm still keeping my worry alive. The reality is that we still can't move fully even to wasm, as ~6% of our players have incompatible browser and we have to support asm.js fallback. My worry is that we end up with fallback cascade: - full featured wasm - wasm - asm.js I'm aware that's the reality of technology under development - and most likely we will just find a solution for that (like secondary build (or link if it's just link time)). It's just too bad we can't easy polyfill new features in old browsers for wasm. Still love WASM <3
    - coldtea 5y ago
      >Unfortunately I'm still keeping my worry alive. The reality is that we still can't move fully even to wasm, as ~6% of our players have incompatible browser and we have to support asm.js fallback Well, if that's a pain, then 6% is small enough to drop/force to upgrade.

pjmlp 5y ago

And eventually WebGL/WebGPU, one step at a time to have full Flash tooling back, and the plugins will be revenged. https://www.opensilver.net https://www.opensilver.net https://leaningtech.com/cheerpj https://leaningtech.com/cheerpj https://leaningtech.com/cheerpx-for-flash https://leaningtech.com/cheerpx-for-flash Looking forward to it.