Blazor: Eine Alternative zu Angular, React und Co.?

Das Angebot an Frameworks für Webapplikationen nimmt stetig zu: Neben bekannten Lösungen wie Angular oder React gibt es eine Vielzahl weiterer JavaScript-Frameworks, mit denen Webapplikationen entwickelt werden können. 2018 wurde das Angebot an Webframeworks um eine Lösung erweitert: Microsoft Blazor. Doch was genau steckt dahinter? Worin unterscheidet sich Blazor von anderen Webframeworks? Und: Lohnt sich der Umstieg überhaupt?

Was ist Blazor?

Blazor ist ein open-source-basiertes Webframework von Microsoft, das wie andere Webframeworks HTML und CSS zur Darstellung von Web-Anwendungen nutzt. Der Unterschied: Blazor basiert nicht wie andere Frameworks auf JavaScript, sondern auf .NET und der Razor-Syntax. Programmiert wird in C#. Entwicklern steht damit ein vertrautes Ökosystem zur Realisierung von Webapplikationen zur Verfügung, ohne sich zusätzlich mit JavaScript-basierten Frameworks vertraut machen zu müssen.

Es gibt mehrere Ausführungsvarianten von Blazor. Die wichtigsten – Blazor Server und Blazor WebAssembly – sollen hier kurz vorgestellt werden:

Blazor WebAssembly: Anwendungen werden direkt im Browser auf einer .NET-Runtime ausgeführt, die auf WebAssembly basiert. Diese Anwendungen funktionieren ähnlich wie Frontend-JavaScript-Frameworks – entwickelt wird jedoch in C#. Wird auf eine Blazor-WebAssembly-App navigiert, wird eine Anfrage an den Webserver abgesetzt. Dieser antwortet mit der .NET-Laufzeitumgebung, zusammen mit WebAssembly und allen erforderlichen Abhängigkeiten. Browser-Plugins oder Erweiterungen sind nicht nötig. Da die Laufzeitumgebung den .NET-Standard unterstützt, können vorhandene .NET-Standardbibliotheken problemlos mit der Blazor-WebAssembly-Anwendung verwendet werden. Diese wird rein Client-seitig ausgeführt – .NET ist auf dem Server nicht erforderlich.

Blazor Server: Die Komponenten der Webanwendungen werden auf dem Server aufbereitet, und nicht Client-seitig im Browser. Bei einer Anfrage an den Server übermittelt dieser ein initiales Document Object Model (DOM) – also ein virtuelles Abbild des Browserinhalts –, das die Kommunikation mit dem Server behandelt. UI-Interaktionen wie Klicks oder Textinputs, die im Browser stattfinden, werden über eine Echtzeitverbindung (SignalR) an den Server gesendet und an die richtigen Komponenteninstanzen weitergeleitet. Die Komponenten werden gerendert und das berechnete UI-DIV – in HTML ein allgemeiner Container auf Blockebene für Seitenelemente – an den Browser bzw. ans DOM zurückgesendet. Die Darstellung in der Webapplikation wird angepasst.

Blazor WebAssembly vs. Blazor Server: Die Vor- und Nachteile

Da bei Blazor WebAssembly der Code lokal im Browser ausgeführt wird, lassen sich die Ressourcen des Clients voll ausschöpfen – was die Performance deutlich steigert. Zudem wird die Last vom Server auf den Client verlagert, wodurch die Anwendung skalierbar wird. Eine serverseitige .NET-Abhängigkeit gibt es nicht. Die Anwendung ist nach dem Download auf dem Client voll funktionsfähig und offlinefähig. Jedoch ergeben sich durch den Browser auch Limitierungen, welche die Anwendung einschränken können. Ausserdem ist eine geeignete Client-Hard- und Software nötig, damit Anwendungen auf Blazor WebAssembly funktionieren. Der Download ist grösser und die Anwendungen haben eine längere Ladezeit als bei Blazor Server.

Blazor Server kann die Möglichkeiten des Servers voll ausschöpfen, einschliesslich der Nutzung aller .NET-kompatiblen APIs. Zudem werden auch Thin-Clients problemlos unterstützt. Blazor-Server-Anwendungen funktionieren auch für Browser, die WebAssembly nicht unterstützen, sowie auf Geräten mit eingeschränkten Ressourcen. Dafür ist die Latenz der Benutzeroberfläche bei Blazor Server hoch, da jede Benutzerinteraktion potenziell eine Kommunikation mit dem Server auslöst. Weil der Server also mehrere Client-Verbindungen verwalten muss, ist die Skalierbarkeit bei Blazor Server eine Herausforderung für Anwendungen mit vielen Benutzern. Es gibt keine Offline-Unterstützung: Wenn die Client-Verbindung ausfällt, funktioniert die App nicht mehr. Zudem ist ein ASP.NET-Server für die Bereitstellung der Anwendung erforderlich. Serverlose Bereitstellungsszenarien wie über Content Delivery Networks sind bei Blazor Server nicht möglich.

Angular, React und Blazor im Vergleich

Um die Nutzung von Blazor zu evaluieren, lohnt sich ein Vergleich mit den zwei derzeit in der Schweiz am weitesten verbreiteten Webframeworks: Angular und React. Angular wurde schon 2010 veröffentlicht, und ist – inzwischen als Typescript-Framework – im Einsatz bei namhaften Firmen wie Google oder Microsoft. Der Fokus bei Angular liegt in der Robustheit und in der Einhaltung von Standards. So ist es unter Angular z. B. nicht möglich, beliebige JavaScript-Bibliotheken einfach einzubinden. Die vielen Funktionalitäten und Features, die Angular bietet, sind gleichzeitig der Nachteil des Webframeworks: Sie wollen zuerst gelernt sein, bevor man das Framework richtig auskosten kann. Eine gewisse Einarbeitungszeit ist bei Angular also unvermeidlich. Zwar erscheinen jährlich zwei Major-Updates des Frameworks; jedoch ist der Wechsel von einer Major-Version zur nächsten stets mit einem Migrationsaufwand verbunden. Bei Projekten mit längerer Entwicklungszeit muss also mit regelmässigen Migrationen gerechnet werden.

React ist im Vergleich zu Angular keine Typescript-, sondern eine reine JavaScript-Bibliothek. Unter anderem setzen Firmen wie Facebook oder Uber auf das Framework. Im Gegensatz zu Angular können unter React andere JavaScript-Bibliotheken eingebunden werden – was eine grosse Flexibilität in der Entwicklung und Implementierung von Webanwendungen erlaubt. Auch für React werden in kurzen Abständen Updates lanciert, doch sind die Version-Sprünge deutlich kleiner als bei Angular.

Blazor setzt den Fokus vor allem auf .NET-Entwickler, damit diese das bestehende Wissen in .NET und C# bei der Entwicklung von Webapplikationen wiederverwenden können. Als vergleichsweise junges Framework weist Blazor noch gewisse Kinderkrankheiten auf, welche die Community aber stetig zu beseitigen versucht. Für Blazor Server gibt es bereits einen Long Term Support (LTS) von drei Jahren für Major-Versionen mit geraden Zahlen. Zwischenversionen bzw. ungerade Major-Versionen haben einen Support von 18 Monaten. Ein entsprechendes Support-Modell ist auch für Blazor WebAssembly geplant. Blazor ist neu Teil der neuen .NET-Plattform. Aktuell ist dies Version .NET 5, .NET 6 wird im November diesen Jahres erscheinen. Zu den wichtigsten Neuerungen für Blazor WebAssembly und Blazor Server gehören:

• Hot Reload: Nur geänderte Daten werden aktualisiert, ohne den Status der App zu ändern (kein Build-Run-Zyklus).
• Ahead of Time Compilation für Blazor WebAssembly: Beschleunigt das Ausführen von Blazor-Code im Browser.
• Error boundary: Fehler innerhalb der Applikation werden abgefangen, ohne die ganze Applikation zum Stillstand zu bringen. Stattdessen wird auf eine Fallback-UI zurückgegriffen.

Fazit: Lohnt sich Blazor?

Das Basiswissen, dass Frontend-Entwickler vorweisen müssen, ist bei allen drei Frameworks dasselbe: Man braucht Kenntnisse in HTML5 und muss wissen, wie JavaScript und CSS funktionieren. Sobald anspruchsvollere Websites oder Progressive Webapplikationen entwickelt werden sollen, müssen auch Kenntnisse z. B. über Service Workers vorhanden sein. Und auch mit Web Sockets, Ajax und anderen Bereichen sollten Entwickler vertraut sein, wenn sie sich an Webapplikationen wagen. Erst wenn dieses Grundwissen vorhanden ist, kann man sich mit einem dieser Frameworks beschäftigen.

Der Vorteil von Blazor: Es beschränkt sich auf das von Microsoft bekannte Ökosystem, Funktionalitäten können mit C# umgesetzt werden. Für .NET-Teams bietet gerade Blazor WebAssembly eine ideale Einstiegsmöglichkeit in Single Page Applications, da die Lernkurve wesentlich niedriger ist als bei JavaScript-Frameworks. Bei einer stabilen Netzwerkverbindung – beispielsweise im Intranet – und einer bekannten Anzahl Nutzer können gerade Blazor-Server-Applikationen nützlich sein – z. B. für ein Monitoring-Cockpit. Wer aber bereits ein Webapplikationsprojekt mit einem anderen Framework angestossen hat, für den lohnt sich der Wechsel kaum. Auch für Mobile-Anwendungen ist Blazor wegen der ständigen Verbindung zum Server (Blazor Server) und der grösseren Downloads (Blazor WebAssembly) weniger geeignet.