Angular im Frontend, eine REST-API dazwischen, Spring Boot im Backend. Das ist der Standard-Stack vieler Unternehmen, und für einen großen Teil interner Anwendungen ist er aufwendiger als nötig. Die Frage Vaadin oder Angular wird in der Praxis selten technisch entschieden. Sie wird meist über Gewohnheit entschieden, weil der Stack unternehmensweit vorgegeben ist. Das ist bequem, aber nicht immer die wirtschaftlichste Wahl.

Ein Beispiel aus einem realen Projekt. Eine Anwendung verwaltet große Mengen an Stamm- und Bewegungsdaten, mit Dutzenden Importen und Exporten in verschiedenen Formaten, faktisch eine Datendrehscheibe für andere Systeme. Die technische Vorgabe des Kunden lautete Angular, REST-API, Spring Boot, weil das der unternehmensweite Standard ist. Für genau diesen Anwendungstyp wäre die Wahl aus fachlicher Sicht eine andere gewesen.

Standard-Stacks werden aus Gewohnheit gewählt

Die Bewertung von Technologien hängt stark vom eigenen Erfahrungshorizont ab. Wer seit Jahren in einer Technologie routiniert ist, bevorzugt sie fast immer, solange es keine harten Gründe für etwas anderes gibt. Das ist menschlich und oft sogar sinnvoll, weil eingespielte Teams schneller liefern. Problematisch wird es erst, wenn Gewohnheit als technische Eignung ausgegeben wird.

Ein erfahrener Entwickler, der seit Jahren in beiden Welten arbeitet und ausdrücklich kein Vaadin-Verfechter ist, bringt es auf den Punkt: JavaScript-Frontends sind häufig ein erhebliches Gefrickel. Das heißt nicht, dass Angular schlecht ist. Es heißt, dass die Standardentscheidung selten hinterfragt wird, obwohl genau das die teureren Fehler verhindern würde.

Wann eine REST-API Mehrwert bringt und wann Overhead

Ein häufiges Argument für den klassischen Stack lautet: Eine REST-API ist eine saubere Trennung zwischen Frontend und Backend. Das stimmt. Die eigentliche Frage ist, ob diese Sauberkeit den Mehraufwand rechtfertigt.

Wertvoll wird eine REST-API dann, wenn es verschiedene Konsumenten gibt, etwa eine Web-App, eine native Mobile-App und Drittanwendungen als Schnittstellennutzer. In diesem Szenario ist sie den Aufwand wert. Gibt es dagegen nur einen einzigen Client, ist sie vor allem eins: technischer Overhead, der Zeit und Geld kostet, ohne einen erkennbaren Nutzen zu liefern.

Für datengetriebene interne Anwendungen mit genau einem Client bündelt Vaadin Frontend und Backend in Java. Ein Team, eine Sprache, ein Stack, ohne die Akrobatik zwischen REST-API und mehreren JavaScript-Frameworks. Das alte Gegenargument, Vaadin sei zu unflexibel für moderne Oberflächen, gilt heute nicht mehr. Responsive Anwendungen entstehen fast von selbst, spezielle optische Anforderungen setzt man über Web Components um. Formularwüsten sind kein Schicksal, sondern eine Designentscheidung.

Vaadin für interne Geschäftsanwendungen

Die Zahlen aus der Vaadin Community Survey 2026 stützen den Praxiseindruck. Verglichen mit klassischen Stacks aus mehreren Sprachen und Frameworks berichten die Befragten von rund 40 Prozent schnellerer Time to Market und etwa 30 Prozent niedrigeren Projektkosten. In eigenen Angeboten liegt Vaadin für den passenden Anwendungstyp oft etwa 30 Prozent unter Angular, React oder Vue mit vorgelagerter REST-API.

Bemerkenswert ist auch, wofür Vaadin genutzt wird. Rund zwei Drittel der Befragten setzen es für datengetriebene interne Geschäftsanwendungen ein, also für Datenpflege, Dashboards und Fachanwendungen. Das sind die Anwendungen, die das Tagesgeschäft tragen. Und genau dort sind viele Legacy-Anwendungen zu Hause, die als wichtig oder sogar geschäftskritisch gelten und noch Jahre betrieben werden sollen.

Der andere Migrationspfad: weg vom Application Server

Neben der Frontend-Frage stellt sich in vielen Häusern eine zweite. Manche Teams sind noch dabei, vom klassischen Application Server wegzukommen, während andere schon fragen, was nach Spring Boot kommt.

Migrationen von Weblogic, JBoss oder Wildfly hin zu Spring Boot führen regelmäßig zum gleichen Ergebnis: schlankere Architektur, produktivere Teams, deutlich weniger Betriebskomplexität. Und regelmäßig zur gleichen Erkenntnis danach. Der Schmerz war nicht die Migration selbst, sondern die Zeit davor auf einem in die Jahre gekommenen Stack. Alternativen wie Quarkus oder Micronaut sind inzwischen produktionsreif und für sehr spezifische Anforderungen an Startzeit oder Skalierung die richtige Wahl. Für die meisten bleibt Spring Boot der solide Standard.

Die dringendere Frage ist ohnehin eine andere: Wie lange lohnt es sich noch, auf einem Application Server zu bleiben? Lizenzkosten, wachsende Betriebskomplexität und der zunehmende Abstand zu modernen Deployment-Praktiken beantworten sie meistens von selbst.

Drei Fragen vor der Stack-Entscheidung

Bevor ein Standard-Stack vorgeschrieben wird, helfen drei Fragen bei einer ehrlichen Einschätzung.

Erstens: Was sind die Anforderungen der Anwendung, und wer sind die Konsumenten? Ein einziger Client rechtfertigt selten den Aufwand einer separaten API.

Zweitens: Braucht die Oberfläche jeden Pixel exakt, oder reicht eine saubere, funktionale Arbeitsoberfläche? Für interne Fachanwendungen ist Letzteres der Normalfall.

Drittens: Wurden Aufwandsschätzungen für mehrere Stacks verglichen? Erst der Vergleich macht sichtbar, wo tatsächlich Kosten entstehen, statt sie in einem gewohnten Stack zu verstecken.

Fazit

Die richtige Antwort auf Vaadin oder Angular lautet: Es kommt auf die Anforderung an. Standard-Stacks aus Gewohnheit kosten dort Geld, wo eine einfachere Architektur denselben Zweck erfüllt. Für datengetriebene interne Anwendungen und für die Modernisierung geschäftskritischer Legacy-Systeme ist Vaadin häufig die wirtschaftlichere Wahl. Technologie sollte man nach Projekt wählen, nicht nach Trend.