WebAssembly ermöglicht es Entwicklern, Web-Anwendungen mit nahezu nativer Leistung in einer Programmiersprache ihrer Wahl zu erstellen. Damit macht es dem JavaScript-Code als bislang einzige native Lösung erstmals Konkurrenz. [...]
Seit fast zwei Jahrzehnten gibt es nur eine einzige Programmiersprache, die nativ im Webbrowser verwendet werden kann: der JavaScript–Code. Der langsame Tod von Drittanbieter-Binär-PlugIns hat Programmiersprachen wie Java oder Flash ActionScript als erstklassige Vertreter der Web-Entwicklung zunehmend ausgeschlossen. Andere Websprachen wie der CoffeeScript werden lediglich zu JavaScript kompiliert.
Mittlerweile gibt es jedoch eine ganz neue Möglichkeit: WebAssembly, oder kurz WASM, ist ein kleines, schnelles Binärformat, das eine nahezu native Leistung für Webanwendungen verspricht. Zudem ist WASM so konzipiert, dass es als Kompilierungsziel für jede Sprache fungieren kann – JavaScript ist dabei nur eine von vielen Möglichkeiten. Da jeder größere Webbrowser WebAssembly inzwischen unterstützt, ist es nun wohl an der Zeit, ernsthaft darüber nachzudenken, bei der Programmierung auf clientseitige Webapps umzusteigen, die als WebAssembly kompiliert werden können.
WebAssembly-Apps sollen JavaScript–Apps keinesfalls ersetzen – oder zumindest noch nicht. Vielmehr sollte WASM als eine Ergänzung zu JavaScript verstanden werden: Während JavaScript flexibel, dynamisch typisiert und über menschenlesbaren Quellcode bereitgestellt wird, ist WebAssembly schnell, stark typisiert und wird über ein kompaktes Binärformat bereitgestellt. Besonders Entwickler von leistungsintensiven Anwendungen wie Games, Musikstreaming, Videobearbeitung oder CAD-Anwendungen sollten WebAssembly in Zukunft näher in Betracht ziehen.
Wie funktioniert WebAssembly?
WebAssembly, das eigens vom World Wide Web Consortium (kurz W3C) entwickelt wurde, ist nach Verständnis seiner Schöpfer ein sogenanntes „Kompilierungsziel“. Das heißt, dass es vom Entwickler nicht direkt geschrieben wird; stattdessen wird der Code in einer anderen, vom Entwickler gewählten Sprache geschrieben und anschließend in WebAssembly-Bytecode kompiliert. Dieser wird anschließend auf dem Client ausgeführt, typischerweise in einem Webbrowser, wo er in nativen Maschinencode übersetzt und mit hoher Geschwindigkeit ausgeführt wird.
WebAssembly-Code ist darauf ausgelegt, schneller geladen, analysiert und ausgeführt werden als JavaScript. Wenn WASM von einem Webbrowser verwendet wird, muss das notwendige Modul zwar zuerst heruntergeladen und eingerichtet werden, ansonsten funktioniert es jedoch auf die gleiche Weise. WebAssembly wird allerdings wesentlich schneller ausgeführt als JavaScript und bietet zusätzlich ein Sandbox-Ausführungsmodell, das auf den gleichen Security-Modellen basiert, die für JavaScript aktuell vorhanden sind.
Derzeit mag das Ausführen in Webbrowsern der häufigste Anwendungsfall von WebAssembly sein, doch eigentlich will es – auch in Zukunft – weitaus mehr sein als nur eine webbasierte Lösung. Wenn sich die Spezifikationen zur Anwendung von WASM erst einmal gefestigt haben, kann der Code auch für mobile Apps, Desktop-Apps, Server und andere Ausführungsumgebungen nützlich sein.
Anwendungsfälle für WebAssembly
Der einfachste Anwendungsfall für WebAssembly ist wohl das Ziel, eine In-Browser-Software zu schreiben. Die zu WASM kompilierten Komponenten können dabei in einer beliebigen Anzahl von Sprachen geschrieben werden. Die endgültige WebAssembly-Nutzlast wird dann über JavaScript an den Client übermittelt.
WebAssembly wurde vor allem in Hinblick auf leistungsintensivere, browserbasierte Anwendungsfälle entwickelt: Spiele, Musikstreaming, Videobearbeitung, CAD, Verschlüsselung und Bilderkennung, um nur ein paar zu nennen.
Im Allgemeinen ist es sinnvoll, sich auf die folgenden drei Bereiche zu konzentrieren, wenn Sie Ihren speziellen Anwendungsfall von WebAssembly bestimmen wollen:
High-Performance-Code, der bereits in einer der möglichen Zielsprachen vorhanden ist: Wenn Sie zum Beispiel eine mathematische Highspeed-Funktion in C geschrieben haben und diese nun in eine Webanwendung integrieren möchten, können Sie sie einfach als WebAssembly-Modul bereitstellen. Die weniger leistungskritischen, benutzerorientierten Teile der App können dabei in JavaScript verbleiben.
High-Performance-Code, der neu geschrieben werden muss, JavaScript dafür aber nicht ideal ist: Noch vor kurzem hätte man asm.js dazu verwenden können, einen solchen Code zu schreiben. Das können Sie heute zwar auch noch tun, aktuell wird WebAssembly allerdings langfristig als die bessere Lösung gehandelt.
Das Portieren einet Desktop-App in eine Web-Umgebung: Viele der Tech-Demos für asm.js und WebAssembly fallen in diese Kategorie. WebAssembly kann ein Substrat für Anwendungen bereitstellen, die ehrgeiziger sind als eine über HTML präsentierte GUI. Eine leichte Aufgabe ist das allerdings nicht, schließlich müssen alle Wege, über die eine Desktop-Anwendung mit ihrem Benutzer verbunden ist, WebAssembly-, HTML- oder JavaScript-Äquivalenten zugeordnet werden.
Wenn Sie eine vorhandene JavaScript–App haben, die keine Performance-Hüllkurven bereitstellt, sollten Sie, nach aktuellem Stand der WebAssembly-Entwicklung, lieber auf eine Umstellung verzichten. Möchten sie allerdings, dass die App schneller läuft, ist WebAssembly sehr wohl dazu in der Lage, ihnen dabei zu helfen.
WebAssembly-Sprachunterstützung
WebAssembly ist nicht darauf ausgelegt, direkt geschrieben zu werden. Wie der Name schon andeutet, ist es vielmehr eine Assemblersprache; dafür gedacht, von der Maschine gelesen zu werden, und keine menschenfreundliche Highlevel-Programmiersprache. WebAssembly ist näher am Zwischecode, wie ihn das LLVM Compiler Infrastructure Projekt hervorgebracht hat, als C oder Java.
Daher umfassen die meisten Anwendungsszenarien für das Arbeiten mit WebAssembly das Schreiben von Code in einer High-Level-Programmiersprache und das anschließende Umwandeln in WASM. Dies kann auf drei grundlegende Arten geschehen:
Direkte Zusammenstellung: Die Quelle wird über die eigene Compiler-Toolchain der jeweiligen Sprache in WebAssembly übersetzt. Rust, C / C ++, Kotlin / Native und D haben jetzt alle nativen Möglichkeiten, WASM über die Compiler zu senden, die diese Sprachen unterstützen.
Tools von Drittanbietern: Die gewählte Programmiersprache hat in ihrer Toolchain keine native WASM-Unterstützung, dafür kann jedoch ein Drittanbieter-Dienstprogramm zum Konvertieren in WASM verwendet werden. Java, Lua und die .Net-Sprachfamilie haben alle die notwendige Unterstützung dafür.
WebAssembly-basierter Interpreter: Hier wird die jeweilige Sprache nicht in WebAssembly übersetzt, sondern ein für WASM geschriebener Interpreter führt den in der jeweiligen Sprache geschriebenen Code aus. Dies ist der umständlichste Ansatz, da der Interpreter mehrere Megabytes an Code umfassen kann, doch er ermöglicht, dass ein existierender Code, der in der jeweiligen Sprache verfasst wurde, unverändert laufen kann. Python und Ruby haben beide Interpreter, die in WASM übersetzt wurden.
WebAssembly-Funktionen
WebAssembly befindet sich noch in einem sehr frühen Stadium. Die WebAssembly Toolchain und seine Implementierung bleiben daher näher am Proof-of-Concept als die Produktionstechnologie. Dennoch haben die Entwickler von WASM das Ziel, es durch eine Reihe von unterschiedlichen Initiativen noch nützlicher zu machen.
Garbage Collection Primitives
WebAssembly unterstützt Sprachen nicht direkt, die Garbage-Collected-Speichermodelle verwenden. Sprachen wie Lua oder Python können nur durch das Einschränken von Feature-Sets oder durch das Einbetten der gesamten Laufzeit als WebAssembly-Programm unterstützt werden. Inzwischen wird jedoch längst daran gearbeitet, Garbage-Collected-Speichermodelle zu unterstützen, ganz unabhängig von ihrer Sprache oder Implementierung.
Threading
Native Unterstützung für Threading ist vor allem in Sprachen wie Rust oder C ++ üblich. Doch die Abwesenheit einer Threading-Unterstützung in WebAssembly bedeutet, dass ganze Klassen von WebAssembly-bezogener Software nicht in diesen Sprachen geschrieben werden können. Der Ansatz, Threading in WebAssembly zu integrieren, nutzt unteranderem das C++-Threadingmodell als Inspiration.
Massenspeicheroperationen und SIMD
Die Parallelität von Massenspeicheroperationen und SIMD (Single Instruction, Multiple Data) ist ein Muss für Anwendungen, die sich durch Datenansammlungen bewegen und eine native CPU-Beschleunigung benötigen, um sich daran nicht zu verschlucken, wie es bei Machine Learning und wissenschaftlichen Anwendungen der Fall sein kann. WebAssembly diese Funktionen über neue Operatoren hinzuzufügen, ist bereits in Planung.
*Serdar Yegulalp ist Redakteur bei InfoWorld.
Be the first to comment