Was ist Blazor?

Im Browser gilt seit Jahrzehnten eine einfache Regel: Wer eine Oberfläche zum Leben erwecken will, schreibt JavaScript. Blazor bricht diese Regel. Es erlaubt, Weboberflächen in C# zu bauen, der Sprache, in der ein großer Teil der deutschen Unternehmenssoftware geschrieben ist. Für Firmen mit .NET im Haus bedeutet das: Die Weboberfläche entsteht in derselben Sprache wie die Warenwirtschaft, die Berechnungen und die Prüfregeln, die es dort schon gibt.

Gebaut wird in Komponenten, also in wiederverwendbaren Bausteinen wie einer Preistabelle oder einem Bestellformular. Jede Komponente ist eine Datei, in der HTML und C#-Code zusammenstehen. Das Prinzip kennt man von React, nur dass hier keine zweite Sprachwelt nötig ist. JavaScript lässt sich einbinden, wenn eine fertige Bibliothek gebraucht wird, es ist aber nicht die Grundlage.

Dieses kleine Beispiel ist eine vollständige Blazor-Komponente: oben die Anzeige, unten die Logik, beides in einer Datei und beides in C#. Klickt jemand auf den Knopf, zählt die Anwendung hoch und aktualisiert die Anzeige von selbst.

Blazor gibt es in zwei Betriebsarten, und die Wahl zwischen ihnen ist die wichtigste Entscheidung im Projekt. Bei Blazor Server läuft die komplette Logik auf dem Server. Der Browser zeigt nur an und meldet jede Eingabe über eine offene Verbindung zurück, der Server schickt die Bildschirmänderung. Das startet schnell und hält den Code im Haus, braucht aber eine stabile Verbindung: Bei schlechtem Netz fühlt sich die Anwendung träge an.

Bei Blazor WebAssembly läuft die Anwendung dagegen direkt im Browser. Möglich macht das WebAssembly, ein Standard, den alle großen Browser verstehen und der auch anderen Sprachen als JavaScript den Weg in den Browser öffnet. Der Preis ist der erste Aufruf: Der Browser lädt neben der Anwendung eine abgespeckte .NET-Laufzeit herunter, und das dauert spürbar länger als bei einer klassischen Webseite. Danach arbeitet die Anwendung auch bei wackligem Netz flüssig.

Seit .NET 8 lassen sich beide Arten mischen: Eine Seite kann fertig vom Server kommen, einzelne Bereiche laufen interaktiv, je nachdem, was die Stelle braucht. Als Faustregel aus unseren Projekten: Im Firmennetz passt meist Server, für Geräte unterwegs eher WebAssembly. Welche Art im Einzelfall trägt, klären wir vor dem Projekt, nicht mittendrin.

Die ehrliche Antwort: fast immer für Anwendungen hinter dem Login, nicht für öffentliche Webseiten. Blazor spielt seine Stärke dort aus, wo ein .NET-Team eine Oberfläche braucht und vorhandene Fachlogik weiterverwenden will. Typische Einsätze sind:

• Interne Anwendungen wie Prüfmasken, Planungswerkzeuge oder Zeiterfassung im Firmennetz
• Die Ablösung alter Windows-Programme, deren Fachlogik in C# weiterleben soll
• Kundenportale für Bestandskunden, bei denen Auffindbarkeit bei Google keine Rolle spielt
• Verwaltungsoberflächen für Maschinen und Geräte, auch auf dem Tablet in der Halle
• Dashboards, die Zahlen aus bestehenden .NET-Systemen anzeigen

Wir setzen Blazor genau in diesem Rahmen ein: Wenn eure Fachlogik in .NET liegt, verwenden wir sie in der Oberfläche direkt weiter, statt sie in einer zweiten Sprache nachzubauen. Liegt kein .NET im Haus, raten wir zu React, auch wenn die Anfrage nach Blazor gestellt war. Mehr zu diesen Projekten steht auf unserer Seite zu Webanwendungen.

Blazor begann nicht als Produktplan, sondern als Machbarkeitsbeweis. Der Microsoft-Entwickler Steve Sanderson zeigte 2017 in einem Experiment, dass .NET dank WebAssembly im Browser laufen kann. Aus der Spielerei wurde ein offizielles Projekt: 2019 erschien Blazor Server als Teil von .NET Core 3.0, ein Jahr später folgte Blazor WebAssembly. Seitdem ist Blazor fester Bestandteil von .NET und wird im selben Rhythmus weiterentwickelt.

