Blazor von Grund auf: Kapitel 1 — Was ist Blazor?

Willkommen zu Kapitel 1 von Blazor von Grund auf. Falls du den Einführungspost verpasst hast, in dem ich erkläre, worum es in dieser Serie geht und an wen sie sich richtet, fang dort an — er ist kurz.

In diesem Kapitel werden wir die grundlegende Frage beantworten: Was ist Blazor? Das klingt einfach, aber die Antwort hat mehrere Schichten — besonders weil „Blazor“ im Laufe der Jahre leicht unterschiedliche Bedeutungen angenommen hat. Am Ende dieses Posts wirst du wissen, was Blazor ist, wie es ins .NET-Ökosystem passt, welche Rendering-Modelle es gibt und warum du es — oder eben nicht — einem JavaScript-Framework vorziehen könntest.

Ein kurzer historischer Überblick

Blazor begann um 2017 als experimentelles Projekt von Steve Sanderson bei Microsoft. Die Idee war provokant: C# im Browser mit WebAssembly ausführen und damit JavaScript vollständig überflüssig machen. Es war ein Proof of Concept, und der Name war eine bewusste Mischung aus Blazer und Razor — der Template-Engine, auf der Blazor letztendlich aufgebaut werden sollte.

Das Experiment erzeugte genug Begeisterung, dass Microsoft es ernst nahm. Blazor wurde als Teil von ASP.NET Core 3.0 im September 2019 ausgeliefert, zunächst als Blazor Server — ein Modell, das deinen C#-Code auf dem Server ausführt und eine SignalR-Echtzeitverbindung nutzt, um UI-Updates an den Browser zu senden. Blazor WebAssembly folgte im Mai 2020 als Teil von ASP.NET Core 3.1 und brachte echte clientseitige Ausführung in das Framework.

.NET 6 und 7 verfeinerten die Entwicklererfahrung. Dann überarbeitete .NET 8, veröffentlicht im November 2023, das Rendering-Modell grundlegend mit dem, was Microsoft Full-Stack-Web-UI nannte. Statisches serverseitiges Rendering, Streaming-Rendering, interaktiver Server, interaktives WebAssembly und ein neuer Auto-Modus lebten nun unter einem Dach in einem einzigen Projekt. .NET 9 baute auf diesem Fundament auf und glättete die rauen Kanten.

Da stehen wir heute.

Was Blazor wirklich ist

Im Kern ist Blazor ein komponentenbasiertes UI-Framework für .NET. Du baust deine Oberfläche aus Komponenten — selbständige Einheiten aus C# und HTML-Markup, die Zustand halten, auf Ereignisse reagieren und zu größeren Strukturen zusammengesetzt werden können. Wenn du mit React oder Vue gearbeitet hast, wird dieses mentale Modell vertraut wirken. Der wesentliche Unterschied ist, dass du statt JavaScript C# schreibst.

Komponenten in Blazor werden in .razor-Dateien geschrieben. Eine .razor-Datei mischt HTML-Markup mit C#-Code und verwendet die Razor-Syntax, die du vielleicht schon aus ASP.NET MVC-Views kennst. So sieht eine einfache Komponente aus:

@page "/counter"

<h1>Zähler</h1>
<p>Aktueller Stand: @currentCount</p>
<button @onclick="IncrementCount">Klick mich</button>

@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        currentCount++;
    }
}

Kein JavaScript in Sicht. Die @onclick-Direktive verknüpft den Button-Klick mit einer C#-Methode. Der @currentCount-Ausdruck rendert den aktuellen Wert. Wenn sich der Zustand ändert, ermittelt Blazor, was im DOM aktualisiert werden muss.

Das ist der Kern. Alles andere — Routing, Dependency Injection, Formulare, HTTP-Aufrufe — baut auf diesem Komponentenmodell auf.

Die Rendering-Modelle

Hier liegt viel Verwirrung begraben, also seien wir präzise. „Blazor“ bezeichnet heute eine Familie von Rendering-Modi, kein einzelnes Deployment-Modell. Den Unterschied zu verstehen ist wichtig, weil er sich auf Performance, Infrastrukturanforderungen und das auswirkt, was deine Komponenten können und nicht können.

Statisches SSR

Der einfachste Modus. Deine Razor-Komponenten rendern auf dem Server zu HTML und dieses HTML wird an den Browser gesendet. Es gibt keine persistente Verbindung, kein WebAssembly und standardmäßig keine clientseitige Interaktivität. Das ist im Wesentlichen das, was Razor Pages macht, aber mit dem Komponentenmodell.

Verwende dies für inhaltsreiche Seiten, Landing Pages, alles, was keine Live-Interaktivität braucht.

Interaktiver Server

Dein Komponentencode läuft auf dem Server. Eine SignalR-WebSocket-Verbindung wird zwischen Browser und Server hergestellt. Wenn du auf einen Button klickst oder in ein Eingabefeld tippst, reist das Ereignis über den WebSocket zum Server, dein C# wird ausgeführt, der Diff berechnet und die DOM-Updates zurück an den Browser gesendet.

Vorteile: Vollständiger Zugriff auf Server-Ressourcen (Datenbanken, Dateisystem, Secrets). Schnelles erstes Laden. Kleine Download-Größe. Funktioniert in Browsern ohne WebAssembly-Unterstützung.

