WebAssembly · compilation · virtual machines
What is WebAssembly, exactly?
The most common misunderstanding about WebAssembly is that it is a language you write. It is not. The official definition is precise, and reading it literally answers most of the questions people have.
The definition, word for word
WebAssembly, abbreviated Wasm, is a binary instruction format for a stack-based virtual machine. It is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications.
Two things follow immediately. It is a target, which means something else compiles into it, the way C compiles to machine code. And it is stack-based, which is a design decision about how the virtual machine holds operands, not a detail you interact with directly.
Nobody is expected to write Wasm by hand for production, any more than anyone writes x86 by hand. You write Rust, C, Go or another language, and the compiler emits Wasm.
The four design goals, and what each one costs
The project states four goals, and they are worth reading as trade-offs rather than as a feature list.
Efficiency. The stack machine is designed to execute at native speed by taking advantage of common hardware capabilities available on a wide range of platforms. Note the qualifier: common capabilities, across a wide range. Speed here comes from targeting what every platform has, not from exploiting what any single one does best.
Safety. Wasm describes a memory-safe, sandboxed execution environment, and one that may be implemented inside existing JavaScript virtual machines. The module cannot reach outside what the host hands it.
Openness. It is designed to be pretty-printed in a textual format for debugging, testing, experimenting, optimizing, learning, teaching, and writing programs by hand. A binary format that ships a readable counterpart is making a deliberate choice against opacity.
Portability. The stated aim is to preserve the versionless, feature-tested, and backwards-compatible nature of the web. That single phrase explains why Wasm has no version numbers to negotiate: you test for a feature, you do not ask which release you are talking to.
The relationship with JavaScript
Wasm does not replace JavaScript, and the official wording about their interaction is careful in a way worth noticing. Modules will be able to call into and out of the JavaScript context and access browser functionality through the same Web APIs accessible from JavaScript.
That future tense, will be able to, sits in the official description. It is a reminder that the boundary between the two has been a moving target, and that anything you read about Wasm and the DOM should be checked against the version you are actually shipping rather than against a blog post.
The practical shape today: Wasm computes, JavaScript orchestrates. Heavy numeric work, codecs, compression, simulation, cryptography all fit the first role. Reaching the page, handling events and calling browser APIs fit the second.
It was never only for browsers
The name misleads people, and the site says so plainly: WebAssembly also supports non-web embeddings. The definition itself mentions client and server applications.
This is why Wasm turns up in places with no browser anywhere: plugin systems that need to run untrusted code safely, edge runtimes, embedded scripting inside larger applications. In all of them the appeal is the same pair of properties, a sandbox with a portable binary format, and the browser is simply the most visible host rather than the only one.
When it is the wrong tool
If your bottleneck is the network, Wasm does not help. A module still has to be downloaded, and a fast computation behind a slow transfer is still slow.
If your work is mostly DOM manipulation, crossing the boundary to do it costs more than it saves. That is what JavaScript is already good at.
If you would need to rewrite working code, weigh that honestly. Wasm shines when a compiled language is already the natural fit, or when you have an existing C or Rust codebase to bring along.
The short version
WebAssembly is a binary instruction format for a stack-based virtual machine, and a portable compilation target rather than a language you write. Its four goals are efficiency at native speed on common hardware, a memory-safe sandbox, a readable text format alongside the binary, and the versionless, feature-tested portability of the web.
It complements JavaScript instead of replacing it, and it supports non-web embeddings, which is why it appears in plugin systems and server runtimes as readily as in browsers. Read the definition literally and most of the confusion around it disappears.
If you are getting into how compiled languages reach a target at all, our note on what an algorithm is starts one level below this.
The definition, the four design goals and their wording, the statement about calling into and out of the JavaScript context, and the note on non-web embeddings are taken from the official WebAssembly site, checked at the time of writing. The specification evolves; verify against the current documentation before relying on a specific capability.