Most Rust developers expect the pitch to hold: compile to WebAssembly, ship to the browser, no C required. Add the wasm32-unknown-unknown target, run wasm-pack build, and you're done.

Then you try it on a real project. Four traps, none of them in the getting-started docs: a deprecated allocator with a memory leak, hidden C dependencies scattered through the ecosystem, a random number crate that silently misbehaves, and bundle sizes that balloon from Emscripten glue.

The Problem with "Just Use Rust"

The core appeal of Rust for WASM is real: no garbage collector, predictable memory, and — in theory — no need for the C/C++ toolchain that browser WASM has historically required.

But the Rust crate ecosystem has C dependencies scattered throughout it, often invisible until compile time. A project that builds fine on Linux will fail on wasm32-unknown-unknown because three levels down in the dependency tree, something links to libz, openssl, or a system RNG.

When I built chem-wasm-lens — a molecular analysis library for the browser — I needed to stay completely C-free. The alternative, RDKit (the standard C++ cheminformatics toolkit), compiles to a ~40MB WASM bundle via Emscripten. My target was under 200KB gzipped. Getting there meant systematically hunting down every C dependency.

The Allocator Story

Every WASM tutorial from a few years ago recommended wee_alloc: a tiny allocator that shrank bundle size and was the default in wasm-pack new.

wee_alloc was archived in August 2025. It has a known memory leak and is no longer maintained. If you have it in an existing project, remove it:

# Cargo.toml — remove this line
wee_alloc = "0.4"

// lib.rs — remove these lines
#[global_allocator]
static ALLOC: wee_alloc::WeeAlloc = wee_alloc::WeeAlloc::INIT;

The current state of WASM allocators:

• Default (dlmalloc): Rust's wasm32-unknown-unknown target uses dlmalloc as the default global allocator. It's a pure Rust implementation — no C, no system calls. For most browser WASM projects, this is fine.
• lol_alloc: Written as a wee_alloc replacement. Smaller than dlmalloc, but the author documents it as not production-ready.
• talc: A newer allocator, benchmarked as smaller and faster than dlmalloc. Worth watching for size-critical projects.

For most projects: just use the default and move on. The allocator is no longer the interesting problem. The interesting problem is transitive C deps.

The Hidden C Dependency Tree

The most common wasm-pack build failure isn't your code — it's a crate three levels deep that silently links to C. The build error typically looks like:

error: failed to run custom build command for `openssl-sys v0.9.x`
  ...
  Could not find directory of OpenSSL installation.

Or for ring:

error: failed to run custom build command for `ring v0.17.x`
  ...
  the target `wasm32-unknown-unknown` is not supported

-sys crates are the signal. Any crate with a -sys suffix wraps a native library:

• openssl-sys — OpenSSL
• libz-sys — zlib
• bzip2-sys — libbz2
• libsqlite3-sys — SQLite
• ring — cryptography (C code for performance-critical paths)

You probably didn't add any of these directly. reqwest pulls in openssl-sys by default. flate2 uses libz-sys by default. sqlx brings in libsqlite3-sys.

How to detect them:

cargo tree --target wasm32-unknown-unknown | grep "\-sys"

Example output from a project using reqwest and flate2:

├── flate2 v1.0.x
│   └── libz-sys v1.1.x (*)       ← C dependency
├── reqwest v0.12.x
│   └── openssl-sys v0.9.x (*)    ← C dependency

Any -sys crate in the output is a potential blocker.

Common replacements:

Here's what a typical fix looks like in Cargo.toml:

[dependencies]
# Before (pulls in openssl-sys):
# reqwest = "0.12"

# After (pure Rust TLS):
reqwest = { version = "0.12", default-features = false, features = ["rustls-tls", "json"] }

# Before (uses libz-sys by default):
# flate2 = "1.0"

# After (pure Rust miniz backend):
flate2 = { version = "1.0", default-features = false, features = ["miniz"] }

The ring situation deserves a specific note. ring powers most TLS stacks in the Rust ecosystem, and it contains C code for performance-critical paths. On wasm32-unknown-unknown, it fails to compile.

For browser WASM, this is usually not a problem — the browser's fetch API handles TLS transparently, so Rust code never touches it. For non-browser WASM runtimes (WASI, Wasmtime), look at RustCrypto crates, which provide pure Rust cryptographic primitives, or aws-lc-rs, which has better WASM support than ring.

