Was sind die Unterschiede zwischen WebAssembly und der JVM?

Im Kern waren sowohl die JVM als auch WebAssembly darauf ausgelegt, kompilierten Code praktisch überall auszuführen. Für die JVM bedeutete dies Maschinen mit unterschiedlichen Betriebssystemen oder CPU-Architekturen, was für die damalige Zeit beispiellos war, und für WebAssembly bedeutete dies jeden Webbrowser auf jedem Computer überall und für alle Zeiten.

Die JVM, die Mitte der 1990er Jahre zusammen mit Java eingeführt wurde, entwickelte sich zu einer vollwertigen Plattform, die umfassende Laufzeitunterstützung bietet – Garbage Collection, umfangreiche Standardbibliotheken und Tools für die verwaltete Ausführung. Manche meinen jedoch, dass dies zu einer erheblichen Aufblähung der JVM führt: großer Speicherbedarf und längere Startzeiten. Obwohl die JVM extrem leistungsstark ist, ist sie für einfache Applications weniger geeignet.

Im Gegensatz dazu wurde WebAssembly speziell für das Web entwickelt, insbesondere für die Ausführung von Code in Browsern. Daher wurde die Architektur so konzipiert, dass eine schlanke Laufzeit und blitzschnelle Startzeiten im Vordergrund stehen, allerdings ohne umfassende Laufzeitunterstützung. Würde Wasm nur auf Browser ausgerichtet sein, wäre es weniger portabel als Java-Bytecode. Heute können jedoch eigenständige Wasm-Laufzeiten außerhalb des Webs ausgeführt werden, was neue Türen für serverseitige Applications, eingebettete Systeme und Edge-Computing öffnet. Darüber hinaus wird WebAssembly um eine begrenzte zusätzliche Laufzeitunterstützung erweitert, insbesondere um die Garbage Collection. Es ist jedoch unwahrscheinlich, dass wir in WebAssembly die gesamte Bandbreite der Laufzeitunterstützung sehen werden, die die JVM bietet.

Die JVM funktioniert nur mit ihrer Sprachenfamilie – Java, Kotlin, Scala und einigen mehr –, die alle bewusst für die Ausführung auf der JVM konzipiert sind. Obwohl das Java-Ökosystem über umfangreiche Bibliotheken und Frameworks verfügt, besteht Interoperabilität nur zwischen diesen JVM-Sprachen. JVM-basierte Applications können nativen Code aufrufen, allerdings nicht ohne großen Aufwand und Sorgfalt.

WebAssembly wurde nicht dafür konzipiert, nur eine Programmiersprache zu unterstützen oder einen bestimmten Sprachstil zu bevorzugen, sei es funktional, mit Garbage Collection oder interpretiert. Jede Sprache – Rust, JavaScript, Python, C++ – kann so kompiliert werden, dass sie auf einer Wasm-Laufzeitumgebung ausgeführt werden kann. Das bedeutet zwar nicht, dass Code aus all diesen Sprachen bereits jetzt miteinander kommunizieren kann, doch durch den aufkommenden Component Model- Standard können Entwickler mehrere in unterschiedlichen Sprachen geschriebene Wasm-Module nahtlos miteinander verbinden. Bald werden Verknüpfung und Interoperabilität für WebAssembly eine Selbstverständlichkeit sein.

Wann haben Sie das letzte Mal gehört, dass jemand die JVM in eine Application eingebettet hat, um Plug-Ins oder benutzerdefinierte Logik auszuführen? Nicht vor Kurzem, wenn überhaupt, oder? Obwohl die JVM leistungsstark ist, ist es bekanntermaßen schwierig, sie in andere Applications einzubetten. Es gab einige Einbettungen mit hohem Bekanntheitsgrad (wie etwa Java-Applets in Browsern), aber sie sind größtenteils verschwunden, weil sie zu schwerfällig oder zu warten waren.

WebAssembly hingegen ist auf Einbettung ausgelegt. Das Einbetten einer Wasm-Laufzeit in eine Application ist oft so einfach wie das Einfügen einer neuen Bibliothek. Sobald dies erledigt ist, kann Ihre Application Wasm-Code ausführen – dies kann die Erweiterung einer Spiel-Engine, die Änderung eines Algorithmus, die Reaktion auf ein Ereignis oder alles andere sein, was Sie sich vorstellen können. Wasm bietet eine Vielseitigkeit bei der Einbettung, die die JVM nicht bieten kann (oder möchte).

Dies ist wohl der Bereich, in dem WebAssembly am hellsten glänzt. Die JVM verfügt über ein eigenes Sicherheitsmodell, wurde jedoch unter der Annahme entwickelt, dass der ausgeführte Code vertrauenswürdig ist. WebAssembly lehnt diese Prämisse grundsätzlich ab. Wasm wurde im Browser entwickelt, wo beim Besuch einer Website zwangsläufig nicht vertrauenswürdiger Code heruntergeladen und ausgeführt wird. Dagegen verwendet Wasm ein striktes, standardmäßig verweigertes Sandbox-Modell. Es gewährt dem Code keinen Zugriff auf Systemressourcen, Speicher oder andere Funktionen, sofern dies nicht ausdrücklich autorisiert wurde. Dieser Ansatz minimiert von Natur aus Angriffsflächen und macht Wasm ideal für Umgebungen, in denen die Ausführung nicht vertrauenswürdigen Codes ein Problem darstellt.

Das Sicherheitsmodell der JVM ist funktionsfähig, wurde jedoch nicht für das Sicherheitsniveau entwickelt, das Wasm bietet.

Die JVM ist ein erfahrener Veteran in der Tech-Welt. Es kann auf eine jahrzehntelange Geschichte zurückblicken und wird durch eine enorme Akzeptanz, umfassende Tools für Unternehmen und eine so große Community gestützt, dass es sich wie eine unerschütterliche Kraft in der Softwareentwicklung anfühlt. Wir wissen, dass es nicht so schnell verschwinden wird. Wenn Langlebigkeit und bewährte Stabilität für Ihre Anwendungsfälle entscheidend sind, ist die JVM die richtige Wahl.

WebAssembly ist unterdessen noch der Neuling auf dem Markt. Obwohl Wasm noch recht jung ist und gerade seinen 10. Geburtstag feiert, wächst die Begeisterung für das Projekt exponentiell. Obwohl WebAssembly heute weniger ausgereift ist als die JVM, lässt seine Entwicklung eine rosige Zukunft erwarten.

Sowohl WebAssembly als auch die JVM sind unglaubliche Technologien, die jeweils auf eine Weise brillieren, die zu ihren Umgebungen und Anwendungsfällen passt. Die JVM eignet sich hervorragend für Unternehmens-Workflows, bei denen es auf vollwertige Applications und umfangreiche Laufzeitfunktionen ankommt. Andererseits machen die Einbettungsfähigkeit, die schlanke Laufzeit, die sprachübergreifende Kompatibilität und die beispiellose Sicherheit von Wasm es zu einer überzeugenden Wahl für Plug-ins und Edge-Computing.

Also, was sollten Sie wählen? Wenn Sie eigenständige Applications mit robusten Laufzeitanforderungen entwickeln, bleibt die JVM eine praktische und bewährte Wahl. Wenn Sie jedoch sprachübergreifende Flexibilität oder die Möglichkeit zur problemlosen Einbindung in vorhandene Apps wünschen, könnte WebAssembly den Ausschlag geben.