WebAssembly mit Rust in Webbrowsern

WebAssembly ist ein offener Standard eines Bytecode-Formats für virtuelle Maschinen, die sowohl in aktuellen Webbrowsern, als auch freistehenden Laufzeitumgebungen zur Verfügung stehen.

Nicht alle Features von WebAssembly werden allerdings von allen Webbrowsern unterstützt.

Programmiersprachen

WebAssembly-Bytecode wird von Compilern verschiedener Programmiersprachen produziert – darunter auch Rust. Client-seitige Web-Programmierung in diesen Sprachen ist somit möglich.

Software, die bereits in diesen Programmiersprachen geschrieben ist, kann ebenfalls in Webbrowsern genutzt werden. Mittels Emscripten stehen z.B. LaTeX, Python, SQLite oder sogar Qt zur Verfügung.

Performance

WebAssembly an sich hat eine bessere Performance als JavaScript – bei geringerer Schwankungsbreite:

• Die statische Typisierung erlaubt Optimierungen, mit denen WebAssembly bis zu 800 %, im Durchschnitt etwa 30 % schneller ausgeführt werden kann als JavaScript und nur etwa 50 % langsamer als nativer Code.
• Das binäre Format ist kompakter:
  • Die Übertragungszeit kann somit geringer sein. Dieser Vorteil kann aber durch das Übertragen großer Datenmengen, wie z.B. Laufzeitumgebungen von genutzten Programmiersprachen, wieder aufgebraucht werden.
  • WebAssembly kann bis zu 20 mal schneller geparst werden, als JavaScript.
  • Mittels Streaming kann die Verarbeitung bereits ab dem ersten übertragenen Byte erfolgen.
• Aufwände für JIT-Kompilierung fallen nicht an.
• Aufwände für Garbage Collection fallen nicht an, wenn WasmGC nicht verwendet wird.
• Der lineare Speicher der WebAssembly VM ist effizienter zu nutzen.

Aber: in Webbrowsern erfolgt die Interaktion mit dem DOM und allen anderen Web APIs über einen JavaScript-Shim. Auch Eventhandler-Callbacks müssen diesen passieren. UTF-8-Strings müssen dabei in JavaScripts UTF-16-Strings transkodiert werden – und umgekehrt. Zugriffe auf den DOM können grundsätzlich nur aus dem JavaScript-Haupt-Thread erfolgen.

Die Grenze zwischen JavaScript und WebAssembly stellt somit einen Flaschenhals dar. Ihn zu durchschreiten, kann 10-1000 % langsamer sein, als der entsprechende reine JavaScript-Aufruf.

Es gibt Möglichkeiten, diesen Flaschenhals zu weiten:

• mehrere Aufrufe von createElement(), appendChild(), remove() etc. lassen sich durch einmaliges Setzen des innerHTML-Attributs ersetzen
• der Binding Generator sledgehammer_bindgen vermeidet einigen Overhead

Benchmarks

• js web frameworks benchmark: hier ist das dennoch gute Abschneiden der folgenden Rust-Frameworks/-Tools beachtlich: sledgehammer_bindgen, wasm-bindgen, Kobold
• JS / wasm-bindgen comparison
• Rust Wasm Benchmark
• Call me maybe?
• PSPDFKIT: WebAssembly (C++) vs JavaScript
• WasmBoy Benchmarking: AssemblyScript vs TypeScript

Programmierung

Tools und Crates:

• Binding Generatoren:
  • wasm-bindgen
  • sledgehammer_bindgen
• Bindings:
  • web-sys
  • js-sys
  • gloo bietet komfortable Wrapper an
• Deployment:
  • wasm-pack
  • Trunk bietet Hot Reloading an

Da fetch() asynchron ist, ist vielfach Asynchrones Rust notwendig. spawn_local() ist eine Möglichkeit, eine asynchrone Funktion (Future) aus einer synchronen Funktion heraus aufzurufen. Die Future muss allerdings die Lifetime 'static haben.