TL;DR
WebAssembly (Wasm) is actively used in production for targeted needs—game ports, image processing, plugin sandboxes and more—but it hasn’t replaced mainstream web app architectures. Its design as a compact, safe bytecode and a portable compilation target makes it valuable for embeddability and secure sandboxing, even as boundary costs and API gaps limit full-app adoption.
What happened
WebAssembly never vanished; instead it settled into a practical niche. Real products rely on it for specific capabilities: running C++ code in browsers (Figma, Godot), powering image tooling (Squoosh), enabling plugin sandboxes (Zellij) and reviving legacy media (Ruffle). Wasm is best thought of as a language/bytecode and compilation target rather than a drop-in replacement for JavaScript. It maps reasonably closely to machine code, supports many source languages (Rust, C, Go, Java, Kotlin, C#, and language runtimes like Python), and runs in both browsers and standalone engines (Wasmtime, WasmEdge, Wasmer). Wasm’s deny-by-default import model, linear memory and small instruction set create a strong security surface that enables fast, process-like isolation. At the same time, costs from crossing the host boundary, binary size inflation for common APIs, and missing native conveniences (for example, a standardized string type) limit its use as the single compilation target for large, incremental codebases.
Why it matters
- Wasm’s explicit import model and linear memory make it well suited for secure, embeddable sandboxes.
- It allows developers to reuse native libraries and language ecosystems in environments that already run a Wasm engine.
- Sandboxing in-process can yield large startup and resource-efficiency gains compared with spawning full OS processes.
- Gaps in system APIs and host boundary costs shape when Wasm is a practical choice versus when native or JS approaches remain preferable.
Key facts
- Wasm is a bytecode/compilation target comparable to JVM bytecode, but with a smaller API surface and different memory guarantees.
- Real-world users include Godot, Squoosh.app, Zellij, Figma, Stackblitz and Ruffle, where Wasm supports major features or entire products.
- Languages commonly compiled to Wasm include Rust, C, Zig, Go, Kotlin, Java and C#; interpreted runtimes such as Python, PHP and Ruby have also been compiled to Wasm.
- There are multiple Wasm runtimes independent of browsers, e.g., Wasmtime, WasmEdge and Wasmer.
- WAT is a textual S-expression format close to Wasm bytecode; it is possible to author Wasm by hand in WAT.
- Wasm’s security model treats external interactions as explicit host imports, enabling strong isolation and smaller attack surfaces.
- Cloudflare uses V8 isolates to run untrusted code efficiently; companies like Fermyon advertise sub-millisecond spinup times for Wasm workloads.
- Binary size can grow because libraries recreate system APIs instead of importing host APIs; standards like WASI aim to address this.
- The GC option for Wasm (to support languages needing garbage collection) is a more recent addition to the platform.
What to watch next
- Progress on WASI and related standards to reduce binary bloat and unify common host APIs.
- Adoption and tooling around the WebAssembly GC proposal, which affects languages that depend on garbage collection.
- Growth of non-browser Runtimes (Wasmtime, WasmEdge, Wasmer) and how they change server-side and embeddable use cases.
- Practical performance characteristics of Wasm outside JS engines: not confirmed in the source
Quick glossary
- WebAssembly (Wasm): A portable bytecode and compilation target designed for safe, efficient execution across environments including browsers and standalone engines.
- WAT: The textual S-expression representation of WebAssembly bytecode, useful for inspection and manual authoring of Wasm modules.
- WASI: WebAssembly System Interface — a set of standardized host APIs intended to give Wasm programs common access to system-like capabilities.
- Linear memory: A contiguous, sandboxed memory region provided to a Wasm module; access is controlled and separate from the host process memory.
- JIT: Just-In-Time compilation: a runtime technique that compiles code on the fly for performance, commonly used by JavaScript engines that also run Wasm.
Reader FAQ
Is WebAssembly dead?
No. It is actively used in production for targeted use cases like game ports, image tooling, sandboxes and language runtimes.
Is Wasm always faster than JavaScript?
Not inherently; performance depends on the runtime, engine optimizations and the cost of crossing host boundaries. The language itself is a compilation target, not a standalone speed guarantee.
Can you build entire web apps in Wasm today?
Major websites built entirely on Wasm-based frameworks are not common yet; many teams use Wasm for specific components or features instead.
Does WebAssembly replace native processes for sandboxing?
Wasm can provide process-like isolation inside a single process and enable fast startup, but whether it replaces OS processes depends on the workload and security model desired.
Table Of Contents On every WebAssembly discussion, there is inevitably one comment (often near the top) asking what happened. It seems to have been advertised as a world-changing advancement. Was…
Sources
- What happened to WebAssembly
- I beg you, please stop thinking WebAssembly is only for …
- The State of WebAssembly – 2024 and 2025
- Wasm's Identity Crisis: What the 3.0 Release Tells Us …
Related posts
- Extremophile microbes could help turn Martian soil into building material
- Surveillance Watch: Interactive map exposing links among surveillance firms
- Google Play star ratings are broken — 8 metadata signals I trust