browser_wasi_shim VS lol_alloc

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.

As a note, you might find some references to use wee_alloc, but it has been unmaintained for some time and shouldn't be used. I'm using the default allocator with the wasm32-wasi target and it works fine, but I don't know if that works with wasm32-unknown-unknown too; if not there's lol_alloc.