Skip to content

SYSTEM Cited by 3 sources

Emscripten

Emscripten is a compiler toolchain that translates C and C++ source code into WebAssembly (plus JavaScript glue) runnable in browsers. It is the standard way to take a large native codebase and make it browser-shippable without rewriting in TypeScript / JavaScript.

Open-source, hosted at github.com/emscripten-core/emscripten.

What it provides

  • Wasm output from C/C++ source (via LLVM backend).
  • JS glue that sets up the Wasm module, marshals data across the JS↔Wasm boundary, and proxies browser-API calls.
  • POSIX shims — a subset of POSIX APIs emulated over browser equivalents (filesystem, timers, sockets).
  • Bindings for browser APIs — including (until recently) a built-in WebGPU binding layer that let C++ WebGPU calls transparently land on the browser's WebGPU API. This built-in layer is now deprecated in favor of Dawn's emdawnwebgpu bindings.

Why it matters

  • Teams with mature C++ codebases (graphics engines, CAD kernels, physics engines, audio engines, emulators) can ship them to the browser without a ground-up rewrite.
  • Combined with browser APIs like WebGPU and WebAssembly SIMD, this closes much of the historical gap between web and native performance for compute-heavy workloads.

Seen in

  • sources/2026-04-21-figma-rendering-powered-by-webgpu — Figma's C++ renderer is compiled to Wasm via Emscripten for the browser client, with custom C++/JS bindings written in cases where the built-in bindings weren't performant enough. The same C++ code is also compiled natively (x64/arm64) for server-side rendering, yielding a one-codebase / two-target story. In-flight migration from Emscripten's deprecated built-in WebGPU bindings to Dawn's emdawnwebgpu.

PyEmscripten: standardizing Python-package cross-compilation (2026-09-21)

Emscripten is the toolchain lineage under PyEmscripten, the platform Cloudflare standardized via PEP 783 so Python packages with native C/C++/Rust extensions can be cross-compiled to Wasm once and published for every PyEmscripten-implementing environment (browsers, Pyodide, Python Workers). Before this, Cloudflare had to hand-compile and host custom Wasm wheels, sharply limiting usable packages. Cloudflare also stabilized the Pyodide build toolchain and added PyEmscripten support to cibuildwheel — so the standard Python wheel-building tool can emit Wasm wheels.

(Source: sources/2026-09-21-cloudflare-python-workers-are-now-generally-available)

-sWASM_BINDGEN: cooperating with wasm-bindgen, and the Rust Emscripten target (2026-09-28)

Historically Emscripten and wasm-bindgen conflicted: both "assume they are in charge of loading and interacting with JavaScript and generating the final JS and Wasm output", so a project could commit to one or the other but never both. The resolution (initiated by Google's Portable Toolchains team — Mitch Foley + Yifan Yang — reviewed/supported by Cloudflare) has them cooperate: Emscripten continues to drive the build, load the Wasm module, and provide the companion JS, while wasm-bindgen emits a smaller portable version of its bindings that slots into Emscripten's library system. Landing this required changes in both projects plus a mutual commitment to maintain integration tests depending on the other. The result is the new -sWASM_BINDGEN setting, and a new wasm32-unknown-emscripten target in wasm-bindgen, with two interop directions:

  1. C++ Emscripten builds (driven by Emscripten's compiler) can link static wasm-bindgen Rust code — both binding layers coexist.
  2. Rust apps using wasm-bindgen (driven by Rust's compiler) can build for the Emscripten target — both binding layers coexist.

Why it matters for Cloudflare Workers: native Rust + Tokio

Because Emscripten "makes it possible to run and bridge native code with the web platform, including … virtualizing platform features such as timers, file system operations, sockets", and because Cloudflare Workers supports Web Platform APIs + Node.js compatibility, Cloudflare can run Emscripten on Workers using its Node.js compilation flags — fully virtualizing timers, FS, and sockets on top of the existing Node.js APIs. This unlocks running native Rust code, including Tokio-based applications, on Workers (contrast today's wasm32-unknown-unknown workers-rs target). Many Rust libraries worked out of the box because "Emscripten already supports the target_family = unix in Rust"; the low-level ones that didn't (libc, socket2, Mio) mostly just needed target_os = "emscripten" added to existing platform gates — trivial, infrequent, well-received target-gate patches. (Source: wasm-bindgen Emscripten docs)

Node.js FS + socket flags: -sNODERAWFS and -sNODERAWSOCKETS (2026-09-28)

Emscripten's Node.js flags are the bridge that make native syscalls work on Workers via Cloudflare's Node.js compat layer:

  • -sNODERAWFS (pre-existing) forwards native filesystem calls straight to Node's FS APIs. In the Pumpkin PoC, Pumpkin's std::fs world writes land on the node:fs Workers compat layer, then on a SQLite-backed Durable Object FS via worker-fs-mount.
  • -sNODERAWSOCKETS (new — contributed by Cloudflare in 40+ PRs) is the socket counterpart: Emscripten previously supported only poll() + a WebSocket emulation layer, not epoll_wait(), which Tokio's I/O driver (via Mio) needs. Rather than build a custom bridge, Cloudflare reused the node:net API already in its Node.js compat layer — so -sNODERAWSOCKETS gives epoll + TCP + UDP + Unix sockets to Emscripten apps in Node.js, and, because Workers implements the same node:net API, on Workers too, with no custom APIs on either side. For the LocalEventLoop path, a drafted emscripten_epoll_add_listener API associates a JS callback with an epoll's ready events; the next drive() collects them with a zero-timeout epoll_wait().

(Source: sources/2026-09-28-cloudflare-supporting-native-rust-in-workers-with-the-new-emscripten-target)

Seen in (additional)

Last updated · 766 distilled / 2,225 read