The goal of this crate is to "run wasmtime on the web", that means providing a unified API for desktop and web runtimes.
With wasm-bridge, you can write a single source code in Rust that you would normally write when using wasmtime,
but it works on desktop as well as on the web.
In general, you would use this crate the same way wou would use wasmtime, and just replace wasmtime with wasm_bridge.
Alternatively, refer to this handy table:
| Use case | 📝 Text tutorial | 🧾 Full example | 📑 Test cases | |
|---|---|---|---|---|
| No bindgen | Read here | Coming soon | See here | Explore here |
| Component model | Read here | Coming soon | Coming soon | Explore here |
| Component model with WASI | Coming soon | Coming soon | Coming soon | Explore here |
wasm-bridge |
wasmtime |
wit-bindgen |
cargo-component |
|---|---|---|---|
0.5.x |
20.0 |
0.24.0 |
0.11.0 |
0.4.x |
19.0 |
0.24.0 |
0.10.1 |
0.3.x |
15.0 |
0.15.0 |
0.5.0 |
0.2.x |
11.0 |
0.8.0 |
- |
0.1.x |
10.0 |
- | - |
There are other options for loading and executing WASM modules on the desktop and on the web in RUST: wasmer can run on the web with the js feature flag, wasmi is an interpreter so it has no problem running on the web, and wasm_component_layer provides a unified API that can be "backed" by a number of "backends".
| Crate | Short description | Component model | Wasi support |
|---|---|---|---|
wasm-bridge |
Re-exports wasmtime on sys, js-sys impl on web. |
Yes, but no resources. | Partially yes. |
wasmer |
Native impl in sys, js-sys impl on web. |
They have wai bindgen. |
Yes. |
wasmi |
Lightweight WASM interpreter, run anywhere. | Planned. | Experimental wasmi_wasi crate. |
wasm_runtime_layer |
Thin wrapper around wasmtime or wasmi, js-sys impl on web. |
wasm_component_layer, but no bindgen. |
Not to my knowledge. |
The source code of wasm-bride is licensed under MIT, but there are portions that are copied from other projects,
and may come with a different license.
Here is a full list of these exceptions:
- The
wasmtime-component-macrocrate "fork".