4 ms·

Tangential but what's the status of garbage collection and DOM manipulation in WASM? Are we ever getting those? I understand it's a high-value technology withou

by jolux 4y ago

Tangential but what's the status of garbage collection and DOM manipulation in WASM? Are we ever getting those? I understand it's a high-value technology without them, but I'm interested in writing full apps in say, OCaml (so I'm glad to hear that WASM is getting TCE!).

Kaze404 4y ago
Have you looked into ReasonML by any chance?
- k__ 4y ago
  I lost track of it since the Reason/ReScript split.
azakai 4y ago
GC is making a lot of progress. There are VM and toolchain prototypes. You can compile Java and Dart to wasm on those today and it generally works and is pretty fast. (There is also a Kotlin prototype but I have less information about it.) Most of the big spec questions have also been resolved. DOM manipulation hasn't changed - you still need to call into JS to do those. Ideas like WebIDL bindings have been proposed over the years but haven't shown enough benefit. JS is better for DOM-heavy code, while wasm excels at computation-heavy code. But you can write bindings from wasm (maybe someone already has for OCaml?), which is what toolchains do today - not as fast as JS, but often good enough.
- marcosdumay 4y ago
  > JS is better for DOM-heavy code If you only look at performance, yeah. Performance isn't the only thing we get from WASM, and it would be nice to get the other benefits without having to sacrifice it. (That said, the marshaling needed for DOM access isn't that relevant, I wouldn't say this is a high-priority problem and would prefer people to focus on GC instead, like they are doing.)
- titzer 4y ago
  I will add to this that we are in a healthy design loop that is tightening in on what I feel is a reasonable final design that is implemented in at least one high-performance engine, V8. AFAIK there are Igalia folks trying to get a parallel implementation in JSC to meet the 2-engine bar. GC will not directly make DOM manipulation easier, but it will make it easier to integrate DOM references into a managed language that compiles to WASM, since it obviates the need for indirections through tables. This feature alone is majorly opens up capabilities for WASM on the Web!
wtetzner 4y ago
While I'm also looking forward to TCE and GC for WASM, you can build full apps in OCaml now via js_of_ocaml.
- jolux 4y ago
  I'm aware of js_of_ocaml and Reason, but I want it to run closer to native speed and use multithreading eventually.
jillesvangurp 4y ago
Kotlin 1.7.0 shipped with a WASM compiler recently that currently requires some experimental flags in Chrome to enable features related to garbage collection, threads, and memory management. So, it looks like this is progressing nicely. Once this lands, I imagine there will be a whole range of languages that will be able to make good use of this. As for DOM manipulation, that seems to work well enough but I'm sure there are further improvements coming.

by jolux 4y ago

Kaze404 4y ago

Have you looked into ReasonML by any chance?

k__ 4y ago
I lost track of it since the Reason/ReScript split.

azakai 4y ago

GC is making a lot of progress. There are VM and toolchain prototypes. You can compile Java and Dart to wasm on those today and it generally works and is pretty fast. (There is also a Kotlin prototype but I have less information about it.) Most of the big spec questions have also been resolved. DOM manipulation hasn't changed - you still need to call into JS to do those. Ideas like WebIDL bindings have been proposed over the years but haven't shown enough benefit. JS is better for DOM-heavy code, while wasm excels at computation-heavy code. But you can write bindings from wasm (maybe someone already has for OCaml?), which is what toolchains do today - not as fast as JS, but often good enough.

marcosdumay 4y ago
> JS is better for DOM-heavy code If you only look at performance, yeah. Performance isn't the only thing we get from WASM, and it would be nice to get the other benefits without having to sacrifice it. (That said, the marshaling needed for DOM access isn't that relevant, I wouldn't say this is a high-priority problem and would prefer people to focus on GC instead, like they are doing.)
titzer 4y ago
I will add to this that we are in a healthy design loop that is tightening in on what I feel is a reasonable final design that is implemented in at least one high-performance engine, V8. AFAIK there are Igalia folks trying to get a parallel implementation in JSC to meet the 2-engine bar. GC will not directly make DOM manipulation easier, but it will make it easier to integrate DOM references into a managed language that compiles to WASM, since it obviates the need for indirections through tables. This feature alone is majorly opens up capabilities for WASM on the Web!

wtetzner 4y ago

While I'm also looking forward to TCE and GC for WASM, you can build full apps in OCaml now via js_of_ocaml.

jolux 4y ago
I'm aware of js_of_ocaml and Reason, but I want it to run closer to native speed and use multithreading eventually.

jillesvangurp 4y ago

Kotlin 1.7.0 shipped with a WASM compiler recently that currently requires some experimental flags in Chrome to enable features related to garbage collection, threads, and memory management. So, it looks like this is progressing nicely. Once this lands, I imagine there will be a whole range of languages that will be able to make good use of this. As for DOM manipulation, that seems to work well enough but I'm sure there are further improvements coming.