Blazor ist eine Antwort auf eine bestimmte Lage, kein Werkzeug für alles. Wer es einsetzen will, sollte die Einschränkungen kennen, bevor die Entscheidung fällt:

• Der erste Aufruf einer WebAssembly-Anwendung lädt die .NET-Laufzeit, auf Mobilfunk dauert das spürbar
• Blazor Server steht und fällt mit der Verbindung: bei schlechtem Netz reagiert die Oberfläche verzögert
• Das Umfeld ist kleiner als bei React, es gibt weniger fertige Bausteine und weniger Entwickler am Markt
• Für öffentliche Seiten, die schnell laden und bei Google vorn stehen sollen, gibt es passendere Werkzeuge

Keiner dieser Punkte wiegt schwer, solange Blazor dort eingesetzt wird, wofür es gedacht ist: Anwendungen für einen bekannten Nutzerkreis, in Firmen, die ohnehin mit .NET arbeiten.

Der Vergleich liegt nahe, weil beide Frameworks Oberflächen aus Komponenten bauen. Die Antwort hängt aber weniger an der Technik als an eurem Haus. React ist der Standard im offenen Web: riesiges Umfeld, viele Entwickler, erste Wahl für alles, was öffentlich und schnell sein muss. Blazor ist die Wahl für .NET-Häuser, die keine zweite Sprachwelt aufmachen wollen. Als Orientierung:

• React, wenn die Anwendung öffentlich ist oder das Team bereits mit JavaScript arbeitet
• React, wenn ihr am Markt aus möglichst vielen Entwicklern wählen wollt
• Blazor, wenn eure Software in C# geschrieben ist und intern genutzt wird
• Blazor, wenn vorhandene Fachlogik aus .NET in der Oberfläche weiterleben soll

Falsch ist keine der beiden Entscheidungen, teuer wird nur die unpassende. Ein .NET-Team, das für eine interne Anwendung React lernen muss, verliert Monate. Eine öffentliche Seite in Blazor kämpft mit Ladezeiten, die React nicht hätte. Die Frage ist also nicht, welches Framework besser ist, sondern welches zu eurem Team und eurem Vorhaben passt.

Für Auftraggeber ist die entscheidende Frage nicht, wie Blazor technisch arbeitet, sondern wer die Anwendung in fünf Jahren pflegt. Genau hier liegt der Reiz: Wenn das eigene Haus mit .NET arbeitet, bleibt die Weboberfläche in der Sprache, die die eigenen Leute lesen und ändern können. Es entsteht keine zweite Werkzeugkette, kein zweites Spezialwissen, keine Abhängigkeit von einem JavaScript-Dienstleister für jede Kleinigkeit.

Auf der Kostenseite ist Blazor unauffällig: Framework und Werkzeuge sind quelloffen und kostenlos, bezahlt wird die Entwicklungszeit. Einplanen sollte man die Versionswechsel von .NET, alle zwei Jahre erscheint eine Fassung mit Langzeitunterstützung, und der Umstieg gehört in die Wartung. Beim Ablösen alter Windows-Programme rechnet sich Blazor oft doppelt: Ein Teil des vorhandenen C#-Codes bleibt nutzbar, und die neue Anwendung muss nicht mehr auf jedem Arbeitsplatz installiert werden.

Die Frage stellt sich bei Blazor anders als bei manchem JavaScript-Framework, das nach drei Jahren wieder verschwindet. Blazor ist kein eigenständiges Produkt, das sich allein am Markt behaupten muss, sondern fester Bestandteil von .NET, einer Plattform, auf der ein erheblicher Teil der weltweiten Unternehmenssoftware läuft. Microsoft entwickelt es im Jahresrhythmus weiter und setzt es in eigenen Produkten ein.

Den Kampf um das offene Web hat Blazor nicht gewonnen, und es sieht nicht danach aus, dass sich das ändert. Dort bleiben React und seine Verwandten gesetzt. In seiner Nische dagegen, den Geschäftsanwendungen der .NET-Welt, ist Blazor etabliert und wächst. Wer dort zuhause ist, bekommt ein Werkzeug mit langer Perspektive. Was wir damit bauen und wann wir abraten, steht auf unserer Seite zur Blazor-Entwicklung.