Ist WebAssembly auch außerhalb des Browsers nutzbar?
Kurz gesagt: ja.
WebAssembly (Wasm) hat sich als dominante Technologie herauskristallisiert, die die Webentwicklung im Sturm erobert hat. Von frühen technischen Demos wie dem beliebten Spiel Doom, das vollständig im Browser läuft , bis hin zu großen Legacy-Apps wie Photoshop, die ein vollständiges Desktop-ähnliches Erlebnis auf einer normalen Webseite bieten, ermöglicht WebAssembly völlig neue Erfahrungen in einem vertrauten Programm, das bereits auf jedem PC der Welt installiert ist.
Wasm wurde so konzipiert, dass es von nahezu jeder Programmiersprache unterstützt wird, unabhängig vom Prozessortyp des Computers des Benutzers, und es verfügt über mehrere vorteilhafte Sicherheitseigenschaften, mit denen der Browser unberechtigter Zugriff auf die Daten oder Systemressourcen eines Benutzers verhindert. Es stellt sich heraus, dass diese Eigenschaften außerhalb des Browsers unglaublich nützlich sind, insbesondere wenn Sie Code isoliert oder ultraportabel ausführen möchten.
Die Geschichte von POSIX unter Unix
WebAssembly hat standardmäßig keinen Zugriff auf Ressourcen des Systems, auf dem es ausgeführt wird. Es handelt sich dabei lediglich um die reine Manipulation von Nullen und Einsen. Aus diesem Grund wird Wasm auch hauptsächlich für rechenintensive Aufgaben wie das Dekodieren von Videos oder die Manipulation von Bildern und nicht für die umfassende App-Entwicklung eingesetzt. Es ist relativ einfach, Ihrer WebAssembly-Sandbox Zugriff auf externe Funktionen zu gewähren, etwa auf Informationen zur aktuellen Uhrzeit oder in einer Datei gespeicherte Daten. Welche APIs genau verwendet werden, variiert jedoch in der Regel von App zu App.
Auf Unix-Systemen ist etwas Ähnliches passiert wie mit WebAssembly außerhalb des Browsers. Viele Apps wollten auf allgemeine Systemressourcen wie Netzwerk- und Dateisysteme zugreifen, aber jedes Betriebssystem hatte dafür eine etwas andere Vorgehensweise. Aus diesem Grund wurde POSIX erstmals als Standardschnittstelle für portable Betriebssysteme eingesetzt. Alle Unix-ähnlichen Systeme konnten diese Schnittstelle übernehmen, um die Kommunikation von Programmen mit dem Betriebssystem zu standardisieren. Dadurch konnten auch Programme, die für die Ausführung auf einem Unix-ähnlichen System entwickelt wurden, problemlos auf ein anderes System portiert werden.
Hier kommt WASI ins Spiel, die WebAssembly System Interface
Um WebAssembly-Programmen eine standardisierte Möglichkeit zur Kommunikation mit einem Betriebssystem zu bieten, wurde WASI, die WebAssembly System Interface, entwickelt. WASI wurde weitgehend von einem Projekt namens CloudABI inspiriert, das wiederum von POSIX inspiriert wurde. Dies eröffnete WebAssembly eine Welt voller Möglichkeiten, auch außerhalb des Browsers zu glänzen – Benutzer hatten nun alle Sicherheits- und Sandboxing-Eigenschaften von WebAssembly in Kombination mit durchdachten APIs, um auf allgemeine Systemressourcen zuzugreifen, ohne vollständig auf Sandboxing verzichten zu müssen. Natürlich kommt einem eine ähnliche Technologie in den Sinn: Container. Keine Diskussion zu diesem Thema ist vollständig ohne einen Verweis auf einen der tiefgründigsten und am häufigsten geteilten Posts über WASI von Docker-Mitbegründer Solomon Hykes:
Das ist eine ziemliche Aussage. WebAssembly bietet eine portable Möglichkeit zum Verpacken von Code, der auf jeder Plattform sicher und geschützt mit nahezu nativer Geschwindigkeit ausgeführt werden kann, mit dem zusätzlichen Vorteil gegenüber Containern, dass überhaupt kein Betriebssystem vorhanden sein muss. Die meisten von Entwicklern erstellten Container verfügen über eine Art Linux-Betriebssystem, auf dem Programme ausgeführt werden, was zu Containergrößen von oft Hunderten von Megabyte oder mehreren Gigabyte führt. WebAssembly-Binärdateien bestehen aus reinem Code mit Größen oft im Kilobyte- oder einstelligen Megabyte-Bereich. Es erscheint verrückt, sich eine Welt vorzustellen, in der Entwickler nicht überall Container, sondern WebAssembly einsetzen. Doch diese Realität wird bereits Wirklichkeit: Es werden bereits mehrere Projekte entwickelt, um Wasm auf Kubernetes auszuführen.
Serverseitiges WebAssembly in der Produktion
Zahlreiche Unternehmen profitieren bereits von serverseitigem Wasm in der Produktion. Cloudflare und Fastly verfügen beide über riesige Edge-Compute-Netzwerke, die es Kunden ermöglichen, Code überall auf der Welt und so nah wie möglich an den Benutzern bereitzustellen. Beide haben sich aus strategischen Gründen für WebAssembly entschieden, um über kleine, ultra-portable Binärdateien mit schnellen Startzeiten und solider Multi-Tenancy zu verfügen. Das aufstrebende Unternehmen Cosmonic nutzt intelligente Netzwerke, um es WebAssembly-Komponenten zu ermöglichen, nahtlos miteinander zu kommunizieren, egal wo sie ausgeführt werden – sei es auf einem winzigen Gerät in Ihrer Handfläche oder auf einer Maschine, die am anderen Ende der Welt läuft. Ein weiterer Emporkömmling, Fermyon, verwendet WebAssembly, um die Server-Arbeitslastdichte massiv zu erhöhen. Das Ergebnis ist eine drastische Reduzierung der Serverkosten und eine umweltfreundlichere Computernutzung.
Wachstum außerhalb des Browsers
Zusammenfassend lässt sich sagen, dass WebAssembly, obwohl ursprünglich für das Computing im Browser entwickelt, auch außerhalb des Browsers eine hohe Lebensfähigkeit gezeigt hat. Sein Design, das verschiedene Programmiersprachen unterstützt und auf Sicherheit setzt, macht es zu einer ausgezeichneten Wahl für die isolierte Ausführung von Code und das Erreichen von Portabilität. Durch die Einführung von WASI konnte serverseitiges WebAssembly florieren. Unternehmen können nun Wasm nutzen und bessere Produkte zu wesentlich geringerer Kosteneffizienz anbieten. Das Potenzial von WebAssembly außerhalb des Browsers ist nicht nur eine Idee, sondern eine wachsende Realität für die Branche.
Weitere Informationen finden Sie in unserem vorherigen Blogbeitrag „ Warum Sie sich für WebAssembly interessieren sollten “.
Sehen oder hören Sie sich auch unseren Podcast „WebAssembly Unleashed“ an.