WASM - WTF?

[1unitedpower]

Früher haben JavaScript-Engines Programme einfach interpretiert. V8 hat dann einen Paradigmen-Wechsel eingeläutet und seitdem übersetzen die Engines Programme zur Laufzeit in Byte-Code, der dann auf einer virtuellen Maschine ausgeführt wird. Das hat seinerzeit zu enormen Geschwindigskeits-Steigerungen geführt.

Dazu kommt, dass JavaScript heute nicht mehr die einzige Option ist, für Browser zu entwickeln. Es gibt zahlreiche Sprachen, die man nach JavaScript übersetzen kann und die dadurch indirekt im Browser ausgeführt werden können.

Man kann JavaScript-Programme im Allgemeinen leider nicht schon zur Entwicklungszeit in den Byte-Code der VM übersetzen. Es gibt immer Fälle, die kann man erst übersetzen, wenn die Code-Ausführung zu einer bestimmten Stelle voran geschritten ist. Für andere Sprachen gilt diese Limitierung aber nicht zwangsläufig, C/C++ sind solche Kandidaten. Das verspricht erneut massive Geschwindigkeits-Vorteile, die adressiert WebAssembly:

1. Byte-Code ist platzsparender als JavaScript-Code, die Netzwerk-Verbindung wird also nicht so sehr belastet.
2. Die Parsing- und Übersetzungs-Schritte entfallen zur Laufzeit, was die eigentliche Code-Ausführung wesentlich beschleunigt.
3. WebAssembly-Programme verwalten ihren Speicher manuell, dadurch kann die Garbage-Collection umgangen werden. Dazu gleich mehr.

Für solche Sprachen ist WebAssembly also ein besseres Übersetzungs-Ziel als JS.

WebAssembly eignet sich derzeit noch nicht als Übersetzungsziel für Sprachen, die auf eine eigene Garbage-Collection angewiesen sind. Weil WebAssembly (noch) keine Schnittstelle zur GC enthält, würde man bei solchen Sprachen quasi das ganze Laufzeit-System samt GC kompilieren und nicht in den Genuss der Vorteile gelangen. Eine Schnittstelle zur GC ist aber geplant und das wird WebAssembly zukünftig auch für Sprachen dieser Art zu einem lukrativen Übersetzungsziel machen.

Was die Sicherheit betrifft, ist WebAssembly so entworfen worden, dass die selben Zugriffs-Beschränkungen eingehalten werden müssen, die auch für JS gelten. Es ist der selbe Teil der JS-Engine, der bspw. den Dateisystem-Zugriff reguliert. Das ist der wesentliche Unterschied im Security-Modell von WASM und vorherigen Plugin-Lösungen. Es ist sogar ein explizit genannter Anwendungsfall, nicht-vertrauenswürdigen Code (serverseitig) gefahrlos auszuführen. Realisiert wird das über Sandboxing. Nichtsdestotrotz werden Engines dadurch natürlich komplexer und es birgt Fehler-Potenzial, das galt aber auch schon für HTML5 und CSS3 und letztlich jede Entwicklung, die uns das Internet beschert hat.

Zum Punkt Lesbarkeit: JavaScript-Programme sind heute teilweise auch schon nicht mehr lesbar. Der Code den man im Browser zu sehen bekommt, hat in der Regel nicht mehr viel mit dem Code zu tun, den der oder die Entwickler(in) geschrieben hat. Minifier, Obfuscater, Transpiler, die heute im professionellen Bereich nicht mehr wegzudenken sind, transformieren alle Code, um ganz unterschiedliche Ziele zu erreichen. Für das Debugging solcher Programme gibt es SourceMaps, die von heutigen Browsern fast nahtlos in die Entwickler-Tools integriert sind. Step-Through-Debugging mit TypeScript ist heute schon recht schmerzfrei. Die SourceMaps wird es auch für WebAssembly wieder geben. Dazu bekommt WebAssembly ein menschenlesbares Format, das ein wenig an Lisp erinnert.