Blog

Erstellen moderner Webanwendungen mit Blazor

Niels Nijveldt

Aktualisiert Oktober 15, 2025
12 Minuten

Wenn Sie mit der Entwicklung einer neuen Frontend-Anwendung beginnen, werden meist Frameworks wie Angular, React und Vue bevorzugt. Das ist verständlich, denn diese Frameworks gibt es schon seit langem und sie haben sich bewährt. Außerdem werden sie von einer starken Gemeinschaft unterstützt. Letztes Jahr hat Microsoft jedoch das größte Upgrade für Blazor seit seiner Veröffentlichung im Jahr 2018 veröffentlicht. Mit diesem Upgrade hat Microsoft gezeigt, dass Blazor nicht mehr wegzudenken ist und eine sehr geeignete Option neben den bekannten JavaScript-Frameworks darstellt. In diesem Artikel erfahren Sie alles über das Blazor-Upgrade.

In Magazin #13 haben wir über die Grundlagen von Blazor geschrieben, und in Magazin #14 haben wir darüber geschrieben, wie Sie vorhandenen C#-Code mit Blazor nutzen können. Die Grundsätze dieser Artikel gelten auch heute noch, und ich empfehle Ihnen, beide Artikel zu lesen. Im November 2023 erhielt ASP.NET, und damit auch Blazor, mit .NET 8 ein bedeutendes Upgrade. Während Blazor Server und Blazor WebAssembly in den älteren Versionen von .NET hervorragend funktionierten, haben beide Hosting-Modelle Vor- und Nachteile. Es kann schwierig sein zu entscheiden, welches Hosting-Modell für Sie am besten geeignet ist. Da sich die Hosting-Modelle erheblich unterscheiden und es nicht einfach ist, später von einem zum anderen zu wechseln, müssen Sie eine gute Wahl treffen.

Blazor Server

Profis

  • Serverseitige Verarbeitung: Die Komponenten der App werden auf dem Server gerendert, der die Vorteile der Serverfunktionen nutzen kann, einschließlich der leistungsstarken Verarbeitung und des Zugriffs auf Serverressourcen.
  • Geringere Download-Größe: Da die App auf dem Server verarbeitet wird, lädt der Client nur die Benutzeroberfläche der App herunter, was zu kürzeren anfänglichen Ladezeiten als bei Blazor WebAssembly führt.
  • Vollständige .NET-Laufzeitunterstützung: Es hat Zugriff auf die vollen Fähigkeiten der .NET-Laufzeitumgebung auf dem Server, so dass Sie alle .NET-Bibliotheken ohne Kompatibilitätsprobleme verwenden können.
  • Vereinfachtes Deployment: Da die Anwendungslogik auf dem Server ausgeführt wird, kann die Bereitstellung unkomplizierter erfolgen, da keine statischen Dateien für die clientseitige Logik erforderlich sind.

Nachteile

  • Latenz: Benutzerinteraktionen erfordern einen Hin- und Rückweg zum Server, was zu spürbaren Verzögerungen führt, insbesondere wenn der Benutzer geografisch weit vom Server entfernt ist oder eine langsame Internetverbindung hat.
  • Skalierbarkeit: Da jeder Client eine ständige Verbindung zum Server unterhält, kann es zu Skalierbarkeitsproblemen kommen, wenn die Anzahl der Benutzer steigt und mehr Serverressourcen benötigt werden.
  • Serverlast: Der Server trägt die Rechenlast der Anwendung, was die Hostingkosten erhöhen kann und bei komplexen Anwendungen oder hohem Benutzeraufkommen eine leistungsfähigere Serverhardware erfordert.
  • Abhängigkeit von der Internetverbindung: Die App benötigt eine ständige Internetverbindung, um zu funktionieren. Daher ist sie für Offline-Szenarien oder Umgebungen mit unzuverlässiger Verbindung weniger geeignet.
  • Zustand: Alle Benutzerinteraktionen werden an den Server gesendet, um zu bestimmen, wie die Benutzeroberfläche für den Client gerendert werden soll. Der Status geht verloren, wenn der Server abstürzt oder heruntergefahren wird. Dies führt zu einem Verlust des Fortschritts für den Benutzer.

Blazor Web Montage

