WebAssembly: Die Grundlagen von Wasm

In dieser Blogreihe über »WebAssembly im Software Engineering« stellt der Autor Nils Brand nicht nur die Technologie WebAssembly (Wasm) vor, sondern vor allem die Potenziale und Auswirkungen auf zukünftiges Software Engineering. Der folgende erste Beitrag behandelt zunächst die Grundlagen und verschafft einen Überblick über mögliche Potenziale hinsichtlich Software-Architektur, Systemmodernisierungen sowie Cloud- bis Edge-Computing und eignet sich auch als Foresight-Bericht.

WebAssembly oder auch kurz Wasm erregte erstmals 2017 Aufsehen, indem die Version 1 in den großen Webbrowsern Mozilla Firefox, Apple Safari, Google Chrome und Microsoft Edge ausgeliefert wurde. Seit Ende 2019 gilt WebAssembly als offiziell festgelegter und offener Standard seitens W3C [1].
Wie bereits das Standardisierungsgremium W3C und die Namenszusammensetzung »Web« + »Assembly« vermuten lassen, handelt es sich hier um eine Webtechnologie – aber eben nicht nur, dazu später mehr. Die Motivation und das Interesse der Industriegiganten hinter WebAssembly waren das Verlangen, mehr Leistung clientseitig, also im Browser, zur Verfügung zu haben. Grund dafür waren verschiedene Limitationen von Javascript, aber insbesondere die Ineffizienz bei rechenintensiven Aufgaben. So werden HTML, CSS und Javascript nun durch WebAssembly ergänzt als Webstandard und die meisten Internetnutzer interagieren mit WebAssembly-Anwendungen täglich.

Aus technologischer Perspektive ist WebAssembly ein Kompilierungsziel für eine Vielzahl von Programmiersprachen, die speziell ein hohes Momentum bei Nutzern der Sprachen C, C++, Rust und Go genießt (vgl. [2] & [3]). Dies ist auch nicht verwunderlich, da diese Sprachen nicht nur modern sind, sondern typischerweise in Performance-kritischen Anwendungen verwendet werden. Unternehmen, die Ihre Produkte zuvor nicht im Web anbieten konnten, aufgrund von Performance und Webunterstützung, verfügen jetzt über eine innovative Möglichkeit zum weiteren Vertrieb ihrer bisherigen Produkte.

Code, der nach WebAssembly kompiliert wurde, trägt dann die Datei-Endung .wasm und liegt als Bytecode vor. Das bedeutet, dass die WebAssembly Module eine Laufzeitumgebung (engl. Runtime) benötigen, um ausgeführt zu werden. Hier fungiert typischerweise ein Webbrowser als Laufzeitumgebung. An dieser Stelle ergibt sich auch das Interesse der Browserhersteller und die immense Bedeutung für WebAssembly, dass es ein W3C-Standard ist.

Doch auch, wenn dies bereits eine Erfolgsgeschichte ist, die sich auf die Anwendungsentwicklung auswirkt, so existiert eine weitere Strömung im WebAssembly Umfeld: WebAssembly System Interface (kurz WASI). WASI ermöglicht eine Schnittstelle zum System bzw. der Hardware, sodass ein Browser als Laufzeitumgebung nicht notwendig ist. Man spricht auch von Server-Side-WebAssembly, WebAssembly-Outside-the-Web oder Embedded-WebAssembly. Hierbei sollen alle Vorteile von WebAssembly-Modulen genutzt und mit dedizierten Laufzeitumgebungen ausgeführt werden, sodass ein Browser nicht mehr notwendig ist. Dies eröffnet im gesamten Cloud-Edge-Kontinuum den Einsatz von WebAssembly als leichtgewichtige Container-Lösung. So sorgte ein Online-Beitrag des Gründers der Docker-Technologie in Bezug auf WASI für großes Aufsehen:

If WASM+WASI existed in 2008, we wouldn’t have needed to created Docker. That’s how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let’s hope WASI is up to the task! https://t.co/wnXQg4kwa4

— Solomon Hykes (@solomonstre), March 27, 2019

Tiefergehende technische Details über WebAssembly und WASI sind auf der webassembly.org (offizielle Website) gelistet und werden im Laufe dieses, sowie künftiger Beiträge hier im IESE-Blog vorgestellt.

8 Vorteile von WebAssembly

Einige Vorteile von WebAssembly wurden bereits im vorherigen Abschnitt angedeutet. Weitere wichtige Vorteile ergeben sich jedoch erst aus der Spezifikation.
Daher folgt hier eine Zusammenfassung:

