Blazor oder React für Geschäftsanwendungen: Was kostet Sie weniger?

Suchergebnisse zu „Blazor vs React“ sind voller Benchmarks und Entwicklermeinungen. Für ein Unternehmen, das eine Geschäftsanwendung baut, ist eine andere Frage wichtiger: Welche Wahl bedeutet weniger Leute, weniger doppelte Arbeit und weniger Überraschungen in den nächsten fünf Jahren?

Die kurze Antwort: Wenn Ihr Team C# schreibt und die Anwendung intern oder hinter einem Login läuft, kostet Blazor meist weniger. Wenn Sie ein öffentliches Produkt für viele Nutzer bauen, mit Frontend-Team und viel Interaktivität, ist React die bessere Wahl. Der größte Unterschied liegt nicht in der Technik, sondern darin, wer die Bildschirme baut.

Derselbe Bildschirm in beiden

Am einfachsten sieht man den Unterschied an einem kleinen Bildschirm: einer Liste offener Aufträge mit einem Aktualisieren-Button.

In React lebt der Bildschirm in JavaScript oder TypeScript und holt die Daten über eine API vom Backend:

type Order = { number: string; customer: string; total: number };

export function OpenOrders() {
  const [orders, setOrders] = useState<Order[]>([]);

  const load = () =>
    fetch('/api/orders/open')
      .then((response) => response.json())
      .then(setOrders);

  useEffect(() => { load(); }, []);

  return (
    <>
      <h2>Open orders: {orders.length}</h2>
      <button onClick={load}>Refresh</button>
    </>
  );
}

Dafür braucht das .NET-Backend einen Endpunkt, der wie jeder andere abgesichert, versioniert und dokumentiert werden muss:

app.MapGet("/api/orders/open", (OrderService orders) => orders.GetOpenAsync())
   .RequireAuthorization();

In Blazor mit serverseitigem Rendern ist der ganze Bildschirm eine C#-Komponente, die denselben Service direkt aufruft:

@inject OrderService Orders

<h2>Open orders: @openOrders.Count</h2>

<button @onclick="LoadAsync">Refresh</button>

@code {
    private List<Order> openOrders = [];

    protected override Task OnInitializedAsync() => LoadAsync();

    private async Task LoadAsync() => openOrders = await Orders.GetOpenAsync();
}

In React gibt es den Typ Order zweimal, einmal in C# und einmal in TypeScript, oft auch die Validierungsregeln. Bei einem Bildschirm ist das eine Kleinigkeit. Bei einer Anwendung mit hundert Bildschirmen ist es eine Schicht Arbeit, die mit jeder Änderung wächst.

Fairerweise: Auch eine Blazor-Anwendung, die im Browser auf WebAssembly läuft, braucht eine API. Der Unterschied ist, dass Modelle und Validierung trotzdem geteilt werden können, weil beide Seiten C# sind.

Verglichen nach dem, was fürs Geschäft zählt

	Blazor	React
Wer baut die Bildschirme	Dieselben C#-Entwickler, die das Backend bauen	Meist ein eigener Frontend-Entwickler oder Full-Stack-Entwickler in zwei Sprachen
Recruiting	Aus dem Pool der .NET-Entwickler	Aus einem viel größeren Pool von Frontend-Entwicklern
Fertige Komponenten	Genug für Geschäftsanwendungen: Tabellen, Formulare, Diagramme	Das größte Ökosystem überhaupt
Erstes Laden	Schnell im Server-Modus, größerer erster Download bei WebAssembly	Schnell, vor allem mit Frameworks wie Next.js
Öffentliche Seiten und SEO	Möglich, aber nicht seine Stärke	Stark, vor allem mit Next.js
Gemeinsamer Code mit dem Backend	Dieselben Klassen, Validierung und Regeln	Eine zweite Sprache, Typen und Validierung also doppelt
Updates über fünf Jahre	Ein .NET-Update pro Langzeitsupport-Zyklus	Viele npm-Pakete, die sich jeweils im eigenen Tempo ändern
Zu wartende Stacks	Einer	Zwei: JavaScript und .NET

Ein typisches Szenario

