FYI - Experimenting with wasm support via Node.js

[mhdawson]

As an FYI I've been experimenting with wasm support via Node.js in a similar manner to how it is provided with wasmtime, wasmedge etc.

My experiement is here: https://github.com/mhdawson/crun/tree/node-wasm-experiment

An overview of how to build and try it out is in: https://github.com/mhdawson/crun/blob/node-wasm-experiment/NODE-WASM_EXPERIMENT.md

It's uses code from a PR not landed yet in Node.js since the Node.js embedder API does not have a C interface at this point so it's not ready/suitable for a PR, but was an easier way for me to experiment/prove out the concept.

So far I've only tried it out with Hello World, trying out example that use more of the WASI interfaces is a next step.

@font

[font]

FYI @giuseppe @flouthoc

[flouthoc]

Hi @mhdawson , This looks amazing !! Thank you so much.

I have one small doubt when I was exploring the runtimes. I have a hunch that node has very experimental support of WASI and I also found it is not maintained very well, could you please confirm my observation. ( I could be completely wrong so just confirming here ).

Just for example I was unable to find support for sock_accept which was introduced in wasi-0.11.0 ( I could have wrongly judged when experimenting ).

The reason this was a concern for me because the embedding wasm runtime in crun made a lot of sense only for WASI use-cases and wasmtime,wasmedge are very actively maintained for this, infact for some instance the new API is immediately added to wasmtime as proof-of-concept.

Again this is more of my perception towards node and I'd like @mhdawson to confirm on this :)

[mhdawson]

WASI is still experimental in Node.js and there is work to be done before it would be reasonable to be included in crun as an option.

At this point I'm interested in exploring how the WASM support in Node.js can/will be used as the more use cases we find as that is a good way to drive work in the Node.js project.

In terms of sock_accept is that officially part of the WASI spec, for some reason I had thought from discussion with @font that it was still "experimental" or something like that on the WASI side?

[flouthoc]

@mhdawson ah i see.

In terms of sock_accept is that officially part of the WASI spec, for some reason I had thought from discussion with @font that it was still "experimental" or something like that on the WASI side?

sock_accept is just one example when I was exploring node it was missing implementation for a few more API but I hope it has changed since then. For second question yes afaik sock_accept is officially part of API https://github.com/WebAssembly/WASI/blob/main/phases/snapshot/docs.md#-sock_acceptfd-fd-flags-fdflags---resultfd-errno

[mhdawson]

@flouthoc thanks for clarifying that.

[font]

@mhdawson WASI API proposals have several different phases. The socket APIs e.g. sock_accept, sock_recv, sock_send, and sock_shutdown are all in the latest WASI snapshot preview 1 as @flouthoc points out, which means they are usable APIs, but may still be subject to change as they are still only in Phase 1 - Feature Proposal. So I think it's OK to start using/implementing them while keeping in mind the above caveats.

[mhdawson]

@flouthoc, @font I was looking at the Node.js implementation of the socket proposal and I think what stalled it out was WebAssembly/WASI#4.

Do you know if that has effectively been abandoned and the current 4 methods defined are what will be in place going forward or will it still likely be replaced by the streaming approach mentioned in that issue?