• Portabilität
  • WebAssembly Module sind höchst portabel, solange eine Laufzeitumgebung (z.B. Browser) für die jeweilige Hardware bzw. Chip-Architektur (x86, ARM, RISC-V, MIPS, …) ausgeführt werden kann. Diese Plattformunabhängigkeit bzw. Hardwareunabhängigkeit ist ein entscheidender Vorteil im Betrieb, da lediglich die Laufzeitumgebung einmal für die jeweilige Chip-Architektur kompiliert werden muss, nicht jedes Mal die WebAssembly Module. Dies erleichtert nicht nur das Deployment erheblich, sondern steigert die Geschwindigkeit der Verteilung. Somit wird auch oft von einer leichtgewichtigen Containerisierungstechnologie im Kontext von WebAssembly gesprochen.
• Geringer Speicherverbrauch
  • WebAssembly Module zeichnen sich durch einen geringen Overhead in der Modulgröße aus. Im Vergleich zu Docker-Containern sind WebAssembly Module oft um das 10-fache kleiner (vgl. [4]), was sich auch direkt auf die Start-Up-Time der einzelnen Module auswirkt. Wichtige Sekunden, die den Unterschied machen können im Embedded-Echtzeitbereich oder im Cloud-Bereich bei unerwarteten Lastspitzen.
• Nahezu native Performance
  • Eines der Grundpfeiler im Design von WebAssembly war Performance und der Anspruch, nahezu native Leistung abzurufen. Angesichts dessen hat die Spezifikation von WebAssembly Effizienz in der DNA.
• Modular
  • Aufgrund der Tatsache, dass WebAssembly Module zum einen aus verschiedenen Programmiersprachen stammen können und zum anderen sehr flexibel in einer Laufzeitumgebung koexistieren können, sind modulare Architekturen möglich. Das bedeutet, dass die Business-Logik in Sprache A entwickelt werden kann, während die Ausführung von rechenintensiven Operationen in der passenderen Sprache B entwickelt werden kann – beide arbeiten nahtlos im Produktivsystem zusammen (vgl. Component-Model [5])
• Security: Isolation & Sandboxing
  • WebAssembly setzt auf ein lineares Speichermodell sowie starke Isolation der einzelnen Module. Es wurde im Design, neben der Performance, der starke Security-Aspekt als ein weiterer Grundpfeiler festgelegt. Somit eignet sich WebAssembly auch auf eigener Hardware, potenziell unsicheren Code sicher auszuführen, da die Module nicht über ihre virtuelle Umgebung herausragen (vgl. [6] & [7])
• Vielfältige Unterstützung von Programmiersprachen
  • Wie bereits mehrfach erwähnt unterstützt WebAssembly viele Programmiersprachen und der Support weiterer Sprachen wächst, wie hier zu erkennen ist: (vgl. [2]& [3])
  • Erwähnenswert ist, dass interpretierte Sprachen wie PHP, Ruby oder Python mit WebAssembly funktionieren. Denn hier werden auch Interpreter nach WebAssembly kompiliert und so ist die Ausführung möglich.
• Browserunterstützung
  • Da WebAssembly ursprünglich als eine Technologie für den Browser konzipiert war, funktionieren WebAssembly-Module auch immer dort. Dies ist ein nicht zu unterschätzender Faktor in der Entwicklung von Systemen, da das Produkt automatisch bereit für den Webbrowser ist. Diese Eigenschaft ist überaus attraktiv für Simulation oder Testing, wie die Robotik eindrucksvoll vorweist [8].
• Kompatibilität mit Rust
  • Seit Jahren erfreut sich die Programmiersprache Rust einer ungebremsten Beliebtheit von Embedded bis hin zu klassischen Informationssystemen (vgl. [9]). So ist es nicht überraschend, dass einige WebAssembly-Tools oder Laufzeitumgebungen mit Rust entwickelt wurden. Selbst auf der offiziellen Rust Website wird auf die herausragende Kompatibilität mit WebAssembly hingewiesen.

Anwendungsgebiete

Aus den bisherigen Abschnitten zeichnete sich schon ab, in welcher Bandbreite, aber auch in welcher Tiefe WebAssembly eingesetzt werden kann. WebAssembly wird die Reise fortsetzen und in zukünftigen Systemen nicht mehr wegzudenken sein. Typische Anwendungsgebiete werden also sein:

• Modernisierung von Legacy-Systemen
• Robuste und interoperable Software-Architekturen
• Beherrschung des Cloud-Edge-Kontinuum
• Portierung ins Web von: Desktopanwendungen, Simulation, Robotik, Gaming, digitaler Zwilling
• Sichere Ausführung von 3rd-Party-Code in digitalen Ökosystemen
• Erleichterung von Safety-Zertifizierung (ASIL, DO178, …)

Unterschiede zwischen Wasm und JavaScript

WebAssembly und Javascript werden oft miteinander vermischt. Doch spätestens beim Lesen vorheriger Abschnitte sollten die Unterschiede deutlich werden.

