Agile, People & Culture
Architecture & Design
Clouds, Kubernetes & Serverless
Core Java & Languages
DevOps & CI/CD
Microservices
Performance & Security
Serverside Java
Web Development & JavaScript

Interview Blog

mit Christian Dedek und Thomas Huber

Christian Dedek und Thomas Huber
23. Mar 2020

Mit WebAssembly lassen sich Hochsprachen wie Java oder C# in ein neues Binärformat kompilieren, das direkt im Browser ausgeführt werden kann. Zum Entwickeln von Webapplikationen muss somit nicht ausschließlich JavaScript zum Einsatz kommen. Wir haben uns mit Christian Dedek (OIO) und Thomas Huber (Trivadis) über die Vor- und Nachteile sowie den aktuellen Stand von WebAssembly unterhalten.

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.

Stay tuned

Regelmäßig News zur Konferenz und der Java-Community erhalten

 

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.

SIE LIEBEN JAVA?

Den Core-Java-Track entdecken

 

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!

Top Articles About Blog

Alle News der Java-Welt:

Behind the Tracks

Agile, People & Culture
Teamwork & Methoden

Clouds & Kubernetes
Alles rund um Cloud

Core Java & Languages
Ausblicke & Best Practices

Data & Machine Learning
Speicherung, Processing & mehr

DevOps & CI/CD
Deployment, Docker & mehr

Microservices
Strukturen & Frameworks

Performance & Security
Sichere Webanwendungen

Serverside Java
Spring, JDK & mehr

Software-Architektur
Best Practices

Web & JavaScript
JS & Webtechnologien

Digital Transformation & Innovation
Technologien & Vorgehensweisen

Domain-driven Design
Grundlagen und Ausblick

Spring Ecosystem
Wissen in Spring-Technologien

Web-APIs
API-Technologie, Design und Management

ALLE NEWS ZUR JAX!