Redaktion: WebAssembly macht es möglich, Hochsprachen wie Java oder C# direkt im Browser auszuführen. Wo liegen dabei die Vorteile im Vergleich zu JavaScript?
Mit WebAssembly ergeben sich alle Vorteile, welche Java gegenüber JavaScript hat.
Christian Dedek, Thomas Huber: Da man dank WebAssembly beispielsweise mit Java statt mit JavaScript programmieren kann, ergeben sich daraus alle Vorteile, welche Java gegenüber JavaScript hat, wie beispielsweise die statische Typisierung. Darüber hinaus ist WebAssembly als solches im Gegensatz zu JavaScript ein echtes Binärformat. WebAssembly ist daher sehr performant. Es kommt fast an die Geschwindigkeit von nativen Anwendungen heran.
Während JavaScript nur bedingt Just-in-Time-kompilierbar ist, ist WebAssembly hier deutlich besser geeignet, womit die Performance richtig gut ist. Mozilla beschreibt die Hintergründe, warum WebAssembly schneller als JavaScript ist, sehr gut im Blogpost A cartoon intro to WebAssembly.
Regelmäßig News zur Konferenz und der Java-Community erhalten Stay tuned
Redaktion: Manche sehen in WebAssembly eine Revolution für das Web. Seht Ihr das auch so? Welche „revolutionäre“ Veränderung für das Web könnte uns bevorstehen?
Christian Dedek, Thomas Huber: WebAssembly ist wohl eher eine Evolution als eine Revolution. Es ist nicht zur Ablösung von JavaScript gedacht, sondern öffnet den Browser einfach für weitere Plattformen.
Verschiedene existierende Ökosysteme und Entwicklergemeinden können den Browser als Plattform mit WebAssembly deutlich leichter erreichen. Sie müssen ihren bestehenden Code nicht in JavaScript neuschreiben, sondern können ihn nach WebAssembly kompilieren. Dies hat beispielsweise den Effekt, dass Bibliotheken, die eigentlich nie für den Browser bestimmt waren, jetzt dank WebAssembly plötzlich im Browser verfügbar sind.
Doch auch für die Migration bestehender Lösungen ins Web kann WebAssembly eine schrittweise Modernisierung erlauben, da bestehender Code im Browser weiterhin genutzt werden kann. Neben dem Browser kann WebAssembly auch eine Evolution auf dem Server darstellen. Mit WASI, was für WebAssembly System Interface steht, soll WebAssembly auf jedem OS ausgeführt werden können, womit es auch für serverseitigen Code spannend ist.
Schaut man auf die offizielle WebAssembly Seite, findet man dort auch den Hinweis, dass WebAssembly eine Rolle sowohl auf dem Client als auch auf dem Server spielen soll. Auf Englisch heißt es dort:
… enabling deployment on the web for client and server applications.
JWebAssembly und TeaVM
JAXenter: Ihr stellt in eurem JAX-Talk die Projekte JWebAssembly und TeaVM vor. Worum handelt es sich dabei?
Christian Dedek, Thomas Huber: Die Werkzeugunterstützung, um Java-Quellcode in WebAssembly kompilieren zu können, ist derzeit noch im Entstehen. Mit JWebAssembly (https://github.com/i-net-software/JWebAssembly) und TeaVM (https://github.com/konsoletyper/teavm) gibt es zwei bekanntere Compiler-Projekte, und wir wollen sie in unserem Talk als möglichen ersten praktischen WebAssembly-Einstieg für Java-Entwickler demonstrieren.
Interessant ist dabei zu bemerken, dass beide Projekte auf dem Java-Bytecode aufsetzen und nicht auf den Quellcodes. Insgesamt ist das Umfeld von WebAssembly momentan aber noch sehr dynamisch, was wir auch gerne an Beispielen aufzeigen wollen. Insofern sollen die genannten Projekte eben nur als Beispiele verstanden werden, und der interessierte Entwickler darf gerne nach Alternativen suchen.
Redaktion: Wie gut funktioniert eurer Erfahrung nach WebAssembly für Java schon? Was klappt gut – wo gibt’s noch Probleme?
Christian Dedek, Thomas Huber: Wer einen leichten Einstieg mit einfacher Integration in sein gewohntes Java-Werkzeugumfeld erwartet, der könnte enttäuscht werden. JWebAssembly und TeaVM sind bisher noch Projekte mit einer eher kleinen Community. Zudem haben die Projekte einige Limitationen.
Bestehender, komplexer Sourcecode von Bibliotheken oder von ganzen Systemen einfach mal mit JWebAssembly oder TeaVM nach WebAssembly zu kompilieren, wird nicht ohne Umstellungen der originalen Quellcodes bzw. ohne zusätzlichen „Kleber“-Code gelingen. Die Gründe dafür sind vielfältig und z.B. bereits in der WebAssembly Spezifikation angelegt.
Java mit vielen seiner Sprachfeatures stand in der initialen Spezifikation nicht im Fokus, und das macht sich bei der 1:1-Übersetzbarkeit bemerkbar. Wer allerdings bereit ist, sich auf ein paar neue Konzepte einzulassen und seine Java-Verwendung entsprechend anzupassen, der kann bereits einiges erreichen.
Die Zukunft ist durch WebAssembly deutlich spannender und hat auch für Java-Entwickler viel Potenzial.
JAXenter: Was ist die Kernbotschaft eurer Session, die jeder Besucher mit nach Hause nehmen sollte?
Christian Dedek, Thomas Huber: WebAssembly wird bereits von allen modernen Browsern unterstützt, und es ist ein W3C Standard. Als intermediäres, binäres Format bietet es sich für viele Anwendungsfälle der Zukunft des Webs und darüber hinaus an.
Diese Möglichkeiten und resultierende technische Architekturen können teilweise bereits jetzt erprobt und in ihren Auswirkungen diskutiert und berücksichtigt werden. Man muss aber bedenken, dass wir es momentan immer noch mit einem ‘minimal viable product’ zu tun haben, bei dem Vorhersagen der Zukunft von vielen Mitspielern abhängen.
In Spezifikationsgremien und in der Forschung wird intensiv an der Zukunft von WebAssembly gearbeitet. Verglichen mit anderen Sprachen und Entwicklungsökosystemen scheint Java momentan bei der konkreten Umsetzbarkeit für den Anwendungsentwickler gegenüber anderen Sprachen wie Rust, C# oder C/C++ etwas abgehängt zu sein. Microsoft hat aber mit ihrem WebAssembly-basierten SPA Framework Blazor gezeigt, was ein engagiertes Unternehmen mit einer technischen Vision in kurzer Zeit auf die Beine stellen kann. Hier kann hoffentlich in Java noch eine gleiche Entwicklung einsetzen. Die Zukunft ist durch WebAssembly deutlich spannender und hat auch für Java-Entwickler viel Potenzial.
Redaktion: Vielen Dank für dieses großartige Interview!
