What Is WebAssembly, in Plain English?
The elevator version
WebAssembly (often shortened to Wasm) is a compact binary code format that every modern browser can run directly, at near-native speed, inside the browser's own security sandbox. It lets code originally written in languages like C, C++, Rust, or C# run in a web page — the job that plugins like Silverlight, Flash, and Java applets used to do, but built into the web platform itself rather than bolted on.
It is not a Microsoft or Google product. WebAssembly is developed as an open standard under a W3C Working Group, with the major browser vendors participating, and it is documented for developers in depth on MDN Web Docs.
Why plugins died and WebAssembly didn't
The plugin era failed on three fronts, and WebAssembly was designed against each of them.
Security. A plugin was native software running with its own security model, largely outside the browser's control. A flaw in the plugin was a flaw on the whole machine. WebAssembly code, by contrast, runs inside the same sandbox as JavaScript — it can only do what the surrounding web page is allowed to do, as the MDN documentation explains. There is no separate attack surface to keep patched.
Installation. Plugins required users to download, install, and update a runtime — and an out-of-date runtime was both a support burden and a security hole. WebAssembly ships inside the browser. If the browser is current, Wasm is current.
Ownership. Each plugin was one vendor's product with one vendor's lifespan; when Microsoft ended Silverlight support, the platform simply stopped. WebAssembly is a multi-vendor standard: no single company can discontinue it, which makes it a far safer foundation for long-lived applications.
What it means for .NET people
For readers of this site, the practical significance is that WebAssembly is what lets C# run in the browser again — legitimately this time. Blazor WebAssembly compiles your .NET code so it executes on the browser's Wasm runtime, delivering roughly what Silverlight promised (rich client apps in C#) without any plugin. The details are in is Blazor the replacement for Silverlight.
What WebAssembly is not
A few common misconceptions worth clearing:
- It is not a JavaScript replacement. Wasm modules and JavaScript work together on the same page; JavaScript typically handles the page and DOM while Wasm handles compute-heavy or ported code.
- It is not automatically faster for everything. It shines at sustained computation — parsing, simulation, codecs, application runtimes — not at making an ordinary web page snappier.
- It is not a security risk in the way plugins were. Because it runs in the standard browser sandbox, enabling Wasm does not widen what a website can do to your machine.
Why this history matters
Understanding WebAssembly explains why there is no "bring Silverlight back" option and never will be: browsers did not lose the ability to run rich applications, they rebuilt it on a foundation they control. The route forward for a Silverlight codebase runs through that foundation — start with why Silverlight won't run in modern browsers if you arrived here mid-mystery.