WASM, die neue CGI-Technologie

Wasm ist die neue CGI

• Die Rolle von Wasm: Wasm (WebAssembly) steht bereit, einen neuen Wandel im Modell von Webanwendungen herbeizuführen. Der Schwerpunkt liegt darauf, den Bau und die Wartung von Hochleistungsanwendungen zu erleichtern.
• Frühere Modelle von Webanwendungen: CGI verwandelte das Web von einem Dokumentenarchiv in ein Netzwerk von Anwendungen. FastCGI wurde entwickelt, um Leistungsprobleme zu lösen, und entwickelte sich später in Richtung serverloses Computing weiter.
• Serverloses Computing: Serverloses Computing wie Amazon Lambda führt dazu, dass man statt Servern „Funktionen“ verwaltet. Das bietet den Vorteil, sich je nach Anfragevolumen schnell skalieren zu können.

Wasm auf dem Server

• Die Erweiterbarkeit von Wasm: Wasm kann nicht nur im Browser, sondern auch auf dem Server ausgeführt werden und bietet dadurch ein leichtergewichtiges Isolationsmodell für serverseitige Anwendungen.
• Wasm-Laufzeitumgebung: Wasm-Module laufen in einer virtuellen Maschine und können aus verschiedenen Sprachen kompiliert werden. Das kann zur Leistungssteigerung in serverlosen Umgebungen beitragen.

Trade-offs von Wasm

• Threads und JIT-Kompilierung: Wasm unterstützt Threads nicht nativ, und JIT-Kompilierung ist nicht möglich. Das kann sich auf die Leistung auswirken.
• Speicherinterface: Die Datenübertragung zwischen Wasm-Modulen und dem Host kann Kopiervorgänge erfordern, was sich auf die Leistung auswirken kann.

Ausblick

• Weiterentwicklung von Wasm: Mit der Weiterentwicklung von Wasm-Laufzeitumgebungen und Entwicklerwerkzeugen werden Skriptsprachen über Wasm-Runtimes verfügen. Das könnte die Ausführungsgeschwindigkeit von Anwendungen erheblich verbessern.
• Edge Computing: Wasm ermöglicht es durch Edge Computing, Rechenleistung in der Nähe der Nutzer bereitzustellen, was die Leistung verbessert.

# GN⁺-Zusammenfassung

• Wasm treibt einen neuen Wandel im Modell von Webanwendungen voran und erleichtert so den Bau und die Wartung von Hochleistungsanwendungen.
• Die Kombination aus serverlosem Computing und Wasm reduziert die Komplexität der Serververwaltung und bietet den Vorteil, sich je nach Anfragevolumen schnell skalieren zu können.
• Wasm kann nicht nur im Browser, sondern auch auf dem Server ausgeführt werden und bietet dadurch ein leichtergewichtiges Isolationsmodell für serverseitige Anwendungen.
• Die Weiterentwicklung von Wasm könnte dazu führen, dass Skriptsprachen über Wasm-Runtimes verfügen und sich dadurch die Ausführungsgeschwindigkeit von Anwendungen erheblich verbessert.
• Durch Edge Computing wird Rechenleistung in der Nähe der Nutzer möglich, was die Leistung verbessert.

[GN⁺]

Hacker-News-Kommentare

• Amazon leitete mit Lambda das Zeitalter des Serverless Computing ein. Google App Engine wurde 6 Jahre vor Lambda veröffentlicht.

• Es ist schwer zu verstehen, worin sich WASM von früheren Technologien wie Java Applets, ActiveX, Silverlight und Macromedia Flash unterscheidet. Man dachte, man hätte die Lektionen darüber gelernt, wie problematisch es ist, nicht vertrauenswürdigen kompilierten Drittanbieter-Code im Webbrowser auszuführen.

• JIT-Kompilierung ist nicht möglich, weil aus Sicherheitsgründen keine dynamische Erzeugung von WASM-Code erlaubt ist. Das ist eine wesentliche Funktion, um Dinge wie Hot Reloading von Code sauber umzusetzen.

• Die Sicherheitsargumente erscheinen nicht glaubwürdig. Man kann zur Laufzeit JS hot-reloaden oder Code generieren, und man könnte die WASM-Runtime dynamisch neu laden, während der Speicher erhalten bleibt, aber die User Experience wäre unbequem.

• Es wurde kein technisch unmöglicher Grund gefunden. Wenn es eine Sicherheitsmaßnahme ist, ließe sie sich leicht umgehen.

• WASM-Bytecode ist konzeptionell ähnlich zu Dingen wie .NET IL und Java-Bytecode, die für JIT-Kompilierung entworfen wurden.

• Das WASM-Projekt scheint keine klare Richtung und keinen starken Erfolgswillen zu haben. Grundlegende Funktionen fehlen noch immer.

  • Dazu gehören Hot Reload, nicht-hackiges Threading, native Schnittstellen zum DOM, Unterstützung für Grafik-/Compute-APIs mit geringem Overhead und Low-Level-Zugriff auf Audio.

• WASM ersetzt die VM einer bestimmten Sprache durch eine VM für allgemeine Zwecke. Damit kann fast alles über Compiler oder Interpreter ausgeführt werden.

  • Es wird normalerweise als Teil einer JavaScript-Engine implementiert und erbt dadurch Sandboxing und API-Zugriff. Die Standardisierung läuft noch.

• WASM wird als Ersatz für JavaScript, Docker, Java, CGI usw. dargestellt. Es ist damit irgendwie alles.

• WASM sollte sich so einfach hosten und deployen lassen wie eine PHP-Anwendung. Das ist offenbar noch nicht der Fall.

• Es erinnert an ein altes Gesetz der Softwareentwicklung: Jede ausreichend große und alte Anwendung wird am Ende den gesamten Software-Stack, auf dem sie läuft, neu implementieren.

• Das große Versprechen von serverseitigem WASM ist eine ewige Plattform bereitzustellen, die keine regelmäßigen Updates benötigt.

  • Es ist ein großes Problem, AWS-Lambda-Apps jedes Mal aktualisieren und neu deployen zu müssen, wenn eine Node.js- oder Python-Version nicht mehr unterstützt wird.

• Local First ist vermutlich die Zukunft. Apps laufen überwiegend im Browser der Nutzer und benötigen nur sehr wenig Hilfe vom Server.

  • Apps wie Figma, Linear und Superhuman nutzen dieses Modell erfolgreich.

• WASM kann im Browser der Nutzer erfolgreich sein. Microsoft nutzt es dafür mit C#/Blazor.

• Es sieht so aus, als würde die JVM und ihr Ökosystem neu erfunden.

• WASM wird sich vermutlich dahin entwickeln, im Cloud-Umfeld den Code für die Ausführung von Lambda-Funktionen zu ersetzen.

  • WASM wird traditionell als etwas wahrgenommen, das auf der Host-Plattform läuft, aber das muss nicht zwingend so sein.

  • Dank der Sandbox-Eigenschaften von WASM kann es außerhalb des Betriebssystems oder in ring0 ausgeführt werden.