team VS browser_wasi_shim

Further down that GitHub issue, it mentions the problem has been fixed:

* https://github.com/rust-lang/rust/issues/71871#issuecomment-...

* https://github.com/rust-lang/rust/pull/79998

Weirdly though, there's another issue (opened prior) that's ongoing and seems to indicate things aren't fixed after all:

* https://github.com/rustwasm/team/issues/291

As for all the rust-wasm stuff, the dispute makes little sense. The "opposition" wants her to transfer publishing rights to a Github group actively being sunsetted and portraying it as a power struggle, yet this struggle is taking place in an issue Williams started in an effort to transfer ownership. Based on the last comments, it looks like publishing rights have been distributed to other members so the whole narrative is effectively moot.

I don't have direct WebAssembly experience (So far, my projects have either required stuff not compatible with WASI or been DOM-centric "must degrade gracefully with JavaScript disabled" stuff) but this thread looks like a good starting point for answering that question.

There are many options, but what worked best for me is compiling with cargo-wasi and loading the resulting Wasm file with browser_wasi_shim. Using wasm32-wasi instead of wasm32-unknown-unknown requires a bit more work (the communication with JS has to be set up manually), but gives the flexibility of having just a Wasm file that can be dropped in and loaded dynamically. (There's wit-bindgen for generating wrapping code according to an interface definition but I didn't have much success with it.)

The webassembly-language-runtimes is focused on providing WASI-based language interpreters, what would require a WASI polyfill at the browser level (https://wasi.dev/polyfill/) and (https://github.com/bjorn3/browser_wasi_shim).

Pyodide is certainly another option, but is emscripten based, not based in webassembly-language-runtimes or WASI.

Indeed, some people are doing this:

- WASI once had an official polyfill https://wasi.dev/polyfill/, now apparently succeeded by https://github.com/bjorn3/browser_wasi_shim

- wasmer-js provides a JS polyfill for WASI https://docs.wasmer.io/integrations/js/wasi

- Cloudflare has a WIP polyfill https://github.com/cloudflare/workers-wasi

I'm generally leery of non-temporary polyfills, so I'm not sure that any of these feel like a long-term viable option for me.

Browser client library uses browser_wasi_shim to communicate with the module.