Mit WebAssembly lassen sich performante Web-Anwendungen in vielen verschiedenen Programmiersprachen erstellen. Der erzeugte Bytecode ist plattformunabhängig und damit ideal auch für die Umsetzung digitaler Produkte.
Die WebAssembly Core Specification ist ein W3C-Standard, der eine virtuelle Maschine mit dazugehörigen Bytecode beschreibt. Neben dieser Spezifikation beschreibt die WebAssembly Working Group derzeit noch die WebAssembly Web API zum Starten und Ausführen von WebAssembly im Browser, sowie das WebAssembly JavaScript Interface für den Zugriff und Datenaustausch zwischen WebAssembly und JavaScript. Anhand dieser Spezifikationen wird bereits klar, dass der Fokus von wasm, die Kurzform für WebAssembly, der Browser und damit das Web ist. Unterstützung erfährt WebAssembly inzwischen auch von den wichtigsten Browsern-Herstellern Apple, Google, Microsoft und Mozilla. Deren Browser unterstützten wasm in der Version 1.1. Diese Version wurde vom W3C Anfang Dezember 2019 als offizieller Webstandard verabschiedet. Interessierte können die Entwicklung des Standards auf GitHub verfolgen.
Mit Ankündigung von wasm in 2015 wurden performancekritische Anwendungen als Ziel angegeben. So wurde ein effizienter Bytecode mit geringem Befehlssatz gewählt, um die Programmgrößen klein zu halten. Ebenso ermöglicht der Bytecode eine deutlich schnellere Ausführung als es mit JavaScript der Fall ist. Dennoch ist die Sicherheit durch vergleichbare Sandboxing-Techniken, wie sie auch bei JavaScript zum Einsatz kommt, sichergestellt. Der standardisierte Bytecode ermöglicht eine Plattformunabhängigkeit.
Da es sich bei wasm um einen Bytecode handelt, muss dieser durch einen Compiler erzeugt werden. So kann der LLVM-zu-Web-Compiler emscripten verwendet werden, um C bzw. C++ in WebAssembly zu kompilieren. Des Weiteren gibt es inzwischen viele Programmiersprachen und Plattformen, die Mechanismen bereitstellen, um ein Kompilat für wasm zu erzeugen. So ermöglicht Microsoft mit Blazor WebAssembly in C# geschriebene .NET-Programme im Browser auszuführen. Auch Rust ist eine beliebte Alternative, um Programme zu schreiben. Selbst eine Kompilierung von JavaScript nach wasm ist möglich. Mit WebAssembly stehen also eine Vielzahl an Sprachen zur Verfügung. Ein gemischter Einsatz in einem Projekt ist derzeit allerdings nicht (sinnvoll) möglich. Selbst der Zugriff auf JavaScript bzw. von JavaScript auf eine Methode innerhalb wasm funktioniert je nach Sprache/Plattform noch nicht immer zufriedenstellend.
Kritiker sehen mit WebAssembly hingegen die Browser-Sicherheit gefährdet. Auch haben manche Sorgen vor einer Rückkehr von Problemen wie bei Flash bzw. Java-Applets. Durchforstet man das Netz zu Sicherheit und WebAssembly, findet man tendenziell mehr positive als negative Beiträge. Dennoch wird wasm noch zögerlich eingesetzt. So kommt eine Studie zum Ergebnis, dass nur 0,0002 % der Top-Webseiten WebAssembly einsetzen. Auf der anderen Seite wurde der Standard auch erst Ende 2019 offiziell verabschiedet und Technologien wie Blazor sind ebenso noch taufrisch. Mit WASI ist ein weiterer Standard in Arbeit, der WebAssembly auch außerhalb des Browsers ermöglichen soll. Mit Wasmtime und Wasmer gibt es auch bereits zwei Möglichkeiten WebAssembly überall laufen zu lassen. Besonders hier könnte wasm eine große Zukunft beschieden sein. Selbst Solomon Hykes, ein Mitgründer von Docker, sieht das so, letztes Jahr twitterte er: „If WASM+WASI existed in 2008, we wouldn’t have needed to created Docker.“