Einige Programmiersprachen sind besser für Wasm geeignet als andere.TippaPatt | shutterstock.com WebAssembly, kurz Wasm, bietet Entwicklern die Möglichkeit, Programme zu erstellen, die mit nahezu nativer Geschwindigkeit im Browser ausgeführt werden können. Oder überall sonst, wo die WebAssembly-Laufzeitumgebung bereitgestellt werden kann. Allerdings werden Applikationen im Regelfall nicht direkt in Wasm geschrieben, sondern in anderen Sprachen, um sie anschließend zu kompilieren – mit Wasm als Ziel. Die folgenden sechs Sprachen lassen sich über verschiedene Tools mit unterschiedlichem Aufwand und Kompatibilitätsgrad – auf Wasm-Laufzeitumgebungen bereitstellen. Rust Rust ist wahrscheinlich die Sprache, die sich am besten für den WebAssembly-Einsatz eignet. Das liegt auch daran, dass existierender Rust-Code nicht wesentlich modifiziert werden muss, um ihn in Wasm zu kompilieren: Das Gros der nötigen Änderungen besteht darin, das richtige Compiler-Ziel und die korrekten Kompilierungseinstellungen einzurichten. Das Tooling generiert außerdem automatisch JavaScript-Boilerplate-Code, der ermöglicht, dass die kompilierten Wasm-Module direkt mit Webseiten interagieren können. Die Größe des kompilierten Moduls variiert dabei, allerdings ist Rust-Code relativ schlank und effizient – ein simples „Hello, world“ ist deshalb in der Regel nicht größer als einige Kilobyte. Die Entwickler hinter Rust stellen zudem auch einen umfassenden Leitfaden zur Wasm-Nutzung bereit. Dieser enthält zum Beispiel detaillierte Informationen darüber, wie sich die Größe der Binaries in Grenzen halten lässt oder wie sich existierende, universelle Rust Crates um Wasm-Support erweitern lassen. C/C++ C und C++ zählten zu den ersten Sprachen, die für Wasm kompiliert wurden. Das lag vor allem daran, dass viele der Low-Level-Verhaltensweisen dieser Sprachen gut auf dem Befehlssatz von Wasm abgebildet werden können. So waren auch die ersten Wasm-Demos Portierungen von Grafikdemos und Spielen, die in C/C++ geschrieben waren. Diese Proof-of-Concept-Projekte (etwa Doom im Browser) haben wesentlichen Anteil daran, dass sich WebAssembly etablieren konnte. Eines der ersten Tools, um C/C++ in Wasm zu kompilieren, war die Emscripten-Toolchain. Diese hat sich seitdem zu einer vollwertigen Toolchain zu diesem Zweck entwickelt – und bietet detaillierte Anweisungen, um Code zu portieren. So können etwa SIMD, Netzwerke, C++-Exceptions, asynchroner Code und viele andere erweiterte Funktionen nach Wasm portiert werden. Der Arbeitsaufwand variiert dabei je nach Funktion. So ist Pthread-Support beispielsweise nicht standardmäßig aktiviert und funktioniert in Browsern nur, wenn der Webserver bestimmte Ursprungs-Header korrekt gesetzt hat. Ab Version 8 kann der Clang C/C++-Compiler ohne zusätzliche Tools nativ für Wasm kompilieren. Emscripten verwendet jedoch dieselbe zugrundeliegende Technologie wie Clang und bietet möglicherweise ein umfassenderes Toolset. Golang Go wurde bereits mit Version 1.11 im August 2018 um WebAssembly-Support ergänzt. Ähnlich wie bei Rust betreffen die meisten Änderungen, die an Go-Programmen für Wasm vorgenommen werden müssen eher den Kompilierungsprozess als das Programm selbst. Die Wasm-Toolchain ist dabei im Go-Compiler enthalten, so dass keine weiteren Tools oder Packages nötig sind. Lediglich die Umgebungsvariablen GOOS und GOARCH sind beim Kompilieren zu ändern. Manuell einzurichten ist hingegen der JavaScript-Boilerplate-Code, der nötig ist, um Wasm-kompilierte Go-Module verwenden zu können. Dazu müssen allerdings lediglich einige Dateien kopiert werden. Der Vorgang lässt sich darüber hinaus auch automatisieren. Komplexer wird’s, wenn es um die Interaktion mit dem DOM geht. Die dafür enthaltenen Tools (syscalls/js-Package) funktionieren, sind aber höchstens für simple Interaktionen geeignet. Für alles, was darüber hinausgeht, empfiehlt sich eine (geeignete) Drittanbieter-Bibliothek. Ein weiterer Nachteil, Go mit Wasm zu nutzen, ist die Größe der generierten Binärartefakte. Aufgrund der Laufzeitumgebung von Go kann selbst ein „Hello, world“-Modul bis zu zwei Megabyte groß werden. Um Platz zu sparen, können Sie Wasm-Binärdateien jedoch komprimieren – oder eine andere Go-Laufzeitumgebung verwenden, wie beispielsweise TinyGo. Diese Option funktioniert aber nur mit einer Teilmenge von Golang. JavaScript Es könnte redundant erscheinen, JavaScript in Wasm zu übersetzen. Schließlich läuft Wasm im Regelfall im Browser – und diese verfügen in den allermeisten Fällen über eine integrierte JavaScript-Laufzeitumgebung. Trotzdem ist es möglich, JavaScript in Wasm zu kompilieren. Zu diesem Zweck empfiehlt sich in erster Linie das Tool Javy, das von der Bytecode Alliance (ein Haupt-Kontributor für Wasm-Initiativen) entwickelt wird. Javy kompiliert JavaScript-Code allerdings genau genommen nicht wirklich in Wasm, sondern führt ihn in einer Wasm-basierten JavaScript-Laufzeitumgebung aus. Zudem macht sich das Werkzeug auch eine dynamische Linking-Strategie zu Nutze, um die resultierenden Wasm-Module relativ klein zu halten. Auch hier variiert die Größe jedoch je nach den in Ihrem Programm verwendeten Funktionen. Python Die Situation bei Python gestaltet sich ähnlich wie bei Go: Python-Programme lassen sich nicht ohne die Python-Laufzeitumgebung ausführen. Und ohne die Python-Standardbibliothek ist es schwierig, etwas Sinnvolles anzustellen. Ganz zu schweigen vom ausufernden Python-Ökosystem. Sie könnten Python zwar über die Wasm-Laufzeitumgebung ausführen, das ist aber vor allem eines: umständlich. Eine bessere Methode, Python-Anwendungen über eine Wasm-Laufzeitumgebung auszuführen, bietet Pyodide – eine Portierung der CPython-Laufzeitumgebung auf Wasm über Emscripten. Eine Implementierung davon, PyScript, ermöglicht es, Python-Programme in Webseiten wie JavaScript auszuführen. Es umfasst auch bidirektionalen Support für die Kommunikation zwischen Python und der JavaScript/DOM-Seite. Dennoch hat Pyodide auch mehrere Nachteile: Pakete, die C-Erweiterungen verwenden (etwa NumPy), müssen manuell auf Pyodide portiert werden, damit sie funktionieren. Von PyPI können nur reine Python-Pakete installiert werden. Außerdem muss Pyodide ein separates Wasm-Paket für die Python-Laufzeitumgebung herunterladen, das mehrere Megabyte groß ist. Das kann – je nach Voraussetzungen – ein Hindernis darstellen. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!
6 WebAssembly-fähige Sprachen
Einige Programmiersprachen sind besser für Wasm geeignet als andere.TippaPatt | shutterstock.com WebAssembly, kurz Wasm, bietet Entwicklern die Möglichkeit, Programme zu erstellen, die mit nahezu nativer Geschwindigkeit im Browser ausgeführt werden können. Oder überall sonst, wo die WebAssembly-Laufzeitumgebung bereitgestellt werden kann. Allerdings werden Applikationen im Regelfall nicht direkt in Wasm geschrieben, sondern in anderen Sprachen, um sie anschließend zu kompilieren – mit Wasm als Ziel. Die folgenden sechs Sprachen lassen sich über verschiedene Tools mit unterschiedlichem Aufwand und Kompatibilitätsgrad – auf Wasm-Laufzeitumgebungen bereitstellen. Rust Rust ist wahrscheinlich die Sprache, die sich am besten für den WebAssembly-Einsatz eignet. Das liegt auch daran, dass existierender Rust-Code nicht wesentlich modifiziert werden muss, um ihn in Wasm zu kompilieren: Das Gros der nötigen Änderungen besteht darin, das richtige Compiler-Ziel und die korrekten Kompilierungseinstellungen einzurichten. Das Tooling generiert außerdem automatisch JavaScript-Boilerplate-Code, der ermöglicht, dass die kompilierten Wasm-Module direkt mit Webseiten interagieren können. Die Größe des kompilierten Moduls variiert dabei, allerdings ist Rust-Code relativ schlank und effizient – ein simples „Hello, world“ ist deshalb in der Regel nicht größer als einige Kilobyte. Die Entwickler hinter Rust stellen zudem auch einen umfassenden Leitfaden zur Wasm-Nutzung bereit. Dieser enthält zum Beispiel detaillierte Informationen darüber, wie sich die Größe der Binaries in Grenzen halten lässt oder wie sich existierende, universelle Rust Crates um Wasm-Support erweitern lassen. C/C++ C und C++ zählten zu den ersten Sprachen, die für Wasm kompiliert wurden. Das lag vor allem daran, dass viele der Low-Level-Verhaltensweisen dieser Sprachen gut auf dem Befehlssatz von Wasm abgebildet werden können. So waren auch die ersten Wasm-Demos Portierungen von Grafikdemos und Spielen, die in C/C++ geschrieben waren. Diese Proof-of-Concept-Projekte (etwa Doom im Browser) haben wesentlichen Anteil daran, dass sich WebAssembly etablieren konnte. Eines der ersten Tools, um C/C++ in Wasm zu kompilieren, war die Emscripten-Toolchain. Diese hat sich seitdem zu einer vollwertigen Toolchain zu diesem Zweck entwickelt – und bietet detaillierte Anweisungen, um Code zu portieren. So können etwa SIMD, Netzwerke, C++-Exceptions, asynchroner Code und viele andere erweiterte Funktionen nach Wasm portiert werden. Der Arbeitsaufwand variiert dabei je nach Funktion. So ist Pthread-Support beispielsweise nicht standardmäßig aktiviert und funktioniert in Browsern nur, wenn der Webserver bestimmte Ursprungs-Header korrekt gesetzt hat. Ab Version 8 kann der Clang C/C++-Compiler ohne zusätzliche Tools nativ für Wasm kompilieren. Emscripten verwendet jedoch dieselbe zugrundeliegende Technologie wie Clang und bietet möglicherweise ein umfassenderes Toolset. Golang Go wurde bereits mit Version 1.11 im August 2018 um WebAssembly-Support ergänzt. Ähnlich wie bei Rust betreffen die meisten Änderungen, die an Go-Programmen für Wasm vorgenommen werden müssen eher den Kompilierungsprozess als das Programm selbst. Die Wasm-Toolchain ist dabei im Go-Compiler enthalten, so dass keine weiteren Tools oder Packages nötig sind. Lediglich die Umgebungsvariablen GOOS und GOARCH sind beim Kompilieren zu ändern. Manuell einzurichten ist hingegen der JavaScript-Boilerplate-Code, der nötig ist, um Wasm-kompilierte Go-Module verwenden zu können. Dazu müssen allerdings lediglich einige Dateien kopiert werden. Der Vorgang lässt sich darüber hinaus auch automatisieren. Komplexer wird’s, wenn es um die Interaktion mit dem DOM geht. Die dafür enthaltenen Tools (syscalls/js-Package) funktionieren, sind aber höchstens für simple Interaktionen geeignet. Für alles, was darüber hinausgeht, empfiehlt sich eine (geeignete) Drittanbieter-Bibliothek. Ein weiterer Nachteil, Go mit Wasm zu nutzen, ist die Größe der generierten Binärartefakte. Aufgrund der Laufzeitumgebung von Go kann selbst ein „Hello, world“-Modul bis zu zwei Megabyte groß werden. Um Platz zu sparen, können Sie Wasm-Binärdateien jedoch komprimieren – oder eine andere Go-Laufzeitumgebung verwenden, wie beispielsweise TinyGo. Diese Option funktioniert aber nur mit einer Teilmenge von Golang. JavaScript Es könnte redundant erscheinen, JavaScript in Wasm zu übersetzen. Schließlich läuft Wasm im Regelfall im Browser – und diese verfügen in den allermeisten Fällen über eine integrierte JavaScript-Laufzeitumgebung. Trotzdem ist es möglich, JavaScript in Wasm zu kompilieren. Zu diesem Zweck empfiehlt sich in erster Linie das Tool Javy, das von der Bytecode Alliance (ein Haupt-Kontributor für Wasm-Initiativen) entwickelt wird. Javy kompiliert JavaScript-Code allerdings genau genommen nicht wirklich in Wasm, sondern führt ihn in einer Wasm-basierten JavaScript-Laufzeitumgebung aus. Zudem macht sich das Werkzeug auch eine dynamische Linking-Strategie zu Nutze, um die resultierenden Wasm-Module relativ klein zu halten. Auch hier variiert die Größe jedoch je nach den in Ihrem Programm verwendeten Funktionen. Python Die Situation bei Python gestaltet sich ähnlich wie bei Go: Python-Programme lassen sich nicht ohne die Python-Laufzeitumgebung ausführen. Und ohne die Python-Standardbibliothek ist es schwierig, etwas Sinnvolles anzustellen. Ganz zu schweigen vom ausufernden Python-Ökosystem. Sie könnten Python zwar über die Wasm-Laufzeitumgebung ausführen, das ist aber vor allem eines: umständlich. Eine bessere Methode, Python-Anwendungen über eine Wasm-Laufzeitumgebung auszuführen, bietet Pyodide – eine Portierung der CPython-Laufzeitumgebung auf Wasm über Emscripten. Eine Implementierung davon, PyScript, ermöglicht es, Python-Programme in Webseiten wie JavaScript auszuführen. Es umfasst auch bidirektionalen Support für die Kommunikation zwischen Python und der JavaScript/DOM-Seite. Dennoch hat Pyodide auch mehrere Nachteile: Pakete, die C-Erweiterungen verwenden (etwa NumPy), müssen manuell auf Pyodide portiert werden, damit sie funktionieren. Von PyPI können nur reine Python-Pakete installiert werden. Außerdem muss Pyodide ein separates Wasm-Paket für die Python-Laufzeitumgebung herunterladen, das mehrere Megabyte groß ist. Das kann – je nach Voraussetzungen – ein Hindernis darstellen. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!
6 WebAssembly-fähige Sprachen Einige Programmiersprachen sind besser für Wasm geeignet als andere.TippaPatt | shutterstock.com WebAssembly, kurz Wasm, bietet Entwicklern die Möglichkeit, Programme zu erstellen, die mit nahezu nativer Geschwindigkeit im Browser ausgeführt werden können. Oder überall sonst, wo die WebAssembly-Laufzeitumgebung bereitgestellt werden kann. Allerdings werden Applikationen im Regelfall nicht direkt in Wasm geschrieben, sondern in anderen Sprachen, um sie anschließend zu kompilieren – mit Wasm als Ziel. Die folgenden sechs Sprachen lassen sich über verschiedene Tools mit unterschiedlichem Aufwand und Kompatibilitätsgrad – auf Wasm-Laufzeitumgebungen bereitstellen. Rust Rust ist wahrscheinlich die Sprache, die sich am besten für den WebAssembly-Einsatz eignet. Das liegt auch daran, dass existierender Rust-Code nicht wesentlich modifiziert werden muss, um ihn in Wasm zu kompilieren: Das Gros der nötigen Änderungen besteht darin, das richtige Compiler-Ziel und die korrekten Kompilierungseinstellungen einzurichten. Das Tooling generiert außerdem automatisch JavaScript-Boilerplate-Code, der ermöglicht, dass die kompilierten Wasm-Module direkt mit Webseiten interagieren können. Die Größe des kompilierten Moduls variiert dabei, allerdings ist Rust-Code relativ schlank und effizient – ein simples „Hello, world“ ist deshalb in der Regel nicht größer als einige Kilobyte. Die Entwickler hinter Rust stellen zudem auch einen umfassenden Leitfaden zur Wasm-Nutzung bereit. Dieser enthält zum Beispiel detaillierte Informationen darüber, wie sich die Größe der Binaries in Grenzen halten lässt oder wie sich existierende, universelle Rust Crates um Wasm-Support erweitern lassen. C/C++ C und C++ zählten zu den ersten Sprachen, die für Wasm kompiliert wurden. Das lag vor allem daran, dass viele der Low-Level-Verhaltensweisen dieser Sprachen gut auf dem Befehlssatz von Wasm abgebildet werden können. So waren auch die ersten Wasm-Demos Portierungen von Grafikdemos und Spielen, die in C/C++ geschrieben waren. Diese Proof-of-Concept-Projekte (etwa Doom im Browser) haben wesentlichen Anteil daran, dass sich WebAssembly etablieren konnte. Eines der ersten Tools, um C/C++ in Wasm zu kompilieren, war die Emscripten-Toolchain. Diese hat sich seitdem zu einer vollwertigen Toolchain zu diesem Zweck entwickelt – und bietet detaillierte Anweisungen, um Code zu portieren. So können etwa SIMD, Netzwerke, C++-Exceptions, asynchroner Code und viele andere erweiterte Funktionen nach Wasm portiert werden. Der Arbeitsaufwand variiert dabei je nach Funktion. So ist Pthread-Support beispielsweise nicht standardmäßig aktiviert und funktioniert in Browsern nur, wenn der Webserver bestimmte Ursprungs-Header korrekt gesetzt hat. Ab Version 8 kann der Clang C/C++-Compiler ohne zusätzliche Tools nativ für Wasm kompilieren. Emscripten verwendet jedoch dieselbe zugrundeliegende Technologie wie Clang und bietet möglicherweise ein umfassenderes Toolset. Golang Go wurde bereits mit Version 1.11 im August 2018 um WebAssembly-Support ergänzt. Ähnlich wie bei Rust betreffen die meisten Änderungen, die an Go-Programmen für Wasm vorgenommen werden müssen eher den Kompilierungsprozess als das Programm selbst. Die Wasm-Toolchain ist dabei im Go-Compiler enthalten, so dass keine weiteren Tools oder Packages nötig sind. Lediglich die Umgebungsvariablen GOOS und GOARCH sind beim Kompilieren zu ändern. Manuell einzurichten ist hingegen der JavaScript-Boilerplate-Code, der nötig ist, um Wasm-kompilierte Go-Module verwenden zu können. Dazu müssen allerdings lediglich einige Dateien kopiert werden. Der Vorgang lässt sich darüber hinaus auch automatisieren. Komplexer wird’s, wenn es um die Interaktion mit dem DOM geht. Die dafür enthaltenen Tools (syscalls/js-Package) funktionieren, sind aber höchstens für simple Interaktionen geeignet. Für alles, was darüber hinausgeht, empfiehlt sich eine (geeignete) Drittanbieter-Bibliothek. Ein weiterer Nachteil, Go mit Wasm zu nutzen, ist die Größe der generierten Binärartefakte. Aufgrund der Laufzeitumgebung von Go kann selbst ein „Hello, world“-Modul bis zu zwei Megabyte groß werden. Um Platz zu sparen, können Sie Wasm-Binärdateien jedoch komprimieren – oder eine andere Go-Laufzeitumgebung verwenden, wie beispielsweise TinyGo. Diese Option funktioniert aber nur mit einer Teilmenge von Golang. JavaScript Es könnte redundant erscheinen, JavaScript in Wasm zu übersetzen. Schließlich läuft Wasm im Regelfall im Browser – und diese verfügen in den allermeisten Fällen über eine integrierte JavaScript-Laufzeitumgebung. Trotzdem ist es möglich, JavaScript in Wasm zu kompilieren. Zu diesem Zweck empfiehlt sich in erster Linie das Tool Javy, das von der Bytecode Alliance (ein Haupt-Kontributor für Wasm-Initiativen) entwickelt wird. Javy kompiliert JavaScript-Code allerdings genau genommen nicht wirklich in Wasm, sondern führt ihn in einer Wasm-basierten JavaScript-Laufzeitumgebung aus. Zudem macht sich das Werkzeug auch eine dynamische Linking-Strategie zu Nutze, um die resultierenden Wasm-Module relativ klein zu halten. Auch hier variiert die Größe jedoch je nach den in Ihrem Programm verwendeten Funktionen. Python Die Situation bei Python gestaltet sich ähnlich wie bei Go: Python-Programme lassen sich nicht ohne die Python-Laufzeitumgebung ausführen. Und ohne die Python-Standardbibliothek ist es schwierig, etwas Sinnvolles anzustellen. Ganz zu schweigen vom ausufernden Python-Ökosystem. Sie könnten Python zwar über die Wasm-Laufzeitumgebung ausführen, das ist aber vor allem eines: umständlich. Eine bessere Methode, Python-Anwendungen über eine Wasm-Laufzeitumgebung auszuführen, bietet Pyodide – eine Portierung der CPython-Laufzeitumgebung auf Wasm über Emscripten. Eine Implementierung davon, PyScript, ermöglicht es, Python-Programme in Webseiten wie JavaScript auszuführen. Es umfasst auch bidirektionalen Support für die Kommunikation zwischen Python und der JavaScript/DOM-Seite. Dennoch hat Pyodide auch mehrere Nachteile: Pakete, die C-Erweiterungen verwenden (etwa NumPy), müssen manuell auf Pyodide portiert werden, damit sie funktionieren. Von PyPI können nur reine Python-Pakete installiert werden. Außerdem muss Pyodide ein separates Wasm-Paket für die Python-Laufzeitumgebung herunterladen, das mehrere Megabyte groß ist. Das kann – je nach Voraussetzungen – ein Hindernis darstellen. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!