When WebAssembly earns its place: less often than the pitch suggests

The pitch for WebAssembly is near-native speed. That part is true, but it describes the state after the work, omitting loading, compilation, boundary crossings and data copying.

Three conditions have to hold together

1. Heavy computation: a single call does real work, not a handful of arithmetic operations
2. Bulk data: one large buffer goes in, instead of small arrays going back and forth
3. Few calls: boundary crossings are an order of magnitude rarer than the computation itself

When all three hold, WASM can be ten times faster or more. Miss one, and the boundary cost eats the gain.

The category that genuinely benefits

A C, C++ or Rust implementation already exists and sits on the hot path: image and media codecs, compression (the high settings of zstd or brotli), cryptography, physics and geometry, and anything needing a deterministic sandbox such as evaluating user-submitted expressions or hosting plugins. What these share: complex algorithms, clean boundaries, block-shaped data.

Three categories that do not

• Anything that touches the DOM. WASM cannot reach it, so every operation is forwarded through JavaScript, and one crossing can cost more than the work itself
• Small string processing. Regex, templates, formatting: tiny inputs and outputs, so boundary cost dominates
• Rewriting JavaScript for performance alone. The JIT handles integer loops and property access well enough; the rewrite often brings no gain and always brings a worse stack trace

The decision on this site: none of them

The heaviest computation here is solving sudoku, stepping a cellular automaton, hashing and image work, all in the millisecond range. Adding a WASM module would mean megabytes of download, a compile step and a call chain only debuggable through the browser console, in exchange for speed nobody can perceive.

Measure first. If the bottleneck is an O(n) loop, writing it in another language does not make it O(log n).