JavaScript komplementierte HTML und CSS in den Anfangszeiten des WorldWideWeb als Werkzeug bzw. Skriptsprache zur grundsätzlichen Erzeugung von dynamischen Websites. Seitdem gehört JavaScript zu einer der am meisten genutzten Sprachen und feierte eine Art Renaissance, indem man JavaScript Ende der 2000er auch häufig serverseitig einsetzte. Dies sind allerdings zwei Parallelen zur bisherigen WebAssembly Geschichte, insofern nun zu den entscheidenden Unterschieden:

• JavaScript eignet sich für die allgemeine Webentwicklung und Interaktion (insb. DOM-Manipulation). Für einfache Aufgaben wie die Weiterleitung von URLs ist JavaScript einfacher und bequemer (vgl. [10]).
• WebAssembly wird dort eingesetzt, wo JavaScript an die Grenzen stößt: für leistungsintensive Aufgaben, wie die Kompression von Bildern clientseitig oder in der Embedded-Domäne.
• JavaScript selbst ist eine Sprache, WebAssembly ist ein Kompilierungsziel.
• JavaScript kann nicht das gesamte Cloud-Edge-Spektrum abbilden und konnte sich nie im Edge-Computing durchsetzen – im Gegensatz zur aktuellen Entwicklung von WebAssembly.
• Es besteht keine Konkurrenzsituation, im Gegenteil: WebAssembly soll nicht JavaScript ersetzen, denn WebAssembly lebt von der Interoperabilität mit JavaScript, da es nur so in den Browser optimal eingebunden werden kann.

Unterschiede zwischen Wasm/WASI und Java Virtual Machine (JVM)

Speziell beim Thema WebAssembly System Interface (WASI) taucht oft der Einwand auf, wo denn nun die Unterschiede zu Java und der Java Virtual Machine (JVM) liegen. Die Philosophie von Java »write once, run anywhere« liegt natürlich der Vision von WASI und dem Cloud-Edge-Kontinuum nahe. Aber auch als Webtechnologie war Java mit Java Applets im Rennen. Doch dies fand aus verschiedensten Gründen, von inkonsistenten User-Interfaces bis hin zur mangelnden Sichtbarkeit in Suchmaschinen, kaum Anklang. Hinsichtlich der JVM und WASI ergeben sich zusammenfassend folgende Unterschiede:

• WebAssembly/WASI unterstützt eine Vielzahl von Programmiersprachen, während in der JVM nur Java unterstützt wird. Dies schreckt insbesondere Entwickler ab, die mit anderen Entwicklungsparadigmen vertraut sind.
• Security (Sandboxing) und Performance von WebAssembly lagen im Fokus beim Standardisieren, weshalb WebAssembly in diesen Bereichen moderner aufgestellt ist und auch einen großen Anklang von Cloud bis Embedded erzielen konnte.
• Die Java-Community gehört zu den etabliertesten Ökosystemen – von Konferenzen, Online-Beiträgen bis hin in die Lehre ist die Java-Technologie stark verwurzelt. Dies ist bei einer noch jungen Technologie wie WebAssembly (noch) nicht der Fall.
• WebAssembly folgte dem (offenen) Standardisierungsweg des W3C, wohingegen Java zunächst stark durch industrielle Interessen des Unternehmens Sun Microsystems getrieben wurde

Tools und Ressourcen für die Verwendung von WebAssembly