Profis

  • Client-seitige Ausführung: Wird mit WebAssembly direkt im Browser ausgeführt und ermöglicht so vollständig clientseitige Anwendungen, die die Verarbeitungsleistung des Clients nutzen können.
  • Offline-Fähigkeiten: Kann offline arbeiten, sobald es geladen ist. Dadurch eignet es sich für Anwendungen, die ohne ständige Internetverbindung funktionieren müssen.
  • Geringere Serverlast: Die Verarbeitung wird auf den Client verlagert, wodurch die Rechenlast des Servers verringert und die Hosting-Kosten gesenkt werden können.
  • Konsistente Leistung: Sobald die Anwendung geladen ist, kann sie eine konsistentere Leistung bieten, ohne die Latenz, die mit Server-Roundtrips für UI-Aktualisierungen verbunden ist.

Nachteile

  • Anfängliche Ladezeit: Das Herunterladen der .NET-Laufzeit und des Anwendungscodes ist erforderlich, bevor die Anwendung ausgeführt werden kann, was zu längeren anfänglichen Ladezeiten als bei herkömmlichen Webanwendungen oder Blazor Server-Anwendungen führt.
  • Browser-Kompatibilität: Moderne Browser unterstützen zwar WebAssembly, aber Inkonsistenzen oder Einschränkungen in älteren Browsern oder bestimmten Umgebungen können die Funktionalität oder Leistung der App beeinträchtigen.
  • Begrenzter Zugriff auf Server-Funktionen: Der direkte Zugriff auf Server-Ressourcen und -Funktionen ist eingeschränkter und erfordert APIs oder andere Mechanismen, um mit serverseitigen Prozessen oder Daten zu interagieren.
  • SEO-Herausforderungen: Suchmaschinen können Schwierigkeiten haben, Inhalte zu indizieren, die clientseitig gerendert werden, obwohl Fortschritte bei den Suchmaschinentechnologien und Pre-Rendering-Techniken dieses Problem abmildern können.
  • Ressourcenintensiv: Dies kann die Hardware des Clients stärker beanspruchen, insbesondere bei komplexen Anwendungen, was bei älteren oder weniger leistungsfähigen Geräten zu Leistungsproblemen führen kann.

 

Um die Auswahl einfacher und weniger "dauerhaft" zu machen, hat Microsoft das Konzept der Rendermodi entwickelt. Rendermodi ähneln den Hosting-Modellen, nur dass Rendermodi auf Seiten und Komponenten beschränkt sind, während die Hosting-Modelle auf die gesamte Anwendung beschränkt sind. Mit dem .NET 8 Upgrade können Sie innerhalb Ihrer Anwendung verschiedene Rendermodi verwenden, um das Beste aus allen Rendermodi mit ein paar zusätzlichen Funktionen zu erhalten und eine moderne Webanwendung zu erstellen. Wenn Sie möchten, können Sie jedoch weiterhin Blazor Server oder Blazor WebAssembly nur für die gesamte Anwendung verwenden. Wenn Sie Ihre Anwendung zum Beispiel als statische Webanwendung bereitstellen möchten, müssen Sie die Blazor WebAssembly-Variante verwenden. Wenn Sie die verschiedenen Rendermodi verwenden möchten, wählen Sie den Projekttyp "Blazor Web App".

 

Vollständige Web-UI mit Blazor

Statischer Server

Der Standard-Rendermodus für eine Blazor-Seite ist das, was man als 'Static Server' bezeichnen könnte. Dabei wird einfach eine Anfrage an den Server gesendet, und die vollständige Seite wird geladen, sobald die Antwort fertig ist. In diesem Fall ist kein Ladezustand möglich. Wenn zum Beispiel Daten abgerufen werden müssen, bleibt der Bildschirm leer oder eingefroren, solange der Server nicht geantwortet hat. In der Regel verwenden Sie diesen Rendering-Modus für Seiten/Komponenten, die einfaches HTML/Razor sind und keine Interaktivität erfordern. Wenn Interaktivität erforderlich ist oder Daten abgerufen werden müssen, sollten Sie Stream Rendering und/oder erweiterte Formulare verwenden. Lesen Sie später mehr über diese Funktionen. Natürlich können Sie auch Javascript verwenden, um Interaktivität zu erreichen, aber ich würde Ihnen raten, Javascript nur zu verwenden, wenn es wirklich notwendig ist. Ziehen Sie stattdessen die Render-Modi 'Interaktiver Server' oder 'Interaktive WebAssembly' in Betracht.

