Silverlight China

A plain-English reference for the Silverlight era — and what to run instead

What Replaced NPAPI Plugins After Browsers Removed Them?

Nothing replaced NPAPI plugins directly — browsers deliberately chose not to build a successor plugin system for the open web. Instead, the jobs plugins used to do were absorbed into the web platform itself: built-in HTML5 audio and video, much faster JavaScript, and WebAssembly, the W3C-standardized runtime that lets compiled code run in every major browser without any install. MDN's plugin glossary entry is blunt about the outcome: plugins are deprecated, and modern sites should use web APIs in their place.

Why there was no 'NPAPI 2.0'

When Chrome laid out its removal plan in the Chromium NPAPI deprecation guide, the reasoning wasn't that NPAPI was an outdated version of a good idea. The problem was the idea itself: letting websites trigger native code that lived outside the browser's security model, needed separate installation and updating, and existed per-operating-system rather than everywhere the web ran. A cleaner plugin API would have inherited most of those problems. (Chrome's own PPAPI interface existed for a while, but it was never an open replacement — see NPAPI vs. PPAPI: what's the difference.) So browser vendors took the other path: make the web platform capable enough that plugins became unnecessary. The background on how plugins worked is in what was NPAPI, and why every browser dropped it.

What took over each job

Plugins did several distinct jobs, and each got a different standards-based successor:

  • Video and audio. The single biggest plugin use case — streaming media through Flash or Silverlight — moved to the HTML5 `<video>` and `<audio>` elements plus browser-native streaming and content-protection APIs. This is why major streaming sites stopped prompting for plugins years ago.
  • Rich interactive applications. App-like experiences that once justified Silverlight now run on modern JavaScript frameworks, and increasingly on WebAssembly, which runs compiled languages at near-native speed inside the browser sandbox. MDN's WebAssembly documentation describes it as designed to work alongside JavaScript, not replace it — the two share the page. For a non-technical explanation, see what is WebAssembly, in plain English.
  • Graphics and games. 3D and canvas rendering moved to standards like WebGL, often driven by WebAssembly-compiled engines.
  • Document viewing. Browsers built in their own PDF viewers rather than relying on a reader plugin.

Aren't extensions the replacement?

No — extensions existed alongside plugins and do a different job. A plugin rendered content inside a page using native code; an extension customizes the browser using web code. Ad blockers and password managers are extensions; Silverlight was a plugin. Nothing in the extension model can host plugin content, which is why no add-on brings Silverlight back.

Why this matters for a legacy Silverlight app

The practical consequence: there is no future browser update that restores a plugin slot for an old app to occupy. The replacement for a Silverlight application isn't a new plugin — it's the application moving onto the platform that won. For .NET teams that usually means Blazor, which runs C# on WebAssembly, a path we compare in is Blazor the replacement for Silverlight.

The web didn't get a new plugin system; it outgrew the need for one. That's inconvenient for legacy apps, but it's also why a page built on today's standards runs on every modern browser, on every operating system, with nothing to install.

Sources

← Silverlight China