WASM spec authors and implementors seem to agree that this all can be naturally handled by providing direct bindings to regular web APIs in WASM.
I would tend to agree... Those don't exactly seem core to the design of the runtime?
WASM spec authors and implementors seem to agree that this all can be naturally handled by providing direct bindings to regular web APIs in WASM.
I would tend to agree... Those don't exactly seem core to the design of the runtime?
Remember that some old IEs had memory leaks because one could make circular references through the DOM and JavaScript, and they each had separate garbage collectors. Well working garbage collection is not an afterthought, and you can't get two distinct garbage systems to work together in the seamless manner that a single system can operate.
I've been writing a bunch of Rust code running in browsers, for work and play. I'm not futzing with the details, I just use wasm-bindgen and web-sys.
I've honestly never worried about garbage collection before, one of the professional hazards of working with a well-designed Rust API. I guess that web-sys provides types with a Drop impl that tell the browser side the object is dead.
> without having to manually mark as held and free.
I guess that's what you're worried about? It's never been a concern of mine. Maybe if one were writing WASM by hand?