wasmer-js VS browser_wasi_shim

});

I was then able to just use this code example with one caveat (https://github.com/wasmerio/wasmer-js?tab=readme-ov-file#use...)

I had to update the SDK import with crossorigin="anonymous"

I use https://github.com/wasmerio/wasmer-js and while v0.12 works fine, v1.2 never returns and is stuck in a busy loop internally somewhere. I did not bother bisecting it because the API changed at v1.0.

You can run WASI/WASM modules in the browser using e.g. the (rather simplistic) official WASI polyfill or the more fully-featured wasmer/wasi. So while htis is certainly a bit more combersome than a direct JS FFI, you should already be able to interact with WASI/WASM-compiled Haskell code from JS.

Good spotto! That's the WASI runtime from wasmerjs (https://github.com/wasmerio/wasmer-js).

That's not the WASI runtime being used in this playground. The one in this playground is @runno/wasi-motor (https://github.com/taybenlor/runno/tree/main/packages/wasi-m...). I haven't released it as an NPM package, but it's all MIT so feel free to copy it.

WASI Modules via Wasmer JS

I have good news! Wasmer can also be run on the browser. Check out wasmer-js [1]

[1] https://github.com/wasmerio/wasmer-js/

Maybe wasmer-js could be used by Deno to provide WASI support inside their engine? :-)

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.