Nehmen wir ein Großhandelsunternehmen mit drei C#-Entwicklern, die die ERP-Schnittstellen pflegen. Es will ein neues Portal, in dem 200 Mitarbeitende Aufträge und Lieferungen verfolgen.

Mit Blazor bauen dieselben drei Leute das Portal. Die Bildschirme nutzen die vorhandenen Services und die Validierung, und jeder neue Bildschirm ist eine Komponente.

Mit React gibt es zwei Wege. Das Unternehmen stellt einen Frontend-Entwickler ein, mit allem, was Recruiting, Einarbeitung und Abstimmung mit sich bringen. Oder die drei C#-Entwickler lernen React und TypeScript, bauen für jeden Bildschirm einen API-Endpunkt und halten die Typen auf beiden Seiten synchron.

Keiner der Wege ist falsch. Aber für diese Art Anwendung kostet der zweite bei jedem neuen Bildschirm mehr, solange die Anwendung lebt.

Ehrlich über Performance und Popularität

• Performance. React lädt schnell und läuft komplett im Browser. Blazor im Server-Modus öffnet sich ebenfalls schnell, aber jeder Klick geht zum Server, was bei guter Verbindung niemand bemerkt, bei schlechter aber spürbar ist. Blazor auf WebAssembly hat einen größeren ersten Download, der danach im Browser zwischengespeichert wird. Für eine interne Anwendung, die täglich geöffnet wird, entscheidet das selten etwas. Für eine öffentliche Seite, die sich auf dem Handy in einer Sekunde öffnen muss, schon.
• Popularität. React ist weitaus verbreiteter, Blazor ist im Vergleich eine Nische. Das zählt, wenn Sie Frontend-Spezialisten einstellen müssen. Es zählt viel weniger, wenn Ihr Team ohnehin C# spricht.

Wann React die bessere Wahl ist

• ein öffentliches Produkt für viele Nutzer, das von Google-Traffic abhängt
• sehr reiche Interaktivität: Editoren, Drag and Drop, viele Animationen
• ein Unternehmen, das bereits ein Frontend-Team mit JavaScript hat
• eine mobile App in React Native, die Code mit dem Web teilen soll

Und React im Frontend mit .NET im Backend ist eine völlig solide Architektur, die viele Unternehmen einsetzen. Das .NET-Backend ist in beiden Fällen dasselbe.

Fünf Fragen vor der Entscheidung

1. Wer baut und pflegt die Bildschirme: Leute, die C# können, oder Frontend-Entwickler?
2. Ist die Anwendung intern oder hinter einem Login, oder öffentlich und von Google abhängig?
3. Wie viel Ihrer Geschäftslogik liegt bereits in .NET?
4. Brauchen Sie sehr reiche Interaktivität oder vor allem Formulare, Tabellen und Berichte?
5. Wen können Sie dort, wo Sie sind, in zwei Jahren realistisch einstellen?

Deuten die Antworten auf ein C#-Team, einen Login und Logik, die schon in .NET liegt, wählen Sie Blazor. Deuten sie auf ein Frontend-Team, ein öffentliches Publikum und eine reiche Oberfläche, wählen Sie React, mit einem .NET-Backend.

Ob Blazor selbst für die nächsten Jahre eine sichere Wahl ist, steht im Artikel Hat Blazor 2026 noch Zukunft?. Und wenn Sie schon eine Blazor-Anwendung haben, die langsam geworden ist, lesen Sie die sieben häufigsten Ursachen.

Wie wir arbeiten

ProCoding ist ein .NET-Studio aus Split, Kroatien. Wir bringen Blazor seit 2020 in Produktion und bauen auch .NET-Backends, mit denen React-Frontends sprechen, daher haben wir keinen Grund, das eine oder das andere zu drängen. Wir helfen bei der Wahl, bauen neue Blazor-Anwendungen und migrieren ältere Anwendungen Bildschirm für Bildschirm. Der erste Schritt ist ein kostenloses 30-minütiges Gespräch.

Quellen

• ASP.NET Core Blazor, Microsoft Learn
• ASP.NET Core Blazor render modes, Microsoft Learn
• React documentation, react.dev
• .NET and .NET Core support policy, Microsoft