Wenn aufmerksame Entwickler zum ersten Mal auf WebAssembly (kurz Wasm) stoßen, stellt sich häufig die Frage: Worin unterscheidet sich WebAssembly von der Java Virtual Machine (JVM)? Das ist eine ausgezeichnete Frage – schließlich beruhen beide Technologien auf demselben grundlegenden Versprechen: einem portablen Bytecode nach dem Prinzip „einmal schreiben, überall ausführen“. Obwohl sie auf einer gemeinsamen Grundlage aufbauen, unterscheiden sich ihre Ansätze und Ziele erheblich. Ein genauerer Blick auf diese Unterschiede zeigt, warum beide weiterhin als eigenständige, wichtige Projekte mit jeweils eigenen Ökosystemen bestehen.
Konzeptionelle Unterschiede
Im Kern wurden sowohl die JVM als auch WebAssembly dafür entwickelt, kompilierten Code praktisch überall auszuführen – bei der JVM bedeutete dies auf Rechnern mit unterschiedlichen Betriebssystemen oder CPU-Architekturen, was zu ihrer Zeit beispiellos war, und bei WebAssembly in jedem Webbrowser auf jedem beliebigen Computer, und zwar für alle Zeiten.
Die JVM, die Mitte der 1990er-Jahre zusammen mit Java eingeführt wurde, entwickelte sich zu einer vollwertigen Plattform mit umfassender Laufzeitunterstützung – darunter Garbage Collection, umfangreiche Standardbibliotheken und Werkzeuge für die verwaltete Ausführung. Allerdings könnte man sagen, dass die JVM dadurch erheblichen Ballast mit sich bringt: einen hohen Speicherbedarf und längere Startzeiten. Trotz ihrer enormen Leistungsfähigkeit eignet sich die JVM daher weniger für schlanke Anwendungen.
Im Gegensatz dazu wurde WebAssembly speziell für das Web konzipiert – genauer gesagt für die Ausführung von Code in Browsern. Daher wurde bei der Architektur besonderer Wert auf eine schlanke Laufzeitumgebung und blitzschnelle Startzeiten gelegt, allerdings ohne die umfangreiche Laufzeitunterstützung. Wäre Wasm ausschließlich auf Browser ausgerichtet, wäre es weniger portabel als Java-Bytecode. Heute können eigenständige Wasm-Laufzeitumgebungen jedoch auch außerhalb des Webs ausgeführt werden, was neue Möglichkeiten für serverseitige Anwendungen, eingebettete Systeme und Edge-Computing eröffnet. Darüber hinaus erhält WebAssembly in begrenztem Umfang zusätzliche Laufzeitunterstützung, insbesondere eine automatische Speicherbereinigung. Es ist jedoch unwahrscheinlich, dass WebAssembly jemals die gesamte Bandbreite der Laufzeitunterstützung bieten wird, die die JVM bereitstellt.
Interoperabilität
Die JVM funktioniert nur mit ihrer eigenen Sprachfamilie – Java, Kotlin, Scala und einigen weiteren –, die allesamt gezielt für die Ausführung auf der JVM entwickelt wurden. Das Java-Ökosystem bietet zwar umfangreiche Bibliotheken und Frameworks, Interoperabilität ist jedoch nur zwischen diesen JVM-Sprachen möglich. JVM-basierte Anwendungen können nativen Code aufrufen, allerdings nur mit erheblichem Aufwand und großer Sorgfalt.
WebAssembly wurde nicht dafür entwickelt, nur eine einzige Programmiersprache zu unterstützen oder einen bestimmten Sprachstil zu bevorzugen – unabhängig davon, ob dieser funktional, speicherbereinigt oder interpretiert ist. Jede Sprache – Rust, JavaScript, Python, C++ – kann so kompiliert werden, dass sie in einer Wasm-Laufzeitumgebung ausgeführt wird. Das bedeutet zwar nicht, dass Code aus all diesen Sprachen bereits jetzt miteinander kommunizieren kann, doch dank des aufkommenden Komponentenmodells-Standards können Entwickler mehrere, in unterschiedlichen Sprachen geschriebene Wasm-Module nahtlos miteinander verbinden. Schon bald werden Verknüpfung und Interoperabilität bei WebAssembly selbstverständlich sein.
Einbettbarkeit
Wann haben Sie zuletzt davon gehört, dass jemand die JVM in eine Anwendung eingebettet hat, um Plug-ins oder benutzerdefinierte Logik auszuführen? Das ist schon eine Weile her – wenn es überhaupt je der Fall war, oder? Die JVM ist zwar leistungsfähig, lässt sich aber bekanntermaßen nur schwer in andere Anwendungen einbetten. Es gab einige prominente Beispiele dafür, etwa Java-Applets in Browsern, doch aufgrund ihrer Umständlichkeit und des hohen Wartungsaufwands sind sie weitgehend verschwunden.
WebAssembly hingegen ist für die Einbettung konzipiert. Eine Wasm-Laufzeitumgebung in eine Anwendung einzubetten, ist oft so einfach wie das Einbinden einer neuen Bibliothek. Anschließend kann Ihre Anwendung Wasm-Code ausführen – etwa um eine Spiele-Engine zu erweitern, einen Algorithmus anzupassen, auf ein Ereignis zu reagieren oder alles andere umzusetzen, was Sie sich vorstellen können. Wasm bietet bei der Einbettung eine Vielseitigkeit, die die JVM nicht bieten kann (und im Übrigen auch gar nicht bieten will).
Sicherheit
Hier spielt WebAssembly wohl seine größten Stärken aus. Die JVM verfügt zwar über ein eigenes Sicherheitsmodell, dieses wurde jedoch unter der Annahme entwickelt, dass der ausgeführte Code vertrauenswürdig ist. WebAssembly verwirft diese Prämisse grundsätzlich: Wasm hat seinen Ursprung im Browser, wo beim Besuch einer Website zwangsläufig nicht vertrauenswürdiger Code heruntergeladen und ausgeführt wird, und setzt daher auf ein striktes Sandbox-Modell, das standardmäßig jeglichen Zugriff verweigert. Code erhält keinen Zugriff auf Systemressourcen, Speicher oder andere Funktionen, sofern dies nicht ausdrücklich autorisiert wurde. Dieser Ansatz minimiert von vornherein die Angriffsfläche und macht Wasm ideal für Umgebungen, in denen die Ausführung nicht vertrauenswürdigen Codes ein Sicherheitsrisiko darstellt.
Das Sicherheitsmodell der JVM ist zwar funktional, wurde aber schlicht nicht für das Sicherheitsniveau konzipiert, das Wasm bietet.
Reifegrad und Community
Die JVM ist ein altgedienter Veteran in der Technologiewelt. Dank ihrer jahrzehntelangen Geschichte kann sie auf eine enorme Verbreitung, umfangreiche Enterprise-Tools und eine so große Community zählen, dass sie wie eine unerschütterliche Größe in der Softwareentwicklung wirkt – wir wissen, dass sie so schnell nicht verschwinden wird. Wenn Langlebigkeit und bewährte Stabilität für Ihre Anwendungsfälle entscheidend sind, ist die JVM die richtige Wahl.
WebAssembly hingegen ist noch immer der Neuling. Obwohl es noch jung ist und kurz vor seinem 10. Geburtstag steht, wächst die Begeisterung für Wasm exponentiell. WebAssembly ist heute zwar noch weniger ausgereift als die JVM, doch seine Entwicklung deutet auf eine vielversprechende Zukunft hin.
Fazit
Sowohl WebAssembly als auch die JVM sind beeindruckende Technologien, die jeweils in den für ihre Umgebungen und Anwendungsfälle relevanten Bereichen ihre Stärken ausspielen. Die JVM eignet sich hervorragend für Unternehmensworkflows, bei denen vollwertige Anwendungen und umfangreiche Laufzeitfunktionen gefragt sind. Wasm hingegen ist dank seiner Einbettbarkeit, schlanken Laufzeitumgebung, sprachübergreifenden Kompatibilität und beispiellosen Sicherheit eine überzeugende Wahl für Plug-ins und Edge Computing.
Wofür sollten Sie sich also entscheiden? Wenn Sie eigenständige Anwendungen mit hohen Anforderungen an die Laufzeitumgebung entwickeln, bleibt die JVM eine praktische und bewährte Wahl. Wenn Sie jedoch sprachübergreifende Flexibilität wünschen oder sich mühelos in bestehende Anwendungen integrieren möchten, könnte WebAssembly den Ausschlag geben.
Über den Autor
Ähnliche Blogbeiträge
Ein umfassender Leitfaden zur Bereitstellung und Sicherheit von KI-Anwendungen
Entdecken Sie optimale Strategien für die Absicherung und Bereitstellung von KI-Anwendungen.
KI zulassen und einführen? Lehren aus der Public Cloud
Die Einführung von KI steht unmittelbar bevor und könnte entscheidend sein, um wettbewerbsfähig zu bleiben. Daher muss die IT-Sicherheit proaktiv handeln und der KI-Einführung schon jetzt einen Schritt voraus sein, um sie auf einen risikogerechten Weg zu lenken.
Stand der Anwendungsstrategie 2022: Zeit für die Modernisierung des Betriebs
Es ist deutlich geworden, dass Unternehmen ihren Fokus erneut auf die Geschäftsfunktionen richten müssen, um die Dynamik ihrer digitalen Transformation aufrechtzuerhalten. Kundenerlebnisse haben zwar weiterhin Priorität, doch auch Geschäftsfunktionen wie Recht, Personalwesen und Finanzen müssen digitalisiert werden. Das bedeutet, dass CIOs das Steuer übernehmen, während sich die digitale Transformation von der Modernisierung von Anwendungen hin zur Modernisierung von Betriebsabläufen verlagert.
F5s Weg zu einer vielseitigen Plattform für Anwendungsanalysen
F5 bietet heute die umfassendsten Anwendungsdienste entlang des gesamten Weges vom Code bis zum Kunden. Künftig werden wir verstärkt auf Anwendungstelemetrie und -analysen setzen, damit unsere Kunden wertvolle Erkenntnisse über ihre Anwendungen, Geschäftsabläufe und Benutzererlebnisse gewinnen können. Beim Ausbau unserer Cloud-Analysefunktionen werden wir ML und KI noch stärker nutzen, um unsere Kunden bei der Verbesserung ihrer Geschäftsdienste zu unterstützen.
Telemetrie: Eine andere Art von Daten
Verwenden wir den Begriff „Telemetrie“ nur, weil er attraktiver klingt als „Daten“? Letztlich sind sowohl Daten als auch Telemetrie strukturierte Informationseinheiten. Es ist kein Verbrechen, die Begriffe synonym zu verwenden. Doch wenn man es genau nimmt, gibt es einen Unterschied. Und dieser Unterschied wird immer wichtiger werden, je weiter Unternehmen in die Datenökonomie vordringen.
MTTR bedeutet nicht „Mean Time to Reboot“
„Schnell scheitern“ lautet heute das Mantra für mehr Geschwindigkeit. Ob in DevOps oder im Geschäftsleben: Wer in einer digitalen Wirtschaft agiert, muss eine möglichst perfekte Verfügbarkeit gewährleisten.