3 ms·
> these projects use Emscripten, but in the future the same Wasm32-wasi module will work I'm curious to know more about this. Does it mean that when browsers s
by lioeters 3y ago
> these projects use Emscripten, but in the future the same Wasm32-wasi module will work
I'm curious to know more about this. Does it mean that when browsers support WASI, these projects will not need to use Emscripten? Or maybe use it for compiling to/with WASI but without the need for a runtime anymore.
Is there anywhere I can keep track of when/how this might happen?
- angelmm 3y agoThose are great questions! I believe Emscripten will be required for some cases as it provides more features for targeting a Web Browser. If WASI is the only requirement for a Wasm module, then there are three possible solutions: - Use a library that provides the WASI bindings in a browser environments: there are some OSS projects that provides WASI bindings on top of browser technologies. For example, workers-wasi from Cloudflare [1]. It could be even another Wasm module that provides the implementation for the main one. I know the people from Loophole Labs are experimenting with virtual filesystems (VFS) [2]. - Browsers provides a WASI implementation: server-oriented runtimes like NodeJS are already providing these bindings (under a experimental flag). I shouldn't have stated that as a fact, as browsers may provide it or not. However, I saw in the past the Google Chrome team experimenting with WASI and the browser FileSystem API [3]. So, I think it may happen :) - [1] https://github.com/cloudflare/workers-wasi https://github.com/cloudflare/workers-wasi - [2] https://www.youtube.com/watch?v=46jZSXVxYPw https://www.youtube.com/watch?v=46jZSXVxYPw - [3] https://github.com/GoogleChromeLabs/wasi-fs-access https://github.com/GoogleChromeLabs/wasi-fs-access
- lioeters 3y agoI appreciate the response, thank you! I've really enjoyed following the explorations of Wasm Labs.