Beachten Sie, dass bei Verwendung dieses Rendermodus nicht alle Blazor-Lebenszyklen verfügbar sind.

Fluss für das Abrufen von Daten:

Verwenden Sie 'Statischer Server' für:

  • Landing Pages
  • Einfache Formulare
  • Normale HTML-Seiten

Interaktiver Server

Der 'Interaktive Server' ist eine einfache Möglichkeit, Interaktivität auf Ihrer Seite oder Komponente zu aktivieren. Wenn Sie diese einfache Zeile zu Ihrer Seite oder Komponente hinzufügen, fühlen sich Benutzerinteraktion und Datenabruf so an, wie Sie es von einer modernen Webanwendung erwarten würden.

@rendermode InteractiveServer

Blazor öffnet eine SignalR-Verbindung auf der Client-Seite, sobald die Seite oder Komponente angefordert wird. Jede Benutzerinteraktion wird über SignalR übermittelt, und der Server gibt das HTML zurück, das im Browser über dieselbe SignalR-Verbindung gerendert werden soll. Wenn es keine Seiten mit dem Rendermodus 'Interaktiver Server' gibt, wird die SignalR-Verbindung geschlossen, um Ressourcen zu sparen.

Es gibt drei Möglichkeiten, diesen Rendermodus zu aktivieren. Die erste ist, den Rendermodus auf der Seitenebene hinzuzufügen:

Alle Komponenten auf dieser Seite werden im Modus 'Interaktiver Server' gerendert. Eine zweite Möglichkeit besteht darin, dasselbe @rendermode Attribut in einer bestimmten Komponente zu platzieren. Die dritte Möglichkeit besteht darin, das Attribut wie folgt zum Element selbst hinzuzufügen: ``

Wenn Sie sich für 'Interaktiver Server' entscheiden, müssen Sie einige Dinge beachten. Der Status des Benutzers wird auf dem Server gespeichert. Sobald der Server angehalten oder neu gestartet wird, ist der Status verschwunden und damit auch der Fortschritt, den der Benutzer bisher gemacht hat. Wenn die Anwendung eine Skalierung auf mehrere Instanzen erfordert, verwenden Sie einen SignalR-Dienst mit der entsprechenden Konfiguration. Denn Sie möchten sicherstellen, dass der Status des Benutzers von der richtigen Instanz abgerufen wird. Wenn Sie den Rendermodus 'Interaktiver Server' verwenden, müssen Sie sicherstellen, dass der/die Benutzer über eine stabile Internetverbindung verfügen.

Verwenden Sie 'Interaktiver Server' für:

  • Seiten/Komponenten, die komplexe Interaktivität erfordern
  • Clients mit begrenzter Hardware
  • Anwendungen, die mit internen Anwendungen integriert werden müssen
  • Wenn keine öffentliche API verfügbar ist

Interaktive WebAssembly

Eine andere Möglichkeit ist die Verwendung von 'Interactive WebAssembly' als Rendermodus. Bei Verwendung dieses Modus werden .wasm Dateien in den Browser geladen. Diese Dateien manipulieren das DOM im Browser, ohne mit einem Server zu kommunizieren. Der Rendermodus kann mit eingestellt werden: @rendermode InteractiveWebAssembly Sie können diesen Rendermodus auf dieselben drei Arten einstellen, wie bereits erwähnt.

Bei der Verwendung von 'Interactive WebAssembly' gibt es einige Dinge zu beachten. Da die Logik auf der Seite des Clients ausgeführt wird, müssen Sie sicherstellen, dass der Client über die richtige Hardware verfügt, um sie auszuführen. Außerdem müssen Sie sicherstellen, dass Ressourcen wie Datenbanken oder APIs für den Client zugänglich sind. Wenn die .wasm Dateien zum ersten Mal geladen werden, wird auch die .NET-Laufzeitumgebung geladen. Dies kann zu einem langsamen Anfangsstart führen.

Verwenden Sie 'Interactive WebAssembly' für:

  • Seiten/Komponenten, die komplexe Interaktivität erfordern
  • Kunden mit eingeschränkter Internetverbindung
  • Wenn eine öffentliche API verfügbar ist
  • Eine große Anzahl von gleichzeitigen Benutzern
  • Anwendungen mit Offline-Unterstützung oder PWAs