The getrandom Footgun

Many crates need random numbers — UUID generation, HashMap initialization, cryptographic primitives. They all end up depending on getrandom.

On wasm32-unknown-unknown, getrandom doesn't know where it is. The target name alone says nothing about whether you're in a browser, a WASI runtime, or a bare-metal environment. Without explicit configuration, the build fails or panics at runtime, depending on the version.

First, find which version is in your tree:

cargo tree | grep getrandom

The fix depends on the version:

getrandom 0.2.x — add the js feature:

# Cargo.toml
[dependencies]
getrandom = { version = "0.2", features = ["js"] }

getrandom 0.3.x — feature flag plus a backend declaration:

In 0.3.x, getrandom introduced a "backend" model that separates feature flags from backend selection. Both are required:

# Cargo.toml
[dependencies]
getrandom = { version = "0.3", features = ["wasm_js"] }

# .cargo/config.toml
[target.wasm32-unknown-unknown]
rustflags = ["--cfg", "getrandom_backend=\"wasm_js\""]

The transitive dependency trap. You can't set feature flags for indirect dependencies directly. If uuid depends on getrandom and you don't use getrandom yourself, you still need to declare it explicitly so Cargo's feature unification propagates the flag:

[dependencies]
uuid = { version = "1", features = ["v4"] }
# Explicitly declare getrandom to force the js feature through the tree
getrandom = { version = "0.2", features = ["js"] }

The getrandom docs also recommend against enabling js/wasm_js in libraries — it breaks non-browser WASM builds. For a browser-only library like chem-wasm-lens, enabling it unconditionally is the right call, but the documentation buries this distinction.

Bundle Size

This is where C dependencies have their most visible cost.

C libraries compiled to WASM via Emscripten carry significant overhead: libc, libc++, a malloc implementation, and Emscripten runtime glue — regardless of how much of it you actually use. Tree shaking doesn't cross the FFI boundary. The result:

• RDKit.js: ~40MB (Emscripten-compiled C++ cheminformatics)
• OpenSSL compiled to WASM: ~1–2MB just for the crypto primitives

Pure Rust compiles lean. chem-wasm-lens ships at 411KB uncompressed, ~200KB gzipped — and that includes SMILES parsing, 2D coordinate generation, SVG rendering, ECFP4 fingerprint similarity, and PDB parsing. The size difference isn't magic; it's the absence of Emscripten glue, Rust's dead code elimination working cleanly across #[wasm_bindgen] exports, and wasm-opt running automatically on release builds.

Check your own binary size after building:

wasm-pack build --release
ls -lh pkg/*.wasm

If the .wasm is unexpectedly large, profile it with Twiggy to see what's taking up space:

cargo install twiggy
twiggy top pkg/your_crate_bg.wasm

The Current Ecosystem State

Where things stand, mid-2025:

Practical Checklist

Before shipping a Rust WASM project:

1. Audit with cargo tree

   cargo tree --target wasm32-unknown-unknown | grep "\-sys"

Any -sys crate is a potential blocker.

1. Remove wee_alloc — archived in August 2025, has a memory leak. The default dlmalloc is fine.

2. Handle getrandom explicitly — run cargo tree | grep getrandom to find the version, then add it explicitly to [dependencies] with the right feature flag, even if you don't use it directly.

3. Replace system TLS — swap openssl/openssl-sys for rustls, or use reqwest with default-features = false, features = ["rustls-tls"].

4. Fix flate2 — use default-features = false, features = ["miniz"] to disable the libz-sys backend.

5. Build with --release — wasm-pack build --release runs wasm-opt automatically. Debug builds skip optimization and are typically 3–5x larger.

Closing Thought

The Rust-to-WASM path is genuinely good, and it's improving. The C ABI for wasm32-unknown-unknown is being standardized (Rust blog, April 2025), wee_alloc's archival simplified the allocator story, and wasm-pack keeps getting better.

Most popular Rust crates predate WASM as a real target, and they picked up C dependencies along the way. The audit is tedious but a one-time fix — once you know which -sys crates to watch for and what replaces them, it doesn't keep coming back.

I hit all four of these problems building chem-wasm-lens, a pure Rust + WASM molecular analysis library for the browser. The table above is what I found trying to go from a ~40MB Emscripten-compiled baseline down to ~200KB gzipped.