4 ms·
Part of Wasm's capability security model is that JS objects are opaque to Wasm and Wasm objects are opaque to JS. This is a good thing and it doesn't prevent in
by davexunit 3y ago
Part of Wasm's capability security model is that JS objects are opaque to Wasm and Wasm objects are opaque to JS. This is a good thing and it doesn't prevent interop.
Everyone asks about DOM nodes, so let's use that as an example. In Wasm, you could import a function known locally as $documentGetElementById. The host (JS) could then instantiate the module and provide Document.prototype.getElementById.bind(document) as the implementation of that import. $documentGetElementById's return type would be (ref extern), an opaque reference to a heap object from the host that can now be freely passed around the Wasm module or back to the host. You could then import any other DOM functions that you need to inspect/manipulate these objects.
On the flip side, if you have a Wasm object reference in JS, you need to call some exported Wasm function(s) to inspect/manipulate it.
- singularity2001 3y agoHow does it not prevent interop if JS can't even read or write the struct data provided by wasm? If they still require glue code hell, what's even the point?