Which Crates Will Work Off-the-Shelf with WebAssembly?

It is easiest to list the things that do not currently work with WebAssembly;crates which avoid these things tend to be portable to WebAssembly and usuallyJust Work. A good rule of thumb is that if a crate supports embedded and#![no_std] usage, it probably also supports WebAssembly.

Things a Crate Might do that Won't Work with WebAssembly

C and System Library Dependencies

There are no system libraries in wasm, so any crate that tries to bind to asystem library won't work.

Using C libraries will also probably fail to work, since wasm doesn't have astable ABI for cross-language communication, and cross-language linking for wasmis very finicky. Everyone wants this to work eventually, especially sinceclang is shipping their wasm32 target by default now, but the story isn'tquite there yet.

File I/O

WebAssembly does not have access to a file system, so crates that assume theexistence of a file system — and don't have wasm-specific workarounds— will not work.

Spawning Threads

There are plans to add threading to WebAssembly, but it isn'tshipping yet. Attempts to spawn on a thread on the wasm32-unknown-unknowntarget will panic, which triggers a wasm trap.

So Which General Purpose Crates Tend to Work Off-the-Shelf with WebAssembly?

Algorithms and Data Structures

Crates that provide the implementation of a particularalgorithm or datastructure, for example A* graphsearch or splay trees, tend to work well with WebAssembly.

#![no_std]

Crates that do not rely on the standardlibrary tend to work well withWebAssembly.

Parsers

Parsers — so longas they just take input and don't perform their own I/O — tend to workwell with WebAssembly.

Text Processing

Crates that deal with the complexities of human language when expressed intextual form tend to work wellwith WebAssembly.

Rust Patterns

Shared solutions for particular situations specific to programming inRust tend to work well with WebAssembly.