© Creative Design Studio/shutterstock.com, © S&S Media
Zehn Unterschiede zu Blazor Server

Blazor WebAssembly ist endlich erschienen


Blazor WebAssembly ist am 19. Mai 2020 erstmals in einer stabilen Version erschienen. In diesem Beitrag stelle ich kurz zehn Gemeinsamkeiten mit und ausführlich zehn Unterschiede zu dem bereits im September 2019 erschienenen Blazor Server vor.

Blazor WebAssembly und Blazor Server sind sich grundsätzlich sehr ähnlich:

  1. Beide Architekturen basieren auf .NET. Der Webentwickler schreibt C#, HTML, CSS und in einigen Fällen etwas JavaScript.

  2. Nicht auf alle Funktionen eines Webbrowsers kann man in Blazor direkt per C#-Code zugreifen. Derzeit müssen Entwickler selbst für vermeintlich einfache Funktionen auf die Interoperabilität mit JavaScript zurückgreifen, z. B. für das Lesen und Schreiben von Cookies und anderen lokalen Speichertypen des Webbrowsers. Die Interoperabilität funktioniert jeweils in beide Richtungen: C#-Code kann JavaScript und JavaScript wieder C#-Code aufrufen.

  3. Seiten und Seitenteile definiert man in Razor Components. Diese bestehen wahlweise nur aus einem Razor Template (.razor mit C#-Einschüben nach dem @-Zeichen), aus einem Razor Template plus Code-Behind-Datei in C# oder nur aus einer C#-Klasse. Razor Components sind jedoch keine Web Components gemäß W3C-Standard, sondern nur Komponenten innerhalb von Blazor.

  4. Razor Components sind zustandsbehaftet, d. h., die Werte in Klassenmitgliedern (Fields und Properties) bleiben erhalten, solange die Komponente aktiv (sichtbar) ist.

  5. Razor Components feuern Lebenszyklusereignisse (OnInitialized(), OnAfterRender() usw.) und Benutzerereignisse (@onclick, @onkeyup usw.), auf die der Entwickler im C#-Code reagiert.

  6. Die Razor Components manipulieren ein Virtual Document Object Model (DOM), Blazor synchronisiert es mit dem echtem DOM des Browsers.

  7. Die .NET Core Dependency Injection kommt zum Einsatz (z. B. für den NavigationManager zum Abruf und zur Steuerung des Browser-URL).

  8. Eine Kapselung von Razor Components, C#-Code, JavaScript-Code und statischen Inhalten ist in Razor Class Libraries (DLLs) möglich. Es gibt bereits zahlreiche hilfreiche Razor-Class-Library-Pakete aus der Community. Ein Verzeichnis findet man auf GitHub unter „Awesome Blazor“ [1].

  9. Es gibt in beiden Blazor-Varianten noch kein Konzept für zur Laufzeit nachladbare Module (Lazy Loading), was bedeutet, dass alle Razor Components einer Anwendung bereits beim Anwendungsstart geladen werden müssen.

  10. Die Authentifizierung erfolgt über eine Ableitung der Klasse Microsoft.AspNetCore.Components.Authorization.AuthenticationStateProvider. Es gibt eine optionale Integration mit ASP.NET Core Identity.

Das waren in Kürze zehn Gemeinsamkeiten, die dazu beitragen, dass man sehr leicht Programmcode zwischen Blazor WebAssembly und Blazor Server austauschen bzw. gemeinsamen Code und gemeinsame Oberflächen in beiden Architekturen verwenden kann.

Ein interessanter Ansatz ist, eine Webanwendung so in eine Razor Class Library zu kapseln, dass sie sowohl in Blazor WebAssembly als auch Blazor Server verwendet werden kann. Man besitzt dann zwei Kopf-/Start-Projekte und gemeinsame DLLs mit der Oberfläche, dem Programmcode und Ressourcen, wie man es heute schon von Xamarin.Forms kennt.

Im Folgenden wird dieser Beitrag zehn Unterschiede genauer erläutern, die in der Praxis zu beachten sind, wenn man sich für eine der beiden Architekturen entscheiden oder gemeinsam nutzbare Razor Class Libraries schaffen will.

1. Versionsnummer und Support

Die aktuelle Veröffentlichung von Blazor Server trägt die Versionsnummer 3.1.5. Bei Blazor WebAssembly ist die erste Version direkt unter der Versionsnummer 3.2 erschienen; Versionen 1.0 bis 3.1 hat es nie gegeben. Der Unterschied zwischen den Versionsnummern 3.1 bei Blazor Server zu 3.2 bei Blazor WebAssembly bedeutet aber keineswegs, dass Blazor WebAssembly der Nachfolger von Blazor Server ist. Die Versionsnummer 3.2 bedeutet nur, dass die erste Version von Blazor WebAssembly außerhalb des Veröffentlichungszyklus von .NET Core erschienen ist. Die nächste Version wird 5.0 sein. Diese Versionsnummer wird sowohl für Blazor Server als auch Blazor WebAssembly gelten und am 10. November 2020 im Rahmen der .NET Conf 2020 [2] als Teil von .NET 5.0 erscheinen. Auf GitHub findet man eine Roadmap für geplante Verbesserungen und weitere Funktionen in ASP.NET Core Blazor 5.0 [3], die aber wahrscheinlich nicht alle schon in .NET 5.0 erscheinen werden.

Blazor in ASP.NET Core 3.1 ist eine Long-Term-Support-Version (LTS), die Microsoft drei Jahre nach dem Erscheinen mit Bugfixes und Sicherheitsupdates sowie mit kommerziellem Support unterstützt. Die Version 3.1 ist am 3. Dezember 2019 erschienen und wird also bis zum 3. Dezember 2022 unterstützt. Blazor WebAssembly 3.2 hat allerdings lediglich den Status Current Version, erhält also nicht den Long-Term-Support der .NET-Core-Version 3.1 aus dem Dezember 2019. Das bedeutet, dass Anwender nach dem Erscheinen der nächsten Version am 10. November 2020 nur drei Monate Zeit haben werden, die Blazor-WebAssembly-Version zu wechseln. Die erste Long-Term-Support-Version von Blazor WebAssembly wird nach aktuellem Wissen erst die Version 6.0 in .NET 6.0 im November 2021 sein.

2. Architektur

Bei Blazor Server (früher: Server-side Blazor) läuft der .NET-Programmcode auf dem Webserver. Die HTML-Oberfläche wird auf dem Webserver in einem sogenannten Virtual DOM gerendert und mit einem kompakten Synchronisierungsverfahren in einzelnen Datenpaketen über eine kontinuierliche WebSocket-Verbindung zum Client übertragen. Eine JavaScript-Bibliothek im Browser aktualisiert mit diesen Datenpaketen die Oberfläche im Sinne eines Remote Renderings.

Bei Blazor WebAssembly (früher: Client-side Blazor) laufen der .NET-Programmcode und das HTML-Rendering tatsächlich im Webbrowser in dessen WebAssembly-Laufzeitumgebung. Eine JavaScript-Bibliothek kommt dennoch auch hier zum Einsatz, um zwischen der WebAssembly Virtual Machine des Browsers und dem DOM zu synchronisieren, denn die WebAssembly VM des Browsers hat laut W3C-Standard keinen Zugriff auf dessen DOM.

schwichtenberg_blazor_webassembly_1.tif_fmt1.jpgAbb. 1: Blazor Server vs. Blazor WebAssembly

Der Benutzer der Webanwendung erlebt in beiden Fällen eine Single Page Application (SPA). Allerdings kann eine Blazor-Server-basierte Webanwendung niemals offlinefähig werden (daher in Abbildung 1 „SPA light“ genannt), und es gibt auch Probleme bei nicht konstanten Netzwerkverbindungen: Wenn der Webserver nicht mehr erreichbar ist, wird die aktuelle Ansicht im Browser ausgegraut und der Benutzer sieht oben die Warnmeldung „Attempting to reconnect to the server ...“. Sollte das nicht gelingen, erfolgt dann die Meldung „Could not reconnect to the server. Reload the page to restore functionality.“ Wenn der Benutzer dann nicht wieder am Anfang der Anwendung landen soll, sondern an seinem letzten Standort, müssen Zustände im Browser gehalten werden.

Blazor Server hat zudem Herausforderungen bei der Skalierbarkeit, denn das Virtual DOM und der Zustand aller Razor Components liegt für jeden aktuell angeschlossenen Browser im RAM des Webservers. Microsoft hat dokumentiert, dass für jeden ...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang