Zuerst klären, welche Entscheidung überhaupt ansteht
Ein .NET-Backend lässt sich mit allen vier Optionen verbinden. Für ein browserbasiertes Frontend zählen dabei vor allem die Schnittstellen, die Anmeldung und das Berechtigungsmodell. Die Programmiersprache des Backends schreibt kein bestimmtes UI-Framework vor.
Vor einer Auswahl würde ich deshalb drei Fragen beantworten: Gibt es bereits einen funktionierenden Frontend-Stack? Welche Kenntnisse sind im Team tatsächlich verfügbar? Und welche Teile der Anwendung brauchen Interaktivität im Browser?
Wer nur einzelne Ansichten einer bestehenden Anwendung interaktiver machen möchte, hat eine andere Aufgabe als ein Team, das ein neues Kundenportal entwickelt. Für einfache, überwiegend serverseitig gerenderte Seiten können auch Razor Pages genügen. Wo eine interaktive Oberfläche gebraucht wird, gehört Blazor für ein .NET-Team gleichberechtigt neben Vue, Angular und React auf die Auswahlliste.
Eine vorhandene, gut gepflegte Lösung erhält dabei einen deutlichen Vertrauensvorschuss. Für einen Wechsel würde ich einen konkreten Nutzen verlangen, der Einarbeitung, Migration und parallele Pflege rechtfertigt.
Vue: wenn ein schrittweiser Einstieg wichtig ist
Vue lässt sich sowohl für einzelne interaktive Bereiche als auch für vollständige Anwendungen einsetzen. In seinen Single-File Components stehen Template, Logik und Styles zusammen. Diese Einsatzformen beschreibt die Vue-Dokumentation.
Für ein Team, das viel mit HTML und serverseitigen Templates arbeitet, würde ich Vue deshalb früh prüfen. Die Darstellung kann zunächst vertraut wirken. Ob daraus wirklich ein leichterer Einstieg entsteht, sollte das Team an einer eigenen Maske ausprobieren.
Auch mit Vue bleiben Architekturentscheidungen offen: Wo liegt gemeinsam genutzter Zustand? Wie werden API-Fehler behandelt? Welche Formular- und UI-Bausteine gelten als Standard? Ich würde diese Fragen für ein neues Projekt früh festhalten, damit nicht jede Funktion ihre eigene Lösung erhält.
Vue wäre für mich besonders interessant, wenn eine überschaubare Mannschaft eine gewachsene Oberfläche schrittweise erneuert. Für größere Anwendungen würde ich zusätzlich prüfen, wie gut sich gemeinsame Regeln über mehrere Beteiligte hinweg durchsetzen lassen.
Angular: wenn gemeinsame Vorgaben Arbeit sparen
Angular bringt einen breiteren Rahmen mit, unter anderem für Routing, Formulare und Dependency Injection. Die offizielle Übersicht beschreibt diese zusammengehörenden Werkzeuge.
Das kann hilfreich sein, wenn mehrere Entwickler an vielen ähnlichen Fachmasken arbeiten und einheitliche Abläufe brauchen. Begriffe wie Services und Dependency Injection sind einem .NET-Team möglicherweise vertraut. Browserzustand, Rendering und asynchrone Abläufe müssen trotzdem verstanden werden.
Ich würde Angular besonders dann prüfen, wenn das Team bewusst gemeinsame Vorgaben möchte und Zeit für den Einstieg einplant. Zur Entscheidung gehört auch die Wartung: Angular veröffentlicht einen Release- und Supportplan. Das Team sollte festlegen, wer Updates verfolgt und die Anwendung samt ergänzenden Bibliotheken prüft.
Eine feste Struktur kann Abstimmungen reduzieren. Ob dieser Vorteil die Einarbeitung rechtfertigt, hängt von der Anwendung und den Menschen ab, die sie betreuen.
React: wenn das Team einen konkreten Stack tragen kann
Bei React würde ich immer nachfragen, was genau zur Auswahl steht. Die offizielle Dokumentation empfiehlt für neue Anwendungen einen Start mit einem Framework. Ein eigener Aufbau, etwa mit Vite, ist ebenfalls möglich; dann müssen Lösungen für Routing und Datenzugriff bewusst ergänzt werden. Die Anleitung zum eigenen Aufbau erläutert diese Verantwortung.
Für den Vergleich sollte deshalb ein konkretes Paket auf dem Tisch liegen: React mit den vorgesehenen Werkzeugen für Navigation, Formulare, Datenzugriff und Tests.
React wäre für mich ein starker Kandidat, wenn das Team damit bereits sicher arbeitet oder benötigte Komponenten in diesem Umfeld gut abgedeckt sind. Entscheidend ist, dass jemand die Auswahl der Bausteine verantwortet und gemeinsame Muster pflegt. Ein gutes bestehendes React-Team würde ich nicht wegen des .NET-Backends auf einen anderen Stack umstellen.
Ebenso wenig würde ich React allein deshalb auswählen, weil sich für fast jede Aufgabe mehrere Bibliotheken finden lassen. Jede zusätzliche Auswahl erzeugt auch Pflegearbeit.
Blazor: wenn das Team auf C# aufbauen möchte
Blazor ermöglicht UI-Komponenten mit C# und Razor. Geeignete Modelle und Validierungslogik können zwischen Client und Server geteilt werden. Für ein C#-Team kann das Sprachwechsel und doppelte Implementierungen reduzieren. Microsoft beschreibt diese Möglichkeiten in der Blazor-Übersicht.
Der Vorteil ist für mich besonders relevant, wenn dieselben Menschen Backend und Fachoberfläche betreuen. HTML, CSS, Barrierefreiheit und Browserkenntnisse bleiben Teil der Arbeit. Benötigte Tabellen, Editoren oder Diagramme würde ich früh auf Bedienbarkeit, Lizenzkosten und Erweiterbarkeit prüfen. Für bestimmte Browserfunktionen oder vorhandene JavaScript-Bibliotheken kann JavaScript-Interop nötig sein.
Das Interaktivitätsmodell gehört zur Auswahl
Bei einer Blazor Web App lässt sich bestimmen, wie Komponenten gerendert werden: statisch auf dem Server, interaktiv auf dem Server, interaktiv per WebAssembly im Browser oder mit Interactive Auto. Statisches Rendering allein liefert keine interaktiven Blazor-Ereignisse. Interactive Auto nutzt zunächst Serverinteraktivität und bei späteren Besuchen nach dem Download die Ausführung im Browser. Es wechselt eine laufende Komponente nicht einfach bei einem Verbindungsabbruch. Die Render-Modi-Dokumentation erklärt diese Unterschiede.
Interaktiv auf dem Server: Die UI-Logik bleibt serverseitig. Latenz, Verbindungsabbrüche und Ressourcen für die Benutzersitzungen gehören deshalb in den Praxistest.
Interaktiv im Browser: WebAssembly verlagert die Ausführung zum Client. Dafür zählen Download, Startzeit und Leistungsfähigkeit der Endgeräte. Backend-Zugriffe benötigen weiterhin eine Verbindung; Offline-Fähigkeit entsteht nicht automatisch. Microsoft erläutert die zugrunde liegenden Abwägungen bei den Hosting-Modellen.
Ich würde Blazor früh prüfen, wenn C# die klare Stärke des Teams ist und passende UI-Komponenten vorhanden sind. Bei wechselhaften Verbindungen, hohen Anforderungen an den ersten Seitenaufruf oder umfangreichen JavaScript-Integrationen muss der Test zeigen, ob der Vorteil im Entwicklungsalltag auch im Betrieb trägt.
TypeScript entscheidet den Vergleich nicht allein
TypeScript ist kein Alleinstellungsmerkmal von Angular. Auch Vue und React dokumentieren den Einsatz ausdrücklich: Vue mit TypeScript, React mit TypeScript.
Für das Team würde ich daher konkreter werden: Sind die API-Verträge nachvollziehbar? Wie werden Änderungen daran bemerkt? Wer prüft, ob Frontend und Backend weiterhin zusammenpassen? Eine vertraute Typnotation beantwortet diese Fragen noch nicht. Auch gemeinsam verwendete C#-Modelle in Blazor ersetzen keine verbindlichen Schnittstellen und serverseitigen Prüfungen.
Die .NET-Anbindung im Vergleich mitprüfen
Bei einem Fachportal würde ich drei Punkte unabhängig vom Framework festlegen.
Berechtigungen: Die Oberfläche kann Aktionen passend zur Rolle anzeigen. Der Server muss die Zugriffsentscheidung trotzdem selbst durchsetzen. Angular weist bei seinen Route Guards ausdrücklich auf diese Grenze hin. Für das .NET-Backend bietet ASP.NET Core unter anderem rollen- und richtlinienbasierte Autorisierung.
Daten- und API-Verträge: Datumswerte, fehlende Werte, Validierungsfehler und konkurrierende Änderungen brauchen vereinbarte Regeln. Wenn zwei Personen denselben Datensatz bearbeiten, sollte das Team vorher entscheiden, was beim zweiten Speichern passieren soll. Dieses Verhalten gehört in den Vergleich der Kandidaten. Serverseitige Blazor-Komponenten können Anwendungsdienste auch direkt aufrufen; eine zusätzliche HTTP-API ist dafür nicht zwingend erforderlich. Die fachlichen Regeln gelten in beiden Fällen.
Bereitstellung: Wo liegen die Frontend-Dateien? Wie laufen Anmeldung und Weiterleitungen in der Zielumgebung? Müssen Frontend und Backend gemeinsam veröffentlicht werden? Wer findet einen Fehler über beide Seiten hinweg? Ich würde diese Fragen bereits am ersten durchgängigen Ablauf prüfen.
Ein Praxistest mit einer echten Fachaufgabe
Als hypothetisches Beispiel eignet sich eine Auftragsmaske: Aufträge filtern, einen Datensatz öffnen, eine Änderung speichern und eine fachliche Ablehnung verständlich anzeigen. Dazu kommen eine abgelaufene Sitzung und eine Aktion, für die der Benutzer keine Berechtigung hat.
Ich würde höchstens zwei verbleibende Kandidaten mit denselben fachlichen Funktionen, Testdaten und Anforderungen vergleichen. Erforderliche Anmeldung, Schnittstellenzugang und Komponentenlizenzen müssen vorher geklärt sein. Die Dauer richtet sich nach diesen Voraussetzungen; eine pauschale Stundenangabe wäre wenig belastbar.
Vor dem Start sollte klar sein, woran das Team die Ergebnisse beurteilt:
- Kann eine zweite Person ein Feld ergänzen und die Änderung testen?
- Sind Ladezustände, Validierungsfehler und fehlende Berechtigungen verständlich gelöst?
- Lassen sich die wichtigen Abläufe auch mit der Tastatur bedienen?
- Funktioniert der Ablauf in der vorgesehenen Betriebsumgebung?
- Ist erkennbar, welche Bibliotheken und Konventionen dauerhaft gepflegt werden müssen?
Erst nach einer solchen Änderung durch eine zweite Person würde ich die Verständlichkeit bewerten. Eine Demo zeigt zunächst vor allem, wie gut ihr Autor die eigene Lösung kennt.
Welche Option ich zuerst prüfen würde
Meine Reihenfolge wäre von der Ausgangslage abhängig:
Bestehender Stack: zuerst den Wechsel begründen
Ausgangslage: Eine gepflegte Lösung und ein erfahrenes Team sind bereits vorhanden.
Erster Prüfkandidat: Die bestehende Lösung.
Entscheidende Frage: Welches konkrete Problem rechtfertigt Einarbeitung, Migration und parallele Pflege?
Vue: schrittweise modernisieren
Ausgangslage: Das Team kennt HTML und Templates und möchte eine gewachsene Oberfläche schrittweise erneuern.
Erster Prüfkandidat: Vue.
Entscheidende Frage: Trägt der Ansatz auch bei komplexeren Formularen, gemeinsamem Zustand und Tests?
Angular: gemeinsame Vorgaben etablieren
Ausgangslage: Viele Fachmasken und mehrere Entwickler sollen nach einheitlichen Regeln arbeiten.
Erster Prüfkandidat: Angular.
Entscheidende Frage: Kann das Team die Einarbeitung und die laufende Pflege des gewählten Stacks tragen?
React: vorhandene Erfahrung nutzen
Ausgangslage: Das Team arbeitet bereits sicher mit React oder verfügt über passende Komponenten.
Erster Prüfkandidat: React mit einem klar festgelegten Stack.
Entscheidende Frage: Wer verantwortet die Bibliotheksauswahl und die gemeinsamen Entwicklungsmuster?
Blazor: .NET-Kenntnisse einbeziehen
Ausgangslage: Das Team hat seinen Schwerpunkt in C# und .NET und möchte darauf bei der UI-Entwicklung aufbauen.
Erster Prüfkandidat: Blazor mit einem zur Anwendung passenden Rendering- und Interaktivitätsmodell.
Entscheidende Frage: Passen dieses Modell und die verfügbaren UI-Komponenten zu den Anforderungen an Nutzung und Betrieb?
Das ist eine Reihenfolge für die Prüfung, keine Größenklassifizierung der Frameworks. Alle vier können anspruchsvolle Anwendungen tragen. Für die Entscheidung zählt, mit welchem vollständigen Stack das konkrete Team seine Aufgaben verlässlich bearbeiten kann.
Steht bei euch eine Frontend-Entscheidung an?
Ich unterstütze Unternehmen dabei, moderne Web-Oberflächen mit bestehenden .NET-Systemen zu verbinden. Im kostenlosen Erstgespräch können wir die Anforderungen einordnen und festlegen, welcher Ausschnitt sich für eine belastbare Entscheidung eignet.