Interaktives Auto

Wenn es egal ist, ob eine Komponente oder Seite als 'Interaktiver Server' oder 'Interaktive WebAssembly' geladen wird, können Sie 'Interaktives Auto' wählen, was eine gute Option sein kann. Dies kann wie folgt eingestellt werden: @rendermode InteractiveAuto Auf diese Weise bestimmt Blazor, wie die Komponente oder Seite geladen wird. Wenn die .wasm Dateien bereits geladen sind, werden diese Dateien verwendet. Wenn nicht, wird eine SignalR-Verbindung aufgebaut, um die Komponente oder Seite zu rendern. In der Zwischenzeit werden die Dateien im Hintergrund auf der Client-Seite geladen. Auf diese Weise wird dem Benutzer ein langsamer Ladevorgang erspart und er erlebt eine schnellere Performance der App.

Wenn Sie diesen Modus wählen, stellen Sie sicher, dass sowohl der Rendermodus 'Interaktiver Server' als auch 'Interaktive WebAssembly' für Seiten und Komponenten, die für 'Auto' markiert sind, funktionieren, da Sie nicht wissen, welcher Rendermodus letztendlich verwendet wird. Ein Datenbankaufruf könnte mit 'Interaktiver Server' funktionieren, da sich die Instanz des Blazor-Servers im Netzwerk befindet, während dieselbe Datenbank im Browser des Clients möglicherweise nicht verfügbar ist.

Streamrendering

Wenn Sie keine interaktiven Modi verwenden müssen oder wollen, sondern nur einige Daten abrufen und ein ordentliches Benutzererlebnis bieten möchten, können Sie Stream Rendering verwenden. Beim Stream Rendering wird eine lang andauernde HTTP-Anfrage gestartet, die eine oder mehrere Antworten zurückgeben kann, bevor eine endgültige Antwort zurückgegeben wird. Dadurch kann ein Ladezustand auf dem Bildschirm angezeigt werden, während die Daten abgerufen werden. Dies ist ideal für Anfragen, die etwas länger dauern können.

Das Stream-Rendering wird aktiviert, indem Sie diese Zeile zu Ihrer Seite oder Komponente hinzufügen: @attribute [StreamRendering]

In diesem Beispiel sehen Sie den Text "Loading..." beim ersten Laden. Sobald OnInitializedAsync fertig ist, wird das DOM aktualisiert und die Tabelle wird gerendert. Ohne das Attribut StreamRendering wäre der Text "Loading..." nicht gerendert worden. Stattdessen wird ein leerer oder eingefrorener Bildschirm angezeigt, bevor die Tabelle gerendert wird.

Fluss:

Verbesserte Navigation und Formulare

Eine weitere Neuerung ist die verbesserte Navigation. Diese Funktion sorgt dafür, dass beim Navigieren von einer Seite zur anderen keine ganze Seite geladen wird. Stattdessen wird nur der Inhalt auf der Grundlage der angegebenen URL aktualisiert. Außerdem gibt es keinen lästigen Verlust der Bildlaufposition. Die erweiterte Navigation ist das Standardverhalten, wenn Sie die Vorlage "Blazor Web App" verwenden und diese Funktion nicht ausdrücklich deaktiviert haben. Blazor fängt die Anfragen ab und fügt den Inhalt der Antwort in das DOM ein. Sie können bei Bedarf das Laden einer vollständigen Seite auf drei verschiedene Arten erzwingen.

  • Mit NavigateTo setzen Sie den Parameter forceLoad auf true
  • Mit Navigation.Refresh setzen Sie den Parameter forceLoad auf true
  • Setzen Sie dieses Attribut auf ein a Element oder dessen Elternteil: data-enhance-nav="false"

Wenn Sie mit Formularen arbeiten, können Sie die erweiterte Formularfunktion verwenden. Dies können Sie erreichen, indem Sie das Formular entweder wie folgt angeben:

oder

Auf diese Weise löst die Submit-Aktion des Formulars die damit verbundene Methode aus, ohne dass ein interaktiver Rendermodus erforderlich ist. Die Funktionsweise ist dieselbe wie bei der erweiterten Navigation. Allerdings muss das Attribut explizit zum Formularelement hinzugefügt werden. Andernfalls wird das Formular nichts tun.