Nachteile: Jede Benutzerinteraktion erfordert einen Server-Roundtrip, was Latenz hinzufügt. Server-Ressourcen skalieren mit der Anzahl aktiver Verbindungen. Die App degradiert, wenn die Verbindung abbricht.

Verwende dies für Geschäftsanwendungen, interne Tools, Apps, bei denen serverseitiger Datenzugriff wichtiger ist als Offline-Fähigkeit.

Interaktives WebAssembly

Die .NET-Runtime wird in den Browser heruntergeladen und deine App läuft vollständig auf dem Client. Nach dem ersten Download funktioniert die App komplett offline und jede Interaktion ist sofort — keine Server-Roundtrips für UI-Logik.

Vorteile: Echte clientseitige Ausführung. Funktioniert offline. Reduzierte Serverlast, sobald die App geladen ist.

Nachteile: Größerer initialer Download (.NET-Runtime + deine App). Langsameres erstes Laden. Du brauchst eine API, um auf serverseitige Daten zuzugreifen.

Verwende dies für offline-fähige Apps, Tools, die sofortige Reaktionsfähigkeit brauchen, Szenarien, bei denen Server-Verarbeitung für die UI nicht benötigt wird.

Auto-Modus

In .NET 8 eingeführt. Die App startet im interaktiven Server-Modus (schnelles erstes Laden, kein Warten auf den WebAssembly-Download). Sobald die WebAssembly-Dateien im Hintergrund heruntergeladen wurden, wechseln nachfolgende Besuche automatisch in den WebAssembly-Modus.

Das gibt dir das schnelle erste Laden des Server-Modus und letztendlich die vollständige clientseitige Ausführung von WebAssembly. Es ist das komplexeste Modell, ist aber ein praktischer Standard für viele Apps.

Modi in derselben App mischen

In .NET 8 und höher bist du nicht auf einen einzigen Rendering-Modus für die gesamte App beschränkt. Eine Landing Page kann statisches SSR sein; das authentifizierte Dashboard kann interaktiver Server sein; ein Datenvisualisierungs-Widget kann interaktives WebAssembly sein. Das Framework verwaltet die Übergänge.

In dieser Serie beginnen wir mit dem interaktiven Server, weil er am einfachsten zum Laufen zu bringen ist und das direkteste mentale Modell hat. Wir erkunden die anderen Modi unterwegs.

Wie Blazor sich mit JavaScript-Frameworks vergleicht

Wenn du mit React, Angular oder Vue entwickelt hast, ist das wahrscheinlich der Vergleich, der dich interessiert.

Die Ähnlichkeiten sind real. Blazors Komponentenmodell ist dem von React bewusst ähnlich. Du hast Props (Parameter in Blazor), lokalen Zustand (Felder im @code-Block), Lifecycle-Hooks und dasselbe Kommunikationsmuster: Daten nach unten, Ereignisse nach oben. Wenn du React kennst, wirst du dich innerhalb weniger Stunden zurechtfinden.

Der wesentliche Unterschied ist die Sprache. In Blazor schreibst du C#. Deine Geschäftslogik, Validierungsregeln und Datenmodelle können alle zwischen deinem Blazor-Frontend und deinem ASP.NET Core-Backend geteilt werden. Kein doppeltes Pflegen einer User-Klasse in TypeScript, wenn du sie schon in C# hast.

Die Ökosystem-Lücke ist real, schließt sich aber. Das npm-Ökosystem ist riesig. Das NuGet-Ökosystem für UI-Komponenten ist kleiner, obwohl es erheblich gewachsen ist. Für eine spezifische Charting-Bibliothek oder ein Drag-and-Drop-Widget hat JavaScript noch mehr Optionen. Aber für die meisten Geschäftsanwendungen ist das, was im .NET-Bereich verfügbar ist, mehr als ausreichend.

JavaScript-Interoperabilität ist vorhanden, wenn du sie brauchst. Blazor lässt dich JavaScript von C# aus und C# von JavaScript aus aufrufen. Für Browser-APIs ohne .NET-Wrapper oder wenn du eine vorhandene JS-Bibliothek nutzen willst, ist Interop verfügbar. Es fügt eine Schicht hinzu, ist aber nicht schmerzhaft.

Die ehrliche Antwort: Wenn dein Team ausschließlich aus JavaScript-Entwicklern besteht, die ein öffentliches Produkt bauen, bei dem SEO, Performance und das npm-Ökosystem entscheidend sind, bleib bei JavaScript. Wenn dein Team aus .NET-Entwicklern besteht, wenn du interne oder Geschäftsanwendungen baust, oder wenn Code-Sharing zwischen Frontend und Backend dir wichtig ist, ist Blazor eine überzeugende Wahl.

Was du brauchst, um mitzumachen

Für den Rest dieser Serie benötigst du:

• .NET 9 SDK — herunterladen von dot.net
• Eine IDE — Visual Studio 2022 (Community-Edition ist kostenlos), VS Code mit der C# Dev Kit-Erweiterung oder JetBrains Rider
• Grundkenntnisse in C# — Klassen, Properties, Interfaces, async/await

Das ist alles. Kein Node, kein npm, kein webpack.

Was als nächstes kommt

In Kapitel 2 werden wir deine erste Blazor-App erstellen, die Projektstruktur durchgehen und sicherstellen, dass du sie lokal ausführen kannst. Am Ende wirst du eine funktionierende App vor dir haben und ein klares Bild davon, was jede Datei macht.

Bis dahin.