3 ms·
To me it sounds like you could implement some parts of the WASI in JavaScript, so a WASM module depending on WASI doesn’t preclude it from running in the browse
by jitl 4y ago
To me it sounds like you could implement some parts of the WASI in JavaScript, so a WASM module depending on WASI doesn’t preclude it from running in the browser or a browser-like runtime. Instead of a bespoke shim generated by the compiler, you could use a standardized shim that provides a known subset of WASI.
On the other hand relying on JS shims means a lot of guaranteed copying to/from the JS heap, which is a very annoying speed tax compared to… not.
I wonder why browsers don’t allow direct WebIDL-based APIs direct from WASM to browser APIs
- paulgb 4y agoIndeed, some people are doing this: - WASI once had an official polyfill https://wasi.dev/polyfill/ https://wasi.dev/polyfill/, now apparently succeeded by https://github.com/bjorn3/browser_wasi_shim https://github.com/bjorn3/browser_wasi_shim - wasmer-js provides a JS polyfill for WASI https://docs.wasmer.io/integrations/js/wasi https://docs.wasmer.io/integrations/js/wasi - Cloudflare has a WIP polyfill https://github.com/cloudflare/workers-wasi 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.
- jitl 4y ago> non-temporary polyfill Isn’t that what the compiler generated shim is that something like Emscripten emits? The Emscripten wrapper code is… frustrating.
- hardwaregeek 4y agoWasmer's one in theory works in the browser but I've yet to have it work. You have to polyfill some stuff like Buffer and even then you run into some annoying runtime Wasm errors.