Welche Rendering-Modi sollten Sie wählen?

Versuchen Sie zunächst, das Stream-Rendering und die erweiterten Formularfunktionen oder den Rendermodus 'Statischer Server' zu verwenden, wenn möglich. Bei einfachen Seiten/Komponenten sollten Sie zunächst das Stream-Rendering ausprobieren, um Daten abzurufen. Wenn das nicht ausreicht, können Sie den Rendermodus 'Interaktiver Server' ausprobieren. Prüfen Sie jedoch die bereits erwähnten Vor- und Nachteile. Vielleicht ist 'Interactive WebAssembly' in Ihrem Fall besser geeignet. Wenn es sich bei Ihrem Formular nur um eine einfache Übermittlungsaktion handelt, verwenden Sie die Funktion für erweiterte Formulare, bevor Sie einen der interaktiven Rendermodi verwenden. Wenn Sie beispielsweise Ihr Formular auf der Grundlage einer Dropdown-Liste neu rendern müssen, benötigen Sie entweder 'Interactive Server' oder 'Interactive WebAssembly' (oder Auto). Auch wenn Sie mit Javascript hantieren müssen, um interaktives Verhalten in Formularen zu erreichen, sollten Sie einen der interaktiven Render-Modi verwenden. Bitte versuchen Sie, Javascript so weit wie möglich zu vermeiden!

Straßenkarte

Wenn Sie sich die Roadmap von Blazor in .NET 9 ansehen, wird es nicht viele wesentliche Änderungen geben. .NET 9 wird im November 2024 veröffentlicht werden. Die Liste war lang, aber laut Daniel Roth (Blazor Product Manager) 1 wurden einige Punkte von der Liste gestrichen, weil Leistungs- und Sicherheitsverbesserungen wichtiger sind.

Derzeit liegt das Hauptaugenmerk des Blazor-Entwicklungsteams auf der Arbeit am Multithreading für WebAssembly, das in der aktuellen Version von Blazor nicht optimal funktioniert. Es gibt jedoch keine Garantie, dass dies in der nächsten Hauptversion behoben wird.

Auf dieser Seite finden Sie die aktuelle Roadmap für .NET 9: ASP.NET Core Roadmap für .NET 9Â #51834

Wann sollten Sie Blazor wählen?

Wenn Sie oder Ihr Unternehmen über die Fähigkeiten verfügen, problemlos eine React-, Angular-, Vue- oder andere Frontend-Framework-App zu entwickeln, dann besteht wahrscheinlich keine Notwendigkeit, sich mit Blazor zu beschäftigen. Ich möchte Sie jedoch dazu einladen, Blazor zumindest auszuprobieren. Vielleicht sind die Dinge, die Ihre Anwendung braucht, in Blazor einfach zu implementieren.

Wenn Sie bereits über C#-Code und Kenntnisse im Unternehmen verfügen, würde ich sagen, dass es ein Kinderspiel ist, Ihre Anwendungen mit Blazor zu entwickeln. Wenn Sie C# kennen, ist die Lernkurve für Blazor besser als bei jedem anderen Frontend-Framework. Auch die Möglichkeit, vorhandenen Code wiederzuverwenden, ohne ihn direkt neu schreiben zu müssen, ist ein absolutes Plus.

Was die Leistung angeht, gibt es meiner Meinung nach keinen besseren Zeitpunkt als jetzt, um mit Blazor zu beginnen. In den letzten Jahren haben Microsoft und die Community hart daran gearbeitet, ein stabiles und leistungsfähiges Framework zu entwickeln (und tun es immer noch). Außerdem gibt Ihnen die Möglichkeit, den richtigen Rendering-Modus pro Komponente/Seite zu wählen, genügend Freiheit, um die Leistung Ihrer Anwendung nach Bedarf zu verbessern.

Beginnen Sie mit der Erstellung Ihrer modernen Webanwendung mit Blazor!

 

Dieser Artikel ist Teil von XPRT.#16. Laden Sie das Magazin hier herunter.

XMS XPRT16

Verfasst von

Niels Nijveldt

I'm Niels Nijveldt, and I work as a consultant at Xebia. I enjoy working with Blazor, Azure, DevOps and fullstack development.

Contact

Let’s discuss how we can support your journey.