browser_wasi_shim VS wee_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.

Note that the wasm-pack tutorial recommends using the wee_alloc crate. This crate is unmaintained and leaks memory, so it should be avoided. Remove this crate, the default allocator works just fine in WebAssembly.

It leaks memory: https://github.com/rustwasm/wee_alloc/issues/106

Last thing that comes to mind is switching the allocator to wee_alloc. I use it most of the time for wasm projects and it doesn't make too much of a difference in binary size but that always depends on the project and usually saves at least a few kB.

For example, check out wee_alloc.

wee_alloc, an allocator optimized for small code size.

Ok. Now I need to add in a global allocator. I use wee_alloc since I know it works pretty well with WASM: Cargo.toml