Closed sffc closed 7 months ago
Wasm modules have a start
function, which could in theory be the part of the Wasm execution that is deferred here. There is not currently the ability in WebAssembly instantiation to delay execution of the start function, but if there were, that seems like the closest match to what would be expected for integration in this proposal and that could in theory be able to cross the async boundaries of Wasm linkage graphs.
There is no known work on this currently that I know of though, but I think that's probably conceptually where it should probably align in the sense that it is the top-level execution not the compilation that is being deferred.
We are working with implementations of WASM modules to understand whether it's possible to instantiate them synchronously instead (compilation would still remain asynchronous). By doing so, import defer
would be able to defer instantiation of WebAssembly modules.
Wasm modules are now compiled asynchronously during the HostLoadImportedModule
call, and then instantiated synchronously on ModuleRecord.Execute()
. As such, import defer
allows deferring instantiation of wasm modules.
Can the interaction with WebAssembly be added to the README?
It's important that the ESM ecosystem tries to be compatible with WASM modules loaded as leaf nodes in a module graph.
WebAssembly can already be compiled and instantiated in separate steps. It would be nice if WASM module instantiation at least, and ideally compilation as well, could be deferred.
There is a sync constructor to create an Instance from a compiled module that could have been previously async compiled, but it is documented as discouraged:
https://developer.mozilla.org/en-US/docs/WebAssembly/JavaScript_interface/Instance/Instance#syntax
However, WASM modules are async modules, and the current proposal puts restrictions on the degree to which async modules can be deferred.