WASI support

[daxpedda]

This issue will be used to collect discussions and issues about WASI support in wasm-bindgen.

Generally speaking wasm-bindgen doesn't currently support WASI, but we should figure out if we want to support it (#3324) or disable it (#3233).

The original plan, outlined here: #1841, now doesn't have the necessary developer support. But the motivation for it, the component model (previously interface types), isn't here yet either.

Input from stakeholders would help a lot!

[csnover]

A library I was working with compiled and linked to a C library using the cc crate, and I believe that wasm-bindgen is not usable in that case unless it supports WASI. (I say ‘believe’ because I was never able to find a channel that was still active to get confirmation from someone authoritative, but at least it seemed like WASI was the ‘blessed’ way to make this work. I at least was unable to find some other way to make it work in the time I had to investigate.)

[daxpedda]

I guess this is one use-case: having WASI dependencies.

But I would argue that this is really a bad workaround, C libraries can target Wasm without WASI or Emscripten just fine. If any WASI function is used it wouldn't work in the browser anyway without a compatibility shim.

On the other hand I understand that the only Wasm target C/C++ libraries usually support is Emscripten, or WASI if they are more modern. As hacky as I described this above, it's a workaround many users could require.

Though I've honestly no clue if you can use a WASI dependency successfully or not with wasm-bindgen, so more input would be appreciated. Thanks @csnover.

[csnover]

Getting a WASI provider into the browser that covered the required system calls was trivial with https://github.com/bjorn3/browser_wasi_shim and required less than 10 LOC change to the bootstrap JS to make it send the required imports when instantiating the module, so this is no barrier.

The third-party C dependency has no knowledge of wasm and used system calls which are available in the WASI shim; I do not understand the comment about it being a ‘bad workaround’ so would be interested to understand more where you are coming from in this regard.

I am not paying attention to the wasm ecosystem to understand what is what, but as an outsider exploring the space for the first time, it looked like WASI being positioned as the standard ABI. Maybe that is just an wrong impression though?

[daxpedda]

Getting a WASI provider into the browser that covered the required system calls was trivial with https://github.com/bjorn3/browser_wasi_shim and required less than 10 LOC change to the bootstrap JS to make it send the required imports when instantiating the module, so this is no barrier.

I agree, it's not a barrier.

The third-party C dependency has no knowledge of wasm and used system calls which are available in the WASI shim; I do not understand the comment about it being a ‘bad workaround’ so would be interested to understand more where you are coming from in this regard.

So I'm searching for the "how it's supposed to be done". WASI isn't supported by the browser, that's why a shim is required.

The "proper" way to do it is to compile to Wasm, not to WASI, which C/C++ is able to. Any C/C++ library not using any system calls will support the Wasm target (barring any complications with build systems 🤣), but as mentioned above, C/C++ libraries that do use system calls, don't commonly support targeting Wasm, but Emscripten.

(I'm using the term "Wasm" here as in the bare target, without WASI or Emscripten.)

---

I'm not against supporting WASI in wasm-bindgen by the way. Just trying to determine how useful, necessary and burdensome it will be.

The original plan for wasm-bindgen was to support WASI anyway, but in a very different way we are now not able to do anymore, see #1841.

[csnover]

I understand what you were saying now, thank you for sharing.

For what it is worth I don’t have much skin in the game at all here; I was just told by someone recently that the emscripten target for Rust did not work, took that claim at face value, saw that WASI was being developed under the WebAssembly group, and assumed this meant the ecosystem had agreed to move toward WASI as the universal ABI for runtimes that need system interface.

I was able to hack wasm-bindgen into working with the wasi target within a day so it seems like it’s mostly there, but it is possible that I didn’t exercise the interface enough since I was only doing it as a proof of concept.

Today I read some discussions in the WASI WG repo and have much more uncertainty as to whether there is actually a commitment to ensure first-class web platform support. Hopefully they are able to resolve that one way or the other since this is the sort of ambiguity that kills standards.

Let me know if there is any other feedback I can provide. Thanks again!

[itsezc]

Not at all sure if its entirely related but as someone who actively uses the web-sys crate, I'd love to see component model come to life (sooner than later) and hope that application developers can get away with little to no refactoring (just a dream); I'd love to see WASI supported.