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 usually
Just 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 a system library won't work.
Using C libraries will also probably fail to work, since wasm doesn't have a
stable ABI for cross-language communication, and cross-language linking for wasm
is very finicky. Everyone wants this to work eventually, especially since
clang is shipping their
wasm32 target by default now, but the story isn't
quite there yet.
WebAssembly does not have access to a file system, so crates that assume the existence of a file system — and don't have wasm-specific workarounds — will not work.
There are plans to add threading to WebAssembly, but it isn't
shipping yet. Attempts to spawn on a thread on the
target 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 particular algorithm or data structure, for example A* graph search or splay trees, tend to work well with WebAssembly.
Crates that do not rely on the standard library tend to work well with WebAssembly.
Parsers — so long as they just take input and don't perform their own I/O — tend to work well with WebAssembly.
Crates that deal with the complexities of human language when expressed in textual form tend to work well with WebAssembly.
Shared solutions for particular situations specific to programming in Rust tend to work well with WebAssembly.