Ein unerwartet problemloses Upgrade

Der Ausgangspunkt für diesen Artikel war kein strategischer Architektur‑Workshop und kein langfristig geplanter Migrationspfad, sondern ein vergleichsweise unspektakulärer Schritt: die Aktualisierung der Versionsnummern im bestehenden Projekt. Im Rahmen der Weiterentwicklung meines URL‑Shortener‑Projekts stand ohnehin ein reguläres Dependency‑Update an. Vaadin 25 ( https://3g3.eu/vdn25 ) war zu diesem Zeitpunkt bereits verfügbar – also lag es nahe, den Schritt einfach zu gehen.

Die Quelltexte zu dem Projekt befinden sich

auf GitHub unter https://3g3.eu/url

Die Erwartungshaltung war dabei realistisch, vielleicht sogar leicht skeptisch. Ein neues Major‑Release, neue Mindestanforderungen, ein modernisierter Stack – all das sind üblicherweise gute Gründe, zumindest mit kleineren Anpassungen oder ersten Reibungen zu rechnen. Entsprechend gering war die Hoffnung, dass ein einfaches Hochziehen der Versionsnummern tatsächlich ausreichen könnte.

Genau das war jedoch der Fall. Nach der Anpassung der Vaadin‑Version sowie der ohnehin bereits aktuellen Java‑ und Plattformabhängigkeiten ließ sich das Projekt ohne weitere Änderungen bauen, starten und bedienen. Die Anwendung verhielt sich wie zuvor: Views wurden korrekt gerendert, Dialoge funktionierten, Styles waren intakt, und auch komplexere UI‑Flows zeigten keinerlei Auffälligkeiten.

Dieses Ergebnis war insofern bemerkenswert, als dass es nicht auf einem trivialen Demo‑Projekt beruhte. Der URL‑Shortener ist eine gewachsene Anwendung mit klarer Modulstruktur, serverseitiger UI‑Logik, Sicherheitsmechanismen und einer kleinen Anzahl an UI‑Komponenten. Dass ein Major‑Upgrade unter diesen Bedingungen ohne unmittelbare Nacharbeit möglich war, ist keine Selbstverständlichkeit.

Gerade diese Erfahrung war der Auslöser für eine genauere Betrachtung von Vaadin 25. Wenn ein Framework‑Upgrade dieser Größenordnung auf Anhieb funktioniert, stellt sich zwangsläufig die Frage nach den Gründen. Welche Entscheidungen im Unterbau machen das möglich? Wo wurde bewusst auf Stabilität gesetzt? Und an welchen Stellen lauern die Änderungen, die erst bei genauerem Hinsehen relevant werden?

Warum Vaadin 25 mehr als ein Versionssprung ist

Vaadin 25 markiert keinen klassischen Evolutionsschritt mit einer Sammlung neuer Widgets oder API‑Erweiterungen, sondern eine bewusste Neuausrichtung des Frameworks. Während frühere Major‑Releases häufig durch zusätzliche Features oder inkrementelle Verbesserungen geprägt waren, steht bei Vaadin 25 die Konsolidierung im Vordergrund: weniger Sonderlogik, weniger historische Altlasten und eine stärkere Annäherung an etablierte Standards der modernen Java‑ und Web‑Entwicklung.

Diese Neuausrichtung ist eine direkte Reaktion auf die Realität vieler produktiver Enterprise‑Anwendungen. Lang laufende Web‑UIs müssen heute nicht nur funktional sein, sondern über Jahre hinweg wartbar, sicher und gut integrierbar bleiben. Genau an dieser Stelle setzt Vaadin 25 an. Das Framework versteht sich weniger als abgeschottetes Ökosystem mit eigenen Regeln, sondern stärker als integraler Bestandteil eines zeitgemäßen Java‑Stacks.

Ein zentrales Signal dafür ist die klare Festlegung auf moderne Plattformen. Mit Java 21 als Mindestanforderung und der Ausrichtung auf aktuelle Jakarta‑ und Spring‑Versionen positioniert sich Vaadin bewusst dort, wo sich auch der restliche Enterprise‑Java‑Stack bewegt. Ältere Kompatibilitätsversprechen werden aufgegeben, um stattdessen einen sauberen, konsistenten technologischen Unterbau zu schaffen.

Auch auf konzeptioneller Ebene ist Vaadin 25 ein Einschnitt. Viele Mechanismen, die in der Vergangenheit als Vaadin‑typische Abkürzungen galten, werden hinterfragt oder vereinfacht. Styling folgt stärker klassischen CSS‑Prinzipien, Build‑Prozesse nähern sich dem Standard‑Java‑Workflow an und der Client‑Side‑Code wird schlanker und transparenter. Das Ergebnis ist ein Framework, das weniger erklärt werden muss und sich besser in bestehende Entwicklungs‑ und Betriebsprozesse einfügt.

Vaadin 25 ist damit kein Release, das primär durch sichtbare Neuerungen im UI glänzt. Sein Mehrwert liegt in der langfristigen Perspektive: stabilere Grundlagen, geringere Komplexität und bessere Anschlussfähigkeit an moderne Java‑Architekturen. Für Entwickler und Architekten bedeutet das vor allem eines: Entscheidungen für oder gegen Vaadin lassen sich künftig klarer entlang technischer Kriterien treffen – und weniger entlang von Framework‑Spezifika.

Der neue Mindeststandard: Java 21, Jakarta EE und moderne Plattformen

Mit Vaadin 25 zieht das Framework eine klare Linie und definiert einen neuen technologischen Mindeststandard. Diese Entscheidung ist bewusst getroffen und richtet sich an Projekte, die langfristig betrieben werden sollen und sich an aktuellen Java‑Plattformen orientieren. Rückwärtskompatibilität um jeden Preis wird zugunsten von Klarheit, Konsistenz und Wartbarkeit aufgegeben.

Im Zentrum steht Java 21 als verbindliche Basis. Damit setzt Vaadin auf eine aktuelle LTS‑Version, die sowohl sprachliche als auch laufzeitseitige Verbesserungen mitbringt. Für Vaadin‑Anwendungen bedeutet das nicht nur Zugriff auf moderne Sprachkonstrukte, sondern vor allem einen einheitlichen Nenner über UI‑Code, Backend‑Logik und Tests hinweg. Die Zeiten, in denen UI‑Code aus Kompatibilitätsgründen auf einem älteren Sprachlevel verharrte, sind damit vorbei.

Eng damit verknüpft ist die Ausrichtung auf aktuelle Jakarta‑Standards. Vaadin 25 basiert auf Jakarta EE 11 und Servlet 6.1 und verabschiedet sich endgültig von historischen javax‑Abhängigkeiten. Diese Umstellung mag auf den ersten Blick wie ein rein technisches Detail wirken, hat in der Praxis jedoch spürbare Auswirkungen: Bibliotheken, Container und Security‑Mechanismen folgen nun einem konsistenten Namensraum und lassen sich deutlich sauberer integrieren. Gerade in sicherheitsrelevanten Anwendungen reduziert dies Reibungsverluste und Fehlkonfigurationen.

Auch im Spring‑Umfeld wird diese Linie konsequent fortgeführt. Vaadin 25 ist auf Spring Boot 4 und Spring Framework 7 ausgerichtet und verzichtet auf Unterstützung älterer Generationen. Damit entfällt ein erheblicher Teil an Kompatibilitätscode, der in früheren Versionen notwendig war. Gleichzeitig rücken Vaadin‑Anwendungen näher an den Mainstream‑Spring‑Stack heran, was Betrieb, Monitoring und Security‑Integration vereinfacht.

Der neue Mindeststandard wirkt sich ebenfalls auf den gesamten Build‑ und Toolchain‑Bereich aus. Moderne Maven‑ und Gradle‑Plugins, aktuelle Node‑Versionen für den Frontend‑Teil sowie klarere Trennung zwischen Entwicklungs‑ und Produktionsartefakten sorgen dafür, dass sich Vaadin‑Projekte stärker wie klassische Java‑Anwendungen anfühlen. Sonderprofile und projektspezifische Workarounds verlieren an Bedeutung.

Wichtig ist dabei die Perspektive: Vaadin 25 verlangt mehr Disziplin beim Einstieg, senkt aber langfristig die Komplexität. Projekte, die den Sprung auf Java 21 und aktuelle Plattformen ohnehin planen oder bereits vollzogen haben, profitieren unmittelbar. Für ältere Anwendungen bedeutet das Upgrade hingegen eine bewusste strategische Entscheidung – mit initialem Aufwand, aber einer deutlich stabileren Basis für die kommenden Jahre.

Schlankerer Stack, schnellere Builds und weniger Ballast

Einer der spürbarsten Effekte von Vaadin 25 zeigt sich nicht unmittelbar im UI, sondern im Unterbau des Projekts. Das Framework wurde in dieser Version gezielt entschlackt: transitive Abhängigkeiten wurden reduziert, historische Kompatibilitätsschichten entfernt und Build‑Prozesse vereinfacht. Das Ergebnis ist ein Stack, der sich deutlich näher an einer klassischen Java‑Serveranwendung orientiert.

In früheren Vaadin‑Versionen war es nicht unüblich, dass Projekte eine beträchtliche Menge an indirekten Abhängigkeiten mit sich führten. Viele davon waren notwendig, um unterschiedliche Plattformstände, alte Browser‑Strategien oder alternative Betriebsmodi zu unterstützen. Mit Vaadin 25 entfällt ein Großteil dieses Ballasts. Die Abhängigkeiten sind klarer strukturiert, transparenter nachvollziehbar und insgesamt überschaubarer.

Diese Reduktion wirkt sich unmittelbar auf den Build‑Prozess aus. Sowohl Maven‑ als auch Gradle‑Builds profitieren von kürzeren Auflösungszeiten und weniger Sonderkonfiguration. Insbesondere der Unterschied zwischen Entwicklungs‑ und Produktionsbuilds ist geringer geworden. Vaadin‑Anwendungen verhalten sich hier deutlich stärker wie gewöhnliche Java‑Artefakte, was den Einstieg für neue Entwickler erleichtert und CI‑Pipelines vereinfacht.

Auch die Startzeiten im Entwicklungsmodus profitieren von diesem Ansatz. Weniger Initialisierungscode, klarere Trennung zwischen Server‑ und Client‑Anteilen sowie modernisierte Frontend‑Abhängigkeiten führen zu einem schnelleren Feedback‑Loop. Gerade in größeren Projekten, in denen häufige Neustarts zum Alltag gehören, ist dies ein nicht zu unterschätzender Produktivitätsgewinn.

Ein weiterer Aspekt ist der Ressourcenverbrauch im Betrieb. Ein schlankerer Stack bedeutet nicht automatisch minimale Speicherbelegung, reduziert jedoch unnötige Last. Weniger Bibliotheken bedeuten weniger Klassen, weniger potenzielle Konflikte und eine kleinere Angriffsfläche. Für produktive Umgebungen – insbesondere in sicherheitskritischen oder stark regulierten Kontexten – ist dies ein klarer Vorteil.

Wichtig ist dabei die Abgrenzung: Vaadin 25 versucht nicht, ein Minimal‑Framework zu sein. Vielmehr geht es um bewusste Reduktion. Alles, was nicht mehr zwingend notwendig ist, wird entfernt oder vereinfacht. Diese Haltung zieht sich durch den gesamten Stack und ist eine direkte Fortsetzung der in den vorherigen Kapiteln beschriebenen Neupositionierung.

Der schlankere Stack bildet damit eine wesentliche Grundlage für die weiteren Neuerungen in Vaadin 25. Vereinfachtes Styling, stabilere UI‑Mechanismen und klarere Migrationspfade sind nur möglich, weil das Framework sich von über Jahre gewachsenen Altlasten löst.

Styling & Theming neu gedacht: CSS statt Sonderlogik

Das Styling‑Modell gehört zu den Bereichen, in denen sich Vaadin 25 am deutlichsten von früheren Versionen absetzt. Während Vaadin lange Zeit eigene Konzepte und Abstraktionen rund um Themes, Variants und Style‑Hooks mitbrachte, verfolgt Version 25 einen klaren Kurs: CSS wird als gleichwertiger, direkter Gestaltungsmechanismus verstanden – ohne unnötige Framework‑Sonderwege.

Diese Entscheidung ist weniger kosmetisch als vielmehr architektonisch. In vielen Projekten führte das bisherige Styling‑Modell dazu, dass UI‑Anpassungen tiefes Vaadin‑Spezialwissen erforderten. Gleichzeitig ließ sich vorhandenes Web‑Know‑how nur eingeschränkt nutzen. Vaadin 25 reduziert diese Reibung gezielt, indem es Styling näher an etablierte Web‑Standards heranführt und damit verständlicher und wartbarer macht.

Ein sichtbares Ergebnis dieses Ansatzes ist das neue Default‑Theme Aura. Es ersetzt Lumo nicht, sondern setzt einen anderen Schwerpunkt. Aura wirkt ruhiger, moderner und weniger verspielt, ohne sich in den Vordergrund zu drängen. Für produktive Anwendungen bedeutet das: ein konsistentes Erscheinungsbild ohne umfangreiche Anpassungen. Lumo bleibt weiterhin verfügbar und eignet sich insbesondere für Projekte, die bereits stark darauf aufbauen oder bewusst ein anderes visuelles Profil verfolgen.

Neben der optischen Basis ist vor allem die Flexibilität entscheidend. Vaadin 25 ermöglicht es, Themes dynamisch zu wechseln – etwa abhängig von Benutzerrollen, Mandanten oder Umgebungen. Light‑ und Dark‑Varianten lassen sich ohne tiefgreifende Umbauten realisieren. Diese Fähigkeit ist nicht neu, lässt sich jedoch mit dem vereinfachten Styling‑Modell deutlich sauberer und nachvollziehbarer umsetzen.

Bewusst entfernt wurde das Material‑Theme. Diese Entscheidung unterstreicht den neuen Fokus: Statt mehrere parallel gepflegte Designsprachen anzubieten, konzentriert sich Vaadin auf wenige, gut integrierte Basisthemen. Für Projekte, die eine stark individualisierte Oberfläche benötigen, ist dies kein Nachteil. Im Gegenteil – durch den stärkeren CSS‑Fokus lassen sich eigene Designsysteme konsistenter und framework‑unabhängiger umsetzen.

Wichtig ist auch die Auswirkung auf die Zusammenarbeit im Team. Designer und Frontend‑affine Entwickler können mit Vaadin 25 deutlich direkter arbeiten, ohne sich in Vaadin‑spezifische Styling‑Konzepte einarbeiten zu müssen. Gleichzeitig behalten Java‑Entwickler die volle Kontrolle über Struktur und Verhalten der UI.

Vorher und Nachher: Styling in der Praxis

Um den Unterschied greifbar zu machen, lohnt sich ein direkter Blick auf typische Styling‑Ansätze vor und nach Vaadin 25. Die Beispiele sind bewusst vereinfacht, zeigen aber sehr deutlich den Paradigmenwechsel.

Beispiel 1: Button‑Styling

Vorher (klassischer Vaadin‑Ansatz mit Theme‑Varianten und Java‑Hooks):

Button save = new Button("Speichern");
save.addThemeVariants(ButtonVariant.LUMO_PRIMARY);
save.getStyle().set("background-color", "var(--lumo-success-color)");
save.getStyle().set("color", "white");

Das Styling ist hier teilweise im Java‑Code verankert. Farben und visuelle Details werden über Vaadin‑spezifische Variablen und APIs gesteuert, was die Trennung von Struktur und Darstellung verwischt.

Nachher (Vaadin 25, CSS‑first):

Button save = new Button("Speichern");
save.addClassName("btn-save");

.btn-save {
  background-color: var(--vaadin-color-success);
  color: white;
}

Die Verantwortung ist klar getrennt: Java beschreibt die Struktur und Semantik, CSS übernimmt das visuelle Erscheinungsbild. Das Styling ist leicht auffindbar, testbar und unabhängig vom Java‑Code anpassbar.

Beispiel 2: Layout‑Abstände und Konsistenz

Vorher (Inline‑Styles im Code):

VerticalLayout layout = new VerticalLayout();
layout.getStyle().set("padding", "var(--lumo-space-m)");
layout.getStyle().set("gap", "var(--lumo-space-s)");

Solche Konstrukte sind funktional, führen aber schnell zu verstreutem Styling‑Wissen im Code.

Nachher (CSS‑basierte Layout‑Klassen):

VerticalLayout layout = new VerticalLayout();
layout.addClassName("content-layout");
.content-layout {
  padding: 1rem;
  gap: 0.5rem;
}

Abstände und Layout‑Regeln sind nun zentral definiert und lassen sich projektweit konsistent anpassen.

Beispiel 3: Dark‑/Light‑Theme ohne Speziallogik

Vorher (Vaadin‑spezifische Theme‑Schalter):

UI.getCurrent().getElement().setAttribute("theme", "dark");

Nachher (Vaadin 25, CSS‑orientiert):

UI.getCurrent().getElement().getClassList().add("theme-dark");

.theme-dark {
  --vaadin-color-background: #1e1e1e;
  --vaadin-color-text: #f5f5f5;
}

Der Wechsel des Themes ist nun ein klar nachvollziehbarer CSS‑Mechanismus und lässt sich problemlos mit bestehenden Designsystemen oder Benutzerpräferenzen kombinieren.

Diese Beispiele verdeutlichen den Kern der Änderung: Vaadin 25 verlagert Styling‑Entscheidungen konsequent dorthin, wo sie hingehören. Der Code wird übersichtlicher, das Styling flexibler und die Zusammenarbeit zwischen Backend‑, Frontend‑ und Design‑Rollen deutlich entspannter.

Komponenten- und Rendering-Verbesserungen im Alltag

Während viele Änderungen in Vaadin 25 eher struktureller Natur sind, zeigen sich die Verbesserungen bei Komponenten und Rendering sehr konkret im täglichen Arbeiten mit der UI. Insbesondere Dialoge, Overlays, Menüs und andere schwebende UI‑Elemente profitieren von einer überarbeiteten Architektur, die auf Konsistenz, Vorhersagbarkeit und Stabilität ausgelegt ist.

In früheren Vaadin‑Versionen waren Probleme mit Überlagerungen, Fokusverlust oder unerwartetem Z‑Index‑Verhalten keine Seltenheit – vor allem in komplexeren Anwendungen mit verschachtelten Dialogen oder dynamisch nachgeladenen Komponenten. Solche Effekte ließen sich meist beheben, erforderten jedoch zusätzliche Logik, Workarounds oder ein tiefes Verständnis interner Vaadin‑Mechanismen.

Vaadin 25 setzt hier auf ein vereinheitlichtes Overlay‑Modell. Dialoge, Kontextmenüs, Tooltips und ähnliche Komponenten folgen nun einer gemeinsamen Rendering‑Strategie. Dadurch werden sie konsistenter positioniert, reagieren stabiler auf Größenänderungen und verhalten sich vorhersehbarer im Zusammenspiel miteinander. Für Entwickler bedeutet das weniger Überraschungen und weniger Sonderbehandlung im Code.

Ein besonders relevanter Aspekt ist das Fokus‑Management. Tastaturnavigation, Fokus‑Rückgabe nach dem Schließen eines Dialogs und die Interaktion mehrerer Overlays gleichzeitig funktionieren in Vaadin 25 deutlich robuster. Das verbessert nicht nur die Benutzererfahrung, sondern wirkt sich auch positiv auf Barrierefreiheit und Testbarkeit aus.

Auch das Zusammenspiel mit modernen Layouts profitiert von der neuen Rendering‑Logik. Overlays passen sich besser an Viewport‑Änderungen an, reagieren sauber auf Scroll‑Container und behalten ihre Position auch bei dynamischen UI‑Updates. Gerade bei datengetriebenen Anwendungen mit vielen Interaktionen reduziert dies visuelle Artefakte und Inkonsistenzen.

Wichtig ist dabei, dass diese Verbesserungen kaum neue APIs erfordern. Bestehender Code profitiert häufig bereits durch das Upgrade selbst. Gleichzeitig werden bisher notwendige Schutzmaßnahmen oder Hilfskonstrukte überflüssig, was den Code vereinfacht und besser lesbar macht.

Vorher und Nachher: Rendering- und Overlay-Verhalten in der Praxis

Die Unterschiede zwischen früheren Vaadin-Versionen und Vaadin 25 werden besonders deutlich, wenn man typische UI-Situationen betrachtet, die in realen Anwendungen regelmäßig auftreten.

Beispiel 1: Verschachtelte Dialoge

Vorher (klassischer Ansatz mit potenziellen Überlagerungsproblemen):

Dialog editDialog = new Dialog();
editDialog.add(new TextField("Name"));
Dialog confirmDialog = new Dialog();
confirmDialog.add(new Span("Änderungen speichern?"));
Button save = new Button("Speichern", e -> confirmDialog.open());
editDialog.add(save);
editDialog.open();

In komplexeren Layouts konnte es hier vorkommen, dass der zweite Dialog nicht korrekt über dem ersten lag oder Fokus und Tastaturnavigation verloren gingen.

Nachher (Vaadin 25, konsistentes Overlay-Modell):

Dialog editDialog = new Dialog();
editDialog.setModal(true);
Dialog confirmDialog = new Dialog();
confirmDialog.setModal(true);
Button save = new Button("Speichern", e -> confirmDialog.open());
editDialog.add(save);
editDialog.open();

Durch das vereinheitlichte Overlay-Rendering werden Dialoge zuverlässig gestapelt, Fokus wird korrekt weitergereicht und nach dem Schließen wiederhergestellt – ohne zusätzliche Hilfskonstrukte.

Beispiel 2: Fokus-Rückgabe nach Dialog-Schließung

Vorher (manuelle Fokus-Korrektur notwendig):

Button openDialog = new Button("Bearbeiten");
Dialog dialog = new Dialog();
dialog.addDialogCloseActionListener(e -> openDialog.focus());
openDialog.addClickListener(e -> dialog.open());

Solche Muster waren notwendig, um eine saubere Tastaturnavigation sicherzustellen.

Nachher (Vaadin 25, automatisches Fokus-Management):

Button openDialog = new Button("Bearbeiten");
Dialog dialog = new Dialog();
openDialog.addClickListener(e -> dialog.open());

Vaadin 25 übernimmt die Fokus-Rückgabe zuverlässig selbst. Der Code wird kürzer, verständlicher und weniger fehleranfällig.

Beispiel 3: Overlay über Grid und Scroll-Container

Vorher (unerwartete Positionierung bei Scroll-Containern):

Grid<Item> grid = new Grid<>(Item.class);
ContextMenu menu = new ContextMenu(grid);
menu.addItem("Details", e -> showDetails());

Je nach Layout und Scroll-Verhalten konnte das Kontextmenü versetzt oder abgeschnitten erscheinen.

Nachher (Vaadin 25, stabilere Positionierung):

Grid<Item> grid = new Grid<>(Item.class);
ContextMenu menu = new ContextMenu(grid);
menu.setOpenOnClick(true);
menu.addItem("Details", e -> showDetails());

Das neue Rendering-Modell berücksichtigt Scroll-Container und Viewport-Änderungen konsistenter, sodass Overlays dort erscheinen, wo der Benutzer sie erwartet.

Diese Beispiele zeigen, dass Vaadin 25 viele UI-Probleme nicht durch neue APIs löst, sondern durch eine robustere interne Architektur. Für bestehende Anwendungen bedeutet das oft: weniger Code, weniger Workarounds und eine UI, die sich auch in Grenzfällen stabil verhält.

Element-API, SVG und MathML: Technische UIs direkt aus Java

Mit Vaadin 25 gewinnt ein Bereich an Bedeutung, der in vielen Projekten bislang nur eine Nebenrolle spielte: die direkte Arbeit mit der Element‑API. Durch die native Unterstützung von SVG und MathML erweitert sich der Gestaltungsspielraum deutlich – insbesondere für technische, datengetriebene Benutzeroberflächen, bei denen klassische UI‑Komponenten an ihre Grenzen stoßen.

Bislang waren solche Anforderungen häufig der Punkt, an dem zusätzliche JavaScript‑Bibliotheken oder externe Frontend‑Frameworks ins Spiel kamen. Diagramme, Statusgrafiken oder mathematische Darstellungen ließen sich zwar integrieren, führten jedoch zu Medienbrüchen im Code und erhöhtem Integrationsaufwand. Vaadin 25 reduziert diese Notwendigkeit spürbar, indem es diese Technologien als vollwertige Elemente im serverseitigen UI‑Modell verfügbar macht.

Die Element‑API erlaubt es, strukturierte DOM‑Elemente direkt aus Java zu erzeugen und zu manipulieren. Mit der Erweiterung um SVG können nun auch grafische Primitive wie Linien, Kreise oder Pfade serverseitig modelliert werden. Damit lassen sich beispielsweise einfache Diagramme, Statusanzeigen oder visuelle Marker erzeugen, ohne das Vaadin‑Komponentenmodell zu verlassen.

Ein ähnlicher Effekt zeigt sich bei MathML. Technische Anwendungen, die Formeln oder Berechnungsergebnisse darstellen müssen, profitieren davon, dass mathematische Ausdrücke semantisch korrekt beschrieben werden können. Die Darstellung ist dabei nicht nur visuell präziser, sondern auch besser zugänglich – etwa für Screenreader oder automatisierte Tests.

Der entscheidende Punkt ist weniger die technische Machbarkeit als vielmehr die architektonische Konsequenz. Durch die Integration von SVG und MathML in die Element‑API bleiben UI‑Logik, Rendering und Datenfluss unter Kontrolle des Java‑Backends. Es entsteht kein zusätzlicher Client‑Side‑State, der synchronisiert oder abgesichert werden muss. Gerade in sicherheitskritischen oder stark regulierten Umgebungen ist dies ein nicht zu unterschätzender Vorteil.

Natürlich ersetzt dieser Ansatz keine spezialisierten Charting‑Libraries oder komplexe Visualisierungstools. Vaadin 25 positioniert die Element‑API bewusst als Werkzeug für gezielte, kontrollierte Visualisierungen. Dort, wo es um klare Zustände, technische Informationen oder erklärende Grafiken geht, ist dieser Ansatz oft robuster und wartbarer als eine externe Abhängigkeit.

Kapitel 6 zeigt damit eine weitere Facette der Neuausrichtung von Vaadin 25. Das Framework erweitert seine Möglichkeiten nicht durch zusätzliche Abstraktionen, sondern durch den direkten Zugang zu etablierten Web‑Standards. Für Entwickler bedeutet das: mehr Ausdruckskraft, weniger Integrationsaufwand und eine UI, die auch jenseits klassischer Formular‑ und Tabellenansichten sauber modelliert werden kann.

Vorher und Nachher: Technische Visualisierung mit und ohne Element‑API

Die Vorteile der erweiterten Element‑API lassen sich besonders gut anhand konkreter Beispiele nachvollziehen. Die folgenden Szenarien sind typisch für technische Anwendungen und zeigen den Unterschied zwischen klassischen Integrationsansätzen und der Vaadin‑25‑Lösung.

Beispiel 1: Statusindikator als SVG

Vorher (externe JavaScript‑Library oder Client‑Side‑Snippet):

Div status = new Div();
status.getElement().setProperty("innerHTML",
  "<svg width='20' height='20'><circle cx='10' cy='10' r='8' fill='green'/></svg>");

Der SVG‑Code wird hier als String eingebettet. Struktur, Semantik und Typprüfung gehen verloren, und Änderungen sind fehleranfällig.

Nachher (Vaadin 25, SVG über Element‑API):

Element svg = new Element("svg");
svg.setAttribute("width", "20");
svg.setAttribute("height", "20");
Element circle = new Element("circle");
circle.setAttribute("cx", "10");
circle.setAttribute("cy", "10");
circle.setAttribute("r", "8");
circle.setAttribute("fill", "green");
svg.appendChild(circle);
getElement().appendChild(svg);

Das SVG ist nun ein vollständig modelliertes DOM‑Element. Änderungen lassen sich gezielt vornehmen, und die Struktur bleibt nachvollziehbar und testbar.

Beispiel 2: Einfaches Balkendiagramm

Vorher (Übergabe von Daten an Client‑Side‑Code):

JsonObject data = Json.createObject();
data.put("value", 75);
ui.getPage().executeJs("renderChart($0)", data);

Hier entsteht zusätzlicher Client‑Side‑State, der synchronisiert und abgesichert werden muss.

Nachher (Vaadin 25, serverseitig erzeugtes SVG):

int value = 75;
Element bar = new Element("rect");
bar.setAttribute("x", "0");
bar.setAttribute("y", "0");
bar.setAttribute("width", String.valueOf(value));
bar.setAttribute("height", "20");
bar.setAttribute("fill", "#4caf50");
Element svg = new Element("svg");
svg.setAttribute("width", "100");
svg.setAttribute("height", "20");
svg.appendChild(bar);
getElement().appendChild(svg);

Die Visualisierung folgt direkt dem Server‑State. Es gibt keine doppelte Logik und keinen versteckten Client‑Side‑Code.

Beispiel 3: Darstellung einer Formel mit MathML

Vorher (Text oder gerenderte Grafik):

Span formula = new Span("E = mc^2");

Die semantische Bedeutung der Formel geht verloren, ebenso wie Zugänglichkeit und maschinelle Auswertbarkeit.

Nachher (Vaadin 25, MathML):

Element math = new Element("math");
Element mrow = new Element("mrow");
mrow.appendChild(new Element("mi").setText("E"));
mrow.appendChild(new Element("mo").setText("="));
mrow.appendChild(new Element("mi").setText("m"));
mrow.appendChild(new Element("mo").setText("·"));
Element msup = new Element("msup");
msup.appendChild(new Element("mi").setText("c"));
msup.appendChild(new Element("mn").setText("2"));
mrow.appendChild(msup);
math.appendChild(mrow);
getElement().appendChild(math);

Die Formel ist nun semantisch korrekt beschrieben, zugänglich und klar strukturiert – direkt aus Java erzeugt.

Diese Beispiele machen deutlich, wie sich mit Vaadin 25 technische Visualisierungen ohne zusätzliche Frontend‑Abhängigkeiten umsetzen lassen. Die Element‑API wird damit zu einem gezielten Werkzeug für kontrollierte, serverseitige Darstellung – genau dort, wo klassische Komponenten nicht mehr ausreichen.

Fazit – Moderne Technik in einem stabilen Maschinenraum

Vaadin 25 fühlt sich weniger wie ein radikaler Neuanfang an, sondern eher wie die gründliche Überholung eines gut konstruierten Maschinenraums. Die äußere Form mag vertraut bleiben, doch im Inneren wurde aufgeräumt, vereinfacht und modernisiert. Genau das erklärt, warum ein Major-Upgrade in der Praxis so reibungslos funktionieren kann – selbst bei einer gewachsenen Anwendung.

Vaadin 25 setzt nicht auf kurzfristige Effekte oder spektakuläre Features, sondern auf nachvollziehbare Konstruktion. Moderne Plattformen, weniger Abhängigkeiten, klarere Zuständigkeiten und eine stärkere Orientierung an Standards bilden das Fundament. Das Ergebnis ist kein fragiles Uhrwerk, sondern ein belastbares System, das auch unter Dauerbetrieb stabil läuft.

Besonders überzeugend ist dabei die Konsequenz, mit der alte Kompatibilitätslasten abgelegt wurden. Java 21, aktuelle Jakarta-APIs, ein vereinfachtes Styling-Modell und ein schlankerer Build-Prozess sind keine kosmetischen Entscheidungen, sondern klare Architektur­aussagen. Sie erfordern Disziplin beim Einstieg, zahlen sich aber langfristig durch Wartbarkeit, Sicherheit und Planbarkeit aus.