cargo-wasi
browser_wasi_shim
| cargo-wasi | browser_wasi_shim | |
|---|---|---|
| 2 | 6 | |
| 446 | 338 | |
| 0.0% | 5.0% | |
| 3.3 | 7.3 | |
| over 1 year ago | about 1 month ago | |
| Rust | TypeScript | |
| Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
cargo-wasi
-
Rust + WASM + Typescript [+ React]
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.)
-
#![no_std] with WASI is more complicated than I thought it would be
I use cargo-wasi to build it:
browser_wasi_shim
-
Show HN: Exiftool-web, an interface for the CLI tool (running Perl in WASM)
This was a pretty fun weekend hack, wasn't (easily) possible until a few weeks ago when I found this blog post about how to execute Perl in WebAssembly. https://andrews.substack.com/p/zeroperl-sandboxed-perl-with-...
As I gather, Exiftool is used a bunch by OSINT researchers, many who aren't big fans of the CLI, so I figured this would be a fun browser port. The above + https://github.com/bjorn3/browser_wasi_shim and some regular Svelte/file API stuff were enough, pretty proud of this demo.
Thinking if I get some more time this weekend I may implement metadata editing / deleting, and bundling these into desktop apps would not be super tricky.
-
Rust + WASM + Typescript [+ React]
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.)
- Is it possible to read a file through webassembly?
-
Extending web applications with WebAssembly and Python
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.
-
The Tug-of-War over Server-Side WebAssembly
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 to Haskell Wasm Reactor Module Communication Example
Browser client library uses browser_wasi_shim to communicate with the module.
What are some alternatives?
wee_alloc - The Wasm-Enabled, Elfin Allocator
memory-control - A proposal to introduce finer grained control of WebAssembly memory.
compiler-builtins - Porting `compiler-rt` intrinsics to Rust
hangover - Hangover runs simple Win64 and Win32 applications on arm64 Linux
wasi-rs - Experimental WASI API bindings for Rust
wasmer-js - Monorepo for Javascript WebAssembly packages by Wasmer