WebAssembly · Kompilierung · virtuelle Maschinen
Was ist WebAssembly genau?
Das häufigste Missverständnis über WebAssembly ist die Annahme, es sei eine Sprache, die man schreibt. Das ist es nicht. Die offizielle Definition ist präzise, und wer sie wörtlich liest, bekommt die meisten Fragen bereits beantwortet.
Die Definition, Wort für Wort
WebAssembly, abgekürzt Wasm, ist ein binäres Befehlsformat für eine stapelbasierte virtuelle Maschine. Es ist entworfen als ein portables Kompilierziel für Programmiersprachen, das die Bereitstellung im Web für Client- und Serveranwendungen ermöglicht.
Daraus folgen sofort zwei Dinge. Es ist ein Ziel, das heißt, etwas anderes kompiliert dorthin, so wie C zu Maschinencode kompiliert. Und es ist stapelbasiert, was eine Designentscheidung darüber ist, wie die virtuelle Maschine Operanden hält, kein Detail, mit dem du direkt umgehst.
Von niemandem wird erwartet, Wasm für den Produktivbetrieb von Hand zu schreiben, so wenig wie jemand x86 von Hand schreibt. Du schreibst Rust, C, Go oder eine andere Sprache, und der Compiler gibt Wasm aus.
Die vier Designziele und was jedes davon kostet
Das Projekt nennt vier Ziele, und es lohnt sich, sie als Abwägungen zu lesen und nicht als Funktionsliste.
Effizienz. Die Stapelmaschine ist darauf ausgelegt, mit nativer Geschwindigkeit ausgeführt zu werden, indem sie sich verbreitete Hardwarefähigkeiten zunutze macht, die auf einer breiten Palette von Plattformen verfügbar sind. Man beachte die Einschränkung: verbreitete Fähigkeiten, über eine breite Palette hinweg. Geschwindigkeit entsteht hier daraus, das anzusteuern, was jede Plattform hat, und nicht daraus, auszureizen, was eine einzelne am besten kann.
Sicherheit. Wasm beschreibt eine speichersichere, in einer Sandbox laufende Ausführungsumgebung, die sich zudem innerhalb bestehender JavaScript-VMs implementieren lässt. Das Modul kann nicht über das hinausgreifen, was der Host ihm reicht.
Offenheit. Es ist so entworfen, dass es in einem Textformat lesbar ausgegeben werden kann, zum Debuggen, Testen, Experimentieren, Optimieren, Lernen, Lehren und Schreiben von Programmen von Hand. Ein Binärformat, das ein lesbares Gegenstück mitliefert, trifft eine bewusste Entscheidung gegen Undurchsichtigkeit.
Portabilität. Das erklärte Ziel ist es, die versionslose, per Feature-Test geprüfte und rückwärtskompatible Natur des Webs zu bewahren. Diese eine Formulierung erklärt, warum Wasm keine Versionsnummern hat, die ausgehandelt werden müssten: Man testet auf ein Feature und fragt nicht, mit welchem Release man spricht.
Das Verhältnis zu JavaScript
Wasm ersetzt JavaScript nicht, und die offizielle Formulierung zu ihrem Zusammenspiel ist auf eine Weise vorsichtig, die auffallen sollte. Module werden in den JavaScript-Kontext hinein und aus ihm heraus aufrufen können und über dieselben Web APIs auf Browserfunktionalität zugreifen können, die auch von JavaScript aus erreichbar sind.
Diese Zukunftsform, werden aufrufen können, steht so in der offiziellen Beschreibung. Sie erinnert daran, dass die Grenze zwischen beiden ein bewegliches Ziel war, und dass alles, was man über Wasm und das DOM liest, gegen die Version geprüft werden sollte, die man tatsächlich ausliefert, und nicht gegen einen Blogbeitrag.
Die praktische Form heute: Wasm rechnet, JavaScript orchestriert. Schwere numerische Arbeit, Codecs, Kompression, Simulation und Kryptografie passen alle in die erste Rolle. An die Seite heranzukommen, Ereignisse zu behandeln und Browser-APIs aufzurufen, passt in die zweite.
Es war nie nur für Browser gedacht
Der Name führt in die Irre, und die Website sagt es unumwunden: WebAssembly unterstützt auch Einbettungen außerhalb des Webs. Die Definition selbst erwähnt Client- und Serveranwendungen.
Deshalb taucht Wasm an Orten auf, an denen weit und breit kein Browser ist: Plugin-Systeme, die nicht vertrauenswürdigen Code sicher ausführen müssen, Edge-Laufzeitumgebungen, eingebettetes Skripting innerhalb größerer Anwendungen. In allen ist der Reiz dasselbe Paar von Eigenschaften, eine Sandbox mit einem portablen Binärformat, und der Browser ist schlicht der sichtbarste Host, nicht der einzige.
Wann es das falsche Werkzeug ist
Wenn dein Engpass das Netzwerk ist, hilft Wasm nicht. Ein Modul muss weiterhin heruntergeladen werden, und eine schnelle Berechnung hinter einer langsamen Übertragung ist immer noch langsam.
Wenn deine Arbeit überwiegend DOM-Manipulation ist, kostet das Überqueren der Grenze mehr, als es einspart. Genau darin ist JavaScript bereits gut.
Wenn du funktionierenden Code neu schreiben müsstest, wäge das ehrlich ab. Wasm glänzt, wenn eine kompilierte Sprache ohnehin die natürliche Wahl ist, oder wenn du eine bestehende C- oder Rust-Codebasis mitbringst.
Die kurze Fassung
WebAssembly ist ein binäres Befehlsformat für eine stapelbasierte virtuelle Maschine und ein portables Kompilierziel, keine Sprache, die man schreibt. Seine vier Ziele sind Effizienz mit nativer Geschwindigkeit auf verbreiteter Hardware, eine speichersichere Sandbox, ein lesbares Textformat neben dem Binärformat und die versionslose, per Feature-Test geprüfte Portabilität des Webs.
Es ergänzt JavaScript, statt es zu ersetzen, und es unterstützt Einbettungen außerhalb des Webs, weshalb es in Plugin-Systemen und Server-Laufzeitumgebungen genauso selbstverständlich auftaucht wie in Browsern. Lies die Definition wörtlich, und der größte Teil der Verwirrung darum löst sich auf.
Wenn du dich erst damit befasst, wie kompilierte Sprachen überhaupt ein Ziel erreichen, setzt unsere Notiz dazu, was ein Algorithmus ist, eine Ebene darunter an.
Die Definition, die vier Designziele und ihre Formulierung, die Aussage über Aufrufe in den und aus dem JavaScript-Kontext sowie der Hinweis auf Einbettungen außerhalb des Webs stammen von der offiziellen WebAssembly-Website, geprüft zum Zeitpunkt des Schreibens. Die Spezifikation entwickelt sich weiter; prüfe gegen die aktuelle Dokumentation, bevor du dich auf eine bestimmte Fähigkeit verlässt.