Skip to content

Support async instantiation in Node.js - #27730

Draft
jeremy-code wants to merge 2 commits into
emscripten-core:mainfrom
jeremy-code:node-streaming
Draft

jeremy-code wants to merge 2 commits into
emscripten-core:mainfrom
jeremy-code:node-streaming

Conversation

@jeremy-code

Copy link
Copy Markdown
Contributor

Since Node.js is on v8, which optimizes instantiateStreaming significantly due to caching,123 async instantiation should be preferred. While Node.js doesn't support file URIs, a file system read stream can still be used as an input for instantiateStreaming, so as long as the MIME type is set correctly (this same technique is used in cosInstantiateStream).

Unidici does support using a Node.js read stream in the Response constructor (see here). I believe this means this should be valid in all Node.js environments. If there somehow is an issue (maybe in an edge environment where some Node polyfill exists, but the native web Response is still used...?), this could be fixed either by:

  1. Readable.toWeb() from node:stream
  2. Using fs.openAsBlob() instead (might have some weird issues on older Node.js versions since blobs used to be stored in memory in Node File-based Blob implementation nodejs/node#45188)

Let me know what you think.

Footnotes

  1. https://v8.dev/blog/wasm-code-caching

  2. https://web.dev/articles/loading-wasm

  3. MDN warns "This method is not the most efficient way of fetching and instantiating Wasm modules. If at all possible, you should use the newer WebAssembly.instantiateStreaming() method instead": https://developer.mozilla.org/en-US/docs/WebAssembly/Reference/JavaScript_interface/instantiate_static

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant