Der WebAssembly-Standard steht in den meisten Browsern zur Verfügung und wird bereits in vielen Webanwendungen verwendet. Die Features und APIs sind aktuell zwar noch vergleichsweise rudimentär, die geplanten Erweiterungen der Spezifikation aber vielversprechend. Zudem gibt es einen Standardisierungsvorschlag, der die Verwendung von WebAssembly außerhalb des Browsers ermöglicht. Zeit für einen Ausblick.

Spotify, Zalando, DAZN: Alle tun es. Micro Frontends sind in der Industrie etabliert. Mittlerweile gibt es verschiedene Frameworks, die bei der Umsetzung dieses architektonischen Ansatzes für Web-Frontends verwendet werden können.

Der Entscheidungsprozess bei Web-Frontends ist häufig Framework-getrieben und betrachtet die architektonischen Implikationen nur am Rande. So ist es heute schon fast selbstverständlich, dass Webanwendungen als clientseitig gerenderte Single Page Applications (SPA) entwickelt werden. Die allgemeine Definition eines „modernen“ Frontends ist dabei nicht selten unmittelbar an die Auswahl eines konkreten Frameworks gebunden. Die Zeiten der eher klassischen, rein serverseitig getriebenen Ansätze (z. B. JSF) scheinen vorbei zu sein.

Im Web haben sich komponentenbasierte UI-Frameworks durchgesetzt. Alle heute relevanten Single Page Application Frameworks setzen vollständig oder mindestens zu großen Teilen auf dieses Paradigma. Mit Web Components existiert ein vielversprechender Standard, der die Erstellung Framework-unabhängiger Komponenten ermöglicht und so bereits heute für mehr Wiederverwendbarkeit im Web sorgen kann.

Während die Erstellung interaktiver Webanwendungen vor gar nicht allzu langer Zeit nur über Plug-ins wie Java-Applets, Flash oder Silverlight möglich waren, haben sich durch die stetige Verbesserung der Browser in den letzten Jahren rein JavaScript-basierte Anwendungen durchgesetzt. Dieser Siegeszug ist vornehmlich durch die native Einbettung der Sprache in die Browser zu begründen. Spätestens an den zahlreichen JavaScript-Sprachaufsätzen wie TypeScript oder Flow und Compile-to-JavaScript-Frameworks, beispielsweise GWT oder Vaadin, lässt sich aber unschwer erkennen, dass das alles andere als perfekt ist.

Webbrowser haben sich lange Zeit nicht gerade mit Ruhm bekleckert. Inkonsistente Implementierungen, schlechtes API-Design und vor allem das Fehlen wichtiger Funktionalitäten haben Entwicklern das Leben erschwert. So waren Webapplikationen ohne die Verwendung clientseitiger Bibliotheken lange völlig undenkbar. Zum Glück hat sich aber in den letzten Jahren nicht nur die JavaScript-, sondern vor allem auch die Browserwelt stark weiterentwickelt. Aktuelle Versionen liefern umfangreiche Toolsets für die Erstellung moderner und leistungsfähiger Webanwendungen. Außerdem stehen aufgrund kurzer Releasezyklen wichtige Updates und Features immer schneller zur Verfügung.

Die MVC-1.0-Spezifikation (aka JSR 371) hatte es bisher nicht gerade einfach. Ursprünglich war sie als Teil von Java EE 8 geplant, um eine leichtgewichtige Alternative zum komponentenbasierten JSF-Framework zu bieten. Im Zuge der von Oracle geplanten Neuausrichtung der Java-Enterprise-Plattform auf Cloud-Computing wurde die Spezifikation aber wieder entfernt.

Mit Single-Page Applications lassen sich performante Webanwendungen entwickeln. Bei wachsender Projektgröße kann es aber zu Geschwindigkeitseinbußen kommen. Was kann man tun, wenn eine SPA langsam wird?

Bislang ist mit JDBC in Java nur ein synchrones und blockierendes Datenbank-API spezifiziert. Seit einiger Zeit gibt es aber konkrete Pläne für ein zusätzliches, asynchrones API. Welche Vorteile hat diese Alternative, und wie wird sie aussehen?

Single-Page Applications (SPAs) entwickeln sich zu einem festen Bestandteil der Anwendungslandschaft in Unternehmen. Die hohe Dynamik in der Welt der Web-Frontends erweist sich aber immer wieder als ein großer Unsicherheitsfaktor. Stellt sich doch die Frage: Kann man SPAs überhaupt zukunftssicher gestalten?

Der Kern von objektorientierter Programmierung ist die Kapselung von Daten und den darauf operierenden Methoden. Das macht Objektorientierung zu einem guten Kandidaten, um Businesslogik zu implementieren, da diese ja in der Regel eine Verknüpfung von Daten und Operationen darstellt. Richtig angewendet, lassen sich sehr gut lesbare und wartungsfreundliche Businessanwendungen mit objektorientierter Programmierung schreiben.

Zugegebenermaßen kann der Einstieg in die Single-Page-Welt verwirrend sein. Noch vor der ersten Zeile Code müssen verschiedene Tools installiert und unzählige Eingaben in der Kommandozeile getätigt werden. Zwar bieten viele Single-Page-Frameworks mittlerweile Werkzeuge (Angular CLI oder Create React App), mit deren Hilfe sich Projekte größtenteils automatisiert erstellen und konfigurieren lassen. Trotzdem bleibt bei Neulingen oft ein fader Beigeschmack: Braucht man das wirklich alles? Früher musste man doch nur jQuery herunterladen …

Immer mehr Webanwendungen werden heutzutage als Single Page Application (SPA) umgesetzt. Langsam aber sicher manifestiert sich dieser Trend auch im Enterprise-Umfeld. Dabei stellt sich hier die Frage, ob und vor allem wie eine klassische Webanwendung zu einer SPA migriert werden kann.

Noch vor wenigen Jahren von vielen Enterprise-Entwicklern als Unheil bringendes Voodoo abgetan, gewinnt JavaScript in modernen Webanwendungen mehr und mehr an Bedeutung. Entsprechend groß ist auch der Zoo an wunderverheißenden Frameworks, aus denen es das passende zu wählen gilt. Wie so oft im Leben gilt leider auch hier: „Wer die Wahl hat, hat die Qual“.

Die wartbare Integration von JavaScript in serverseitig getriebene Webanwendungen stellt eine große Herausforderung dar. Dazu existiert bisher kein standardisierter Weg. Bislang greifen viele auf Inline-Scripting zurück, was oft zu Nachteilen führt. Dieser Artikel zeigt, wie JavaScript und JSF sauber zusammengeführt werden können.