Support WebAssembly.instantiateStreaming

[Leko]

I think it's better support WebAssembly.instantiateStreaming.
It makes more easy to use WebAssembly and we can get more compatibility for Web.

It already implemented in Google Chrome, Firefox and some browsers.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/instantiateStreaming

instantiateStreaming already exists in deps/v8/src/wasm/wasm-js.cc but cannot cover this branch.

node/deps/v8/src/wasm/wasm-js.cc

Lines 1177 to 1182 in de73272

	if (isolate->wasm_compile_streaming_callback() != nullptr) {
	InstallFunc(isolate, webassembly, "compileStreaming",
	WebAssemblyCompileStreaming, 1);
	InstallFunc(isolate, webassembly, "instantiateStreaming",
	WebAssemblyInstantiateStreaming, 1);
	}

To cover this branch, we must call SetWasmCompileStreamingCallback.

node/deps/v8/include/v8.h

Line 7805 in de73272

void SetWasmCompileStreamingCallback(ApiImplementationCallback callback);

node/deps/v8/src/api.cc

Lines 8876 to 8877 in de73272

	CALLBACK_SETTER(WasmCompileStreamingCallback, ApiImplementationCallback,
	wasm_compile_streaming_callback)

In chromium, implemented here:
https://github.com/chromium/chromium/blob/51459d663d841c6430747aec97be9f7e7a7ca41f/third_party/blink/renderer/bindings/core/v8/v8_wasm_response_extensions.cc#L194-L222
And use it here:
https://github.com/chromium/chromium/blob/51459d663d841c6430747aec97be9f7e7a7ca41f/third_party/blink/renderer/bindings/core/v8/v8_wasm_response_extensions.cc#L228

Why we must inject the actual implementation,
It's said that this is for layering reasons.
WebAssembly/design#1085

Discussion

1. How about it?
2. How to make instantiateStreaming compatible with design.
   • ex. instantiateStreaming(fs.promises.readFile('./some.wasm'), importObject)
     • It's not compatible with design.
     • readFile returns Buffer, not ArrayBuffer.

[devsnek]

The design of instantiateStreaming currently requires Response to perform proper checks for stuff like mimes and whatnot. While node could implement instantiateStreaming possibly taking a node Stream object i don't think its worth splintering the wasm api between browsers and node. For some reasons i won't go into here node might gain a Response object anyway (and we're already working on mimes over in #21128) so once we get that stuff in this could be done.

[AyushG3112]

While I understand that implementing WebAssembly for isomorphism might be good, but, for native modules, we already have Native and N-API addons. This would just be throwing another one into the mix.

[devsnek]

@AyushG3112 we already support wasm, this would just be adding another method of loading it.

[AyushG3112]

@devsnek ah, I did not know that. Nevermind my comment then, and thanks!

[bnoordhuis]

What is the use case besides feature parity with browsers? WebAssembly.instantiateStreaming() seems of limited usefulness in Node.js. Likewise WebAssembly.compileStreaming().

ex. instantiateStreaming(fs.promises.readFile('./some.wasm'), importObject)

That would be fairly straightforward to implement but I share @devsnek's sentiment that we shouldn't diverge from browsers lightly.

For some reasons i won't go into here node might gain a Response object

Pray tell!

[Leko]

@devsnek @bnoordhuis I totally agree.
I think it should be implemented the same API as browser.

[bnoordhuis]

Okay, but can you speak to your use case? As I said, I don't really see when or why you'd use it with Node.js.

[Leko]

@bnoordhuis My use case is image processor what work on browser and Node.js implemented by WebAssembly.
And small wrapper for loading it.

BTW, I think we decide to implement Fetch API or not prior to start this discussion.
It already discussing in this issue: #19393 (comment)

[bnoordhuis]

image processor what work on browser and Node.js implemented by WebAssembly

I can see why you'd load it in streaming fashion in a browser but why in Node.js? If it's an on-disk file, just load it in one go.

[Leko]

@bnoordhuis
Personally, The most important reason is portability.
I want to use instantiateStreaming because Google recommended way of loading WebAssembly to use WebAssembly.*Streaming.
But cannot use instantiateStreaming if planned to run both Node.js and browser.

[xtuc]

What if the WebAssembly loading and instantiation is done is a separate worker and posted to the main thread?

Also FYI https://github.com/wasm-tool/node-loader. I know that @bmeck is working a multi-threaded loading which would fit well to this use case.

[Trott]

Is this something Node.js is likely to implement? If not, should we close this?

[Trott]

I'm going to mark this as stalled and close it. Feel free to comment or re-open if you believe that's the wrong thing to do here.

[tigercosmos]

It's sad that Node doesn't support this method. 😐

[tniessen]

It's sad that Node doesn't support this method. 😐

I am sure we would consider a PR if you were to implement it.

[devsnek]

good start here: https://github.com/devsnek/node/tree/feature/wasm-streaming

[devsnek]

👀