I am scoping out an app and would like to compile the Rust side of things into Web Assembly. I have a basic skeleton lib.rs file that I built from a tutorial I found. Without the autonomi crates it builds the WASM binary fine, but when I run wasm-pack with the latest autonomi crate listed I get 5 errors in the ‘evmlib’ crate. Here is my Cargo.toml:
[package]
name = "myapp"
version = "0.1.0"
edition = "2024"
[build]
rustflags = ["--cfg", "tokio_unstable"]
[dependencies]
autonomi = "0.4.1"
tokio = { version = "1.44.1", features = ["macros"]}
wasm-bindgen = "0.2"
getrandom = { version = "0.2", features = ["js"] }
[lib]
crate-type = ["cdylib", "rlib"]
I probably don’t need the features flag for tokio. I ran into build errors on that one until I put in the ‘tokio_unstable’ flag, which by itself may be a bad thing.
Anyone else have any luck going the WASM route?
6 Likes
@bzee from Autonomi may be able to comment.
AFAIK this is a dead end for the time being because of limitations around network access, but I’m not sure so hopefully Benno will comment.
6 Likes
Pretty much that is the point. Consider WASM compiled javascript. It has the limitations of javascript, so cannot access native UDP/tcp/QUIC although there are attemtps to do so. There is webrtc etc. so there are moves afoot, but we don’t support webrtc
Adding WASI would help, but that is not moving forward quickly enough.
So WASM has a place, it can handle any non network/no discs stuff. So many use it for wallets and that kind of cryptography where you want more control and speed etc.
We will be putting out nodejs bindings, that works as there is a backend (node) that does have network and disk access.
7 Likes
Ah, that makes sense. Thanks for the info. Any estimates on when the nodejs bindings will be available for use?
1 Like
They are in process, you might see some PRs if you look as they are being coded as we speak.
2 Likes