© piick/Shutterstock.com
Der aktuelle Stand der Implementierung und wohin die Reise geht

Der Status quo von WebAssembly


WebAssembly ist ein relativ neues, binäres Format für ausführbaren Programmcode im Web. Dieser Artikel beschäftigt sich mit der Motivation hinter WebAssembly, dem aktuellen Stand der Implementierung sowie den zukünftigen Erweiterungen.

Mehr als nur statische HTML-Seiten im Browser anzuzeigen, hat eine lange Tradition. Der Wunsch nach dynamischen Inhalten ist so alt wie das Internet selbst. Als mit dem Netscape Navigator Version 2.02 im Jahr 1995 die Skriptsprache LiveScript der breiten Öffentlichkeit zugänglich gemacht wurde, war auch der Wunsch nach dynamischeren Inhalten plötzlich ein Stückchen näher an der Realität. LiveScript wurde später in JavaScript umbenannt und entwickelte sich zu einem Fundament des Internets wie wir es heute kennen.

Die Entwicklung von immer dynamischeren Inhalten nahm dann ihren Lauf. Im Jahr 2005 prägte James Garret in seinem Aufsatz den Begriff AJAX und zeigte, wie es in Verbindung mit XML und Backend-Logik möglich ist, noch interaktivere Anwendungen zu bauen. JavaScript wurde immer beliebter.

Richten wir nun unseren Blick in die etwas jüngere Vergangenheit, nämlich auf das Jahr 2010: JavaScript als Laufzeitumgebung ist überall. Webbrowser sind überall. Ein weltweit etablierter Standard. Daraus entsteht die Idee, genau diese Laufzeitumgebung auch für mehr als nur Webseiten zu nutzen. Aus einer Zusammenarbeit der Mozilla Foundation und dem Spielestudio Epic entsteht das Projekt Emscripten [1]. Emscripten ist ein C- bzw. C++-Compiler, der als Ergebnis JavaScript erzeugt. Mit diesem Compiler war es möglich, die Unreal­-Spiele-Engine komplett nach JavaScript zu übersetzen und im Browser laufen zu lassen. Das beeindruckende Ergebnis war die Unreal-Cathedral-Demo.

Die Epic-Tech-Demos zeigten es ganz deutlich: die JavaScript Engines in den Browsern sind dank Just-in-Time-Kompilierung leistungsfähiger als viele dachten, und man kann damit wesentlich mehr machen, als nur div-Tags ein- und auszublenden. Durch den Einsatz von Cross-Compilern wie Emscripten ist es möglich, bestehenden Quellcode in Form von C oder C++ ohne größere Umbauarbeiten in neuen Umgebungen laufen zu lassen. Dies eröffnet für bestehende Lösungen und Produkte komplett neue Kundensegmente und Verteilungsmöglichkeiten für lauffähige Software.

Der Trend ist eindeutig. Der Anteil an JavaScript in Webseiten und Webanwendungen steigt stetig an, im Extremfall auf mehrere Millionen Zeilen Quellcode. Die Größe der Anwendungen nimmt teilweise schneller zu als die zur Verfügung stehende Rechenleistung auf mobilen Geräten oder die nutzbare Netzwerkbandbreite für den Download auf das Zielgerät. Daraus ergeben sich zwei Lücken, eine offensichtliche und eine vielleicht weniger offensichtliche.

Die offensichtliche Lücke sind die erwähnte Größe der Anwendungen, die Downloadkapazität und die Netzwerkbandbreite. Zugegebenermaßen kann der Größe und hohen Ladezeit durch eine geschickte Modulstruktur im JavaScript ein Stück entgegengewirkt werden. Trotzdem muss der Programmcode zum Nutzer übertragen werden, und die zur Verfügung stehende Kapazität der Funknetzwerke ist auf den Vertrag des Kunden mit dem Mobilfunkanbieter bzw. auch durch den noch schleppenden Breitbandausbau in Deutschland limitiert.

Die weniger offensichtliche Lücke liegt in der Natur der JavaScript-Laufzeitumgebungen und der Sprache. JavaScript kann erst dann sinnvoll analysiert und validiert werden, wenn es vollständig auf das Zielgerät heruntergeladen wurde. Dieser Schritt ist blockierend und zeitaufwändig. Die schwache Typisierung von JavaScript unterstützt die JavaScript-Laufzeitumgebung bei der Ausführung auch nicht gerade. Erst durch geschickten Einsatz von Tiered-Just-in-Time-Compilern [2] kann JavaScript effizient ausgeführt werden. Durch diese Struktur ergeben sich aber oftmals unerwünschte Warmlaufphasen der Anwendungen. Phasen, in denen das Programm noch nicht mit optimaler Geschwindigkeit arbeitet oder auch mal einfriert.

WebAssembly 1.0

Als Reaktion auf die beschriebenen Probleme wurde 2015 WebAssembly ins Leben gerufen, das ein neuer offener Standard werden sollte. Anders als bei den vorherigen, auf Browser-Plug-ins (ActiveX) oder Herstellererweiterungen (NaCl) basierenden Ansätzen für nativen Code, waren von Anfang an Vertreter aller Browseranbieter bei der Spezifikation beteiligt. Die Idee war, ein kompaktes, sicheres und transportables Format für Programmcode zu schaffen. Dieses Format sollte sich leicht in die bestehende Browserlandschaft integrieren lassen und auf den bereits bestehenden Standards aufbauen. Das kompakte Format sollte zudem mit maximaler Effizient validier- und ausführbar sein. Zu guter Letzt sollte es auch leicht in bestehende Compiler­infrastrukturen integrierbar sein. Im März 2017 war es dann so weit: WebAssembly 1.0 [3] wurde in Form eines MVP (Minimum Viable Product) der Öffentlichkeit zur Verfügung gestellt.

Doch wie funktioniert nun WebAssembly genau? WebAssembly besteht aus zwei Teilen. Der erste Teil ist die sogenannte Hostumgebung, das WebAssembly Runtime Environment. Das ist ein isolierter (sandboxed) Bereich mit klar definierten Schnittstellen. Innerhalb dieser Umgebung wird der WebAssembly-Code ausgeführt. Die Syntax und Semantik dieses Codes ist der zweite Teil der Spezifikation.

Schauen wir uns ein WebAssembly-Beispiel genauer an, lasst uns gemeinsam das obligatorische „Hello World“ schreiben! WebAssembly-Code ist eine Mischung aus Stack- und Registermaschine. Die Argumente für einen Operanden und das Ergebnis der Ausführung werden auf dem Stack abgelegt. Zusätzlich stehen noch vordefinierte lokale Variablen für die Datenspeicherung zur Verfügung. Der Code kann hierbei zwei verschiedene Darstellungsformen annehmen – es gibt eine Darstellung in Text- und eine in Binärform. Die Textform ist für uns Menschen gedacht und soll das Debugging des Codes erleichtern. Die Binärform ist der eigentlich kompakte und transportable Code, der der WebAssembly-Hostumgebung zur Laufzeit übergeben wird.

WebAssembly-Code ist stark typisiert. In Version 1.0 wurde bewusst ein sehr einfaches, aber erweiterbares Typsystem gewählt. Tatsächlich gibt es nur vier numerische Typen, jeweils 32- und 64-Bit-Ausprägungen von Gan...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang