Future of Rust/WASM for Web?

50 points BuzzingConfusion

I've been recently thinking about where WASM on the web is heading, and it's exciting but also kind of a mess. There's a lot of cool stuff happening both in and out of the browser, like web workers with shared array buffers and the recent release of WASI preview 2. But the ecosystem for WASM in the browser feels super fragmented.

For example, there are tons of ways to interact with web APIs. In the C world, there's Emscripten, while Rust has js-sys and wasm-bindgen. Go has JSGo. Outside the browser, the WASI project is trying to standardize an ABI, but it won't be usable in the browser anytime soon (plus, it doesn't currently give access to web-like APIs like WebGPU).

Rust seems to have mostly abandoned its Emscripten target, which makes it feel like Rust and C-like languages are drifting apart when it comes to targeting the web. This is frustrating because, even though WASM is now an official Tier 2 Python target and there are impressive projects like Pyodide that can compile CPython (or even micropython) to WASM, writing a non-complex Rust module to work in that environment is tricky. A lot of Rust dependencies that rely on web APIs don't support the wasm32-unknown-emscripten target (and obviously also mot the Pyodide JS APIs).

This fragmentation makes sense without a standardized ABI for browsers, but I haven't seen any major efforts to bridge these gaps. Has anyone thought about this recently or is anyone working on something that could help unify these fragmented parts?