Skip to content

SYSTEM Cited by 2 sources

wasm-bindgen

wasm-bindgen is the core Rust project that generates the Rust↔JavaScript bindings every Rust-on-Wasm runtime depends on — including Rust Workers. It walks the Rust source to emit a paired Wasm module + JS glue so that Rust types, exported functions, async functions, and closures can be called from JavaScript and vice versa, and so that async Rust can reject JS Promises with typed errors.

Role on this wiki

Canonical wiki instance of co-maintained critical-path infrastructure on the Rust Wasm stack. Cloudflare became part of the wasm-bindgen organization formed in 2025 (replacing the sunset rustwasm GitHub org) alongside the Rust WebAssembly working group and independent maintainers, and used that role to move Rust-Workers reliability fixes from a platform-private wrapper into the shared project.

What Cloudflare's 2026-04 work added

  • panic=unwind support for wasm32-unknown-unknown — wasm-bindgen now generates exports that catch panics at the Rust↔JS boundary and surface them as JavaScript PanicError exceptions, using the WebAssembly Exception Handling proposal.
  • Walrus exception- handling support — the WebAssembly parser wasm-bindgen uses had to be taught try / catch instructions; the descriptor interpreter had to evaluate exception-handling blocks.
  • extern "C-unwind" on exports so Rust doesn't abort when a foreign exception unwinds through the boundary.
  • MaybeUnwindSafe trait + Closure::new_aborting variants — see unwind-safety. The aborting variants terminate on panic when unwind-safety of captured state can't be proven, avoiding the AssertUnwindSafe-footgun.
  • Exception.Tag for foreign exceptions — lets embedders distinguish recoverable unwinds from genuine aborts at the JS boundary. "We chose to mark all errors which are definitely unwinds."
  • set_on_abort hook — attach a handler at initialization time that recovers from aborts according to the embedder's needs. Canonical wiki instance of abort-recovery.
  • --reset-state-function (experimental) — exposes a function on the generated bindings that lets the Rust application request that its Wasm instance be reset to initial state on the next call. Benefits wasm-bindgen libraries imported by JS apps; class instances from the old Wasm instance throw (handles orphaned), new constructors work. "The JS application using a Wasm library is errored but not bricked."
  • Modern-exception-handling migration plan — "over the coming months, we'll be working to make the transition to stable panic=unwind and modern Exception Handling as invisible as possible to end users." Rust Wasm targets still default to the legacy variant today.

The reliability failure class wasm-bindgen now contains

Before: a single Rust panic or abort left the Wasm instance in an undefined state, so that instance could no longer serve any request safely — the sandbox poisoning class. After: panics unwind cleanly with destructors running and the instance remaining valid; aborts route through the set_on_abort hook for embedder-controlled recovery. "Implementing critical error recovery as the last line of defence ensures execution correctness and that future operations will be able to succeed. The invalid state does not persist, ensuring a single failure does not cascade into multiple failures."

The wasm32-unknown-emscripten target: cooperating with Emscripten (2026-09-28)

A second major line of wasm-bindgen work — first initiated by Google over a year ago, then reviewed/supported by Cloudflare's co-maintainers — added first-class support for the Emscripten wasm32-unknown-emscripten target. The original conflict: Emscripten and wasm-bindgen each "assume they are in charge of loading and interacting with JavaScript and generating the final JS and Wasm output", forcing a project to pick one. The fix makes them cooperate — Emscripten drives the build, loads the Wasm module, and provides the companion JS, while wasm-bindgen emits a smaller, portable version of its JS bindings in a format that slots directly into Emscripten's library system. Exposed as the new -sWASM_BINDGEN Emscripten setting, with two interop directions:

  1. C++ Emscripten code (Emscripten-compiler-driven) can be built against static wasm-bindgen Rust code — wasm-bindgen bindings alongside Emscripten bindings.
  2. Rust apps using wasm-bindgen (Rust-compiler-driven) can build for the Emscripten target — Emscripten bindings alongside wasm-bindgen bindings.

Landing this required changes in both projects and a mutual commitment to maintain integration tests that depend on the other. The payoff on Workers is large: because Emscripten virtualizes native platform features (timers/FS/sockets) over Workers' Node.js compat APIs, this target lets native Rust — including Tokio apps — run on Workers, well beyond the wasm32-unknown-unknown target that today's workers-rs uses. See the wasm-bindgen Emscripten reference. (Source: sources/2026-09-28-cloudflare-supporting-native-rust-in-workers-with-the-new-emscripten-target)

Seen in

Last updated · 766 distilled / 2,225 read