Im Bereich der Entwicklungswerkzeuge ist täglicher Wandel als auch eine gewisse Etablierung zu spüren. Speziell der Industrieverband »Bytecode Alliance« ist zu erwähnen, da hier auch verschiedene Technologien (wie z.B. Laufzeitumgebungen für Embedded + Cloud) und Entwickler-Tools entstehen. Ebenso bieten die bekannten Virtualisierungs- und Container-Technologien Anbindungen für WebAssembly-Module an. Die WebAssembly Working Group innerhalb des W3C ist hier (https://www.w3.org/groups/wg/wasm/) zu finden. Außerdem hilft Ihnen das Fraunhofer IESE gerne bei der Auswahl passender Werkzeuge und Tools!

Praxisbeispiele und Erfolgsgeschichten

Seit spätestens 2021 häufen sich die Erfolgsgeschichten vom Einsatz von WebAssembly, weshalb sich sogar eine spezielle Website »madewithwebassembly.com« bildete, um dies festzuhalten.
Auf dieser Seite werden die »klassischen« Anwendungsfälle dargestellt, also von WebAssembly als Browsertechnologie. Prominente Use-Cases sind: eBay, Autodesk AutoCAD, Figma, Photoshop, OpenCV, TensorFlow und Unity.

Ansätze, die die Verwendung von WASI einbeziehen, sind nur vereinzelt im Internet auffindbar. Die innovativsten Erfolgsgeschichten sind folgende:

• Disney+, Amazon Video, BBC
  Um der Vielzahl an Endgeräten (Konsolen, Smartphone, leistungsschwache und moderne Smart-TVs) eine App-Unterstützung zu gewährleisten, wurde ein Hardware-Abstraction-Layer benötigt, welches mit WebAssembly + WASI umgesetzt wurde. Ferner konnte ein schnellerer Updatezyklus erreicht werden, um hierbei nicht losgelöst von den Geräteherstellern zu agieren.
• Shopify
  Im digitalen Ökosystem von Shopify spielen Plug-ins von Drittanbietern eine große Rolle in der Nutzererfahrung. Um aber den Anbietern von Plug-ins eine ebenso gute Nutzererfahrung (oder Developer Experience) zu ermöglichen, identifizierte Shopify als Mehrwert, dass Plug-ins auf der Shopify-eigenen Infrastruktur betrieben werden können. Dies spart den Plug-in-Entwicklern Kosten und Aufwand einer eigenen Infrastruktur. Dies lässt ein Securityrisiko vermuten. Jedoch durch die starke Sandboxing-Eigenschaft von WebAssembly und einer serverseitigen Wasm-Laufzeitumgebung konnte das Ausführen von »untrusted 3rd Party Code« sicher gewährleistet werden.
• Alibaba
  Das Higress cloud-native API-Gateway von Alibaba war bereits befähigt, WebAssembly Module auf die »traditionelle Art« mit der V8-Engine auszuführen. Allerdings waren Effizienzsteigerung (weniger Ressourcen, bei gleichbleibender Leistung) das Ziel und so setzte Alibaba auf eine dedizierte WebAssembly-Laufzeitumgebung. Dabei wurde im Durchschnitt eine Performancesteigerung um 50% erreicht und in Einzelfällen mit komplexen Operationen sogar bis zu 100%.
• Cloudflare
  Cloudflare bietet mit Workers äußerst beliebte Serverless-Funktionalitäten an. Hierbei möchte Cloudflare besondere Mehrwerte bieten, indem Kunden auch die Möglichkeit zur Verfügung gestellt wird, WebAssembly Module auszuführen, z.B. für clientseitige Bildverarbeitung. Ergänzend sieht Cloudflare einen Mehrwert durch die vielfältige Sprachunterstützung von WebAssembly als Kompilierungsziel und erhofft sich, neue Märkte zu erschließen.

In der Forschungswelt werden auch neuartige Architekturen oder lang ersehnte Konzepte versucht, mit WebAssembly zu realisieren. Beispiele hierfür sind das EU-Projekt HAL4SDV aus der Automobilbranche oder das EU-Projekt Elastic aus der 6G-Telekommunikationsbranche. Abschließend kann WebAssembly inkl. WASI bei Software Defined X Forschungsvorhaben in Zukunft eine zentrale Rolle spielen, aufgrund der Eigenschaft der Hardwareabstraktion.

> Die Potenziale für WebAssembly in Software Defined Defense haben wir in einem Flyer (PDF) verdeutlicht.

Fazit

WebAssembly ist mehr als eine inkrementelle Verbesserung der Webtechnologie. Es ist ebenfalls mehr als nur eine Containerisierungstechnologie. Vielmehr wird WebAssembly Softwarearchitekturen von Embedded- bis hin zu Informationssystemen weitreichend beeinflussen. Bei genauerer Betrachtung multiplizieren sich die Features von WebAssembly immens. Es erweitert das Geschäftsfeld von Unternehmenssoftware in Informations- und eingebettete Systeme. Außerdem ermöglicht es, die Portabilität von WebAssembly für Simulation und effizientes Deployment zu nutzen.

Deshalb ist jetzt ein wichtiger Zeitpunkt, sich genauer mit der Technologie zu beschäftigen und disruptive Auswirkungen auf das eigene Geschäftsmodell zu evaluieren.

Referenzen

[1] W3C WebAssembly Working Group, Zugegriffen: 06.03.2025.
[2] github.com/appcypher/awesome-wasm-langs, Zugegriffen: 06.03.2025.
[3] developer.fermyon.com/wasm-languages/webassembly-language-support Zugegriffen: 06.03.2025.
[4] wasmedge.org/docs/start/build-and-run/docker_wasm, Zugegriffen: 06.03.2025.
[5] component-model.bytecodealliance.org, Zugegriffen: 06.03.2025.
[6] shopify.engineering/shopify-webassembly, Zugegriffen: 06.03.2025.
[7] webassembly.org, Zugegriffen: 06.03.2025.
[8] ros2wasm.dev, Zugegriffen: 06.03.2025.
[9] survey.stackoverflow.co, Zugegriffen: 06.03.2025.
[10] WebAssembly on Cloudflare Workers, Zugegriffen: 06.03.2025.