Seite 3: Dennoch zahlreiche Unterschiede

Inhaltsverzeichnis

Endnutzer sehen auf den ersten Blick keinen Unterschied zwischen einer Blazor-Server- und einer Blazor WebAssembly-Anwendung. Das heißt, auch eine Blazor-Server-Anwendung wirkt nicht wie eine klassische Multi-Page Application (MPA), sondern wie eine moderne Single-Page Application (SPA). Im Detail gibt es aber dennoch einige Unterschiede:

• Das erste Release von Blazor Server ist am 23. September 2019 erschienen mit der Versionsnummer 3.0, das zweite am 10. Dezember 2020 als Version 3.1. Aktuell ist Version 3.1.6. Das erste Release von Blazor WebAssembly ist unter der Nummer 3.2 am 19. Mai 2020 erschienen. Aktuell ist die Version 3.2.1. Eine Versionsnummernangleichung erfolgt erst mit .NET 5.0 (geplant für den 10. November 2020). Dann erhalten Blazor Server und Blazor WebAssembly beide die Nummer 5.0.
• Blazor Server 3.1 ist eine LTS-Version (Long-Term Support), die Microsoft drei Jahre nach dem Erscheinen mit Bugfixes und Sicherheitsupdates sowie kommerziellem Support unterstützt. Blazor WebAssembly 3.2 hat allerdings lediglich den Status "Current Version", die schon drei Monate nach dem Erscheinen der nächsten Version aus dem Support läuft. Version 5.0 wird für beide Architekturen eine "Current Version" sein. Langfristigen Support (d. h. drei Jahre) gibt es für Blazor WebAssembly erst in .NET 6.0 im November 2021.
• Bei Blazor Server laufen der C#-Programmcode und das Virtual DOM auf dem Webserver auf Basis der .NET-Core-Laufzeitumgebung, bei Blazor WebAssembly hingegen C#-Code und Virtual DOM im Webbrowser, und zwar in dessen Sandbox.
• Blazor Server läuft auf Basis von .NET Core (aktuell 3.1), Blazor WebAssembly auf Basis von Mono (aktuell 6.13). Das liegt daran, dass das Mono-Entwicklungsteam die herausfand, wie man .NET mit WebAssembly kompatibel macht. Erst in .NET 5.0 werden beide die gleiche Laufzeitumgebung verwenden.
• Blazor Server funktioniert mit einem Polyfill auch im Internet Explorer, Blazor WebAssembly läuft dort gar nicht.
• Während eine Blazor-WebAssembly-Anwendung auch offline arbeiten kann und als Progressive Web App (PWA) lokal installierbar ist, kann eine Blazor-Server-Anwendung niemals offline funktionieren. Wenn bei einer Blazor-Server-Anwendung der Webserver nicht mehr erreichbar ist, wird die aktuelle Ansicht im Browser ausgegraut und Benutzer sehen oben eine Warnmeldung. Sollte auch nach einigen Sekunden die Verbindung nicht wiederhergestellt sein, werden Benutzer aufgefordert, die Anwendung neu zu laden. Wenn sie dann zur alten Position in der Anwendung zurückkehren sollen, muss die Anwendung das über eine eigene Zustandsverwaltung im Webbrowser oder auf dem Webserver regeln.
• Während bei Blazor WebAssembly Rechenzeit und RAM des Client-Systems mit dem Webbrowser verwendet werden, teilen sich bei Blazor Server alle Nutzer die Prozessoren und den Speicher des Webservers. Blazor Server ist folglich schlechter skalierbar.
• Während Blazor Server naturgemäß immer auf einem ASP.NET-Core-fähigen Webserver laufen muss, lässt sich Blazor WebAssembly von einem beliebigen Webserver starten.
• Beim Erstellen einer verteilbaren Version (dotnet publish) entsteht bei Blazor Server eine .exe-Datei, bei Blazor WebAssembly eine .dll. Bei Ersterem ist also ein Self-Hosting außerhalb eines Webservers möglich, wie bei ASP.NET Core üblich, indem man die entstandene .exe-Datei einfach startet. Hier startet Kestrel, der in ASP.NET Core integrierte Webserver.
• Während bei Blazor WebAssembly der Startcode der Anwendung inklusive der Konfiguration des Dependency-Injection-Containers in der Datei Program.cs erfolgt, verwendet Blazor Server den in ASP.NET Core üblichen Host Builder mit einer Klasse Startup.cs (s. Abb. 2).

• Bei Blazor Server sind alle Debugging-Funktionen von Visual Studio uneingeschränkt verfügbar, bei Blazor WebAssembly gibt es noch Restriktionen (z. B. keinen Halt bei unbehandelten Ausnahmen, Inhalte von Objektmengen werden nicht korrekt angezeigt, Debugging nur mit Chrome und Edge Chromium).
• Blazor WebAssembly lädt beim Start eine Vielzahl von Dateien (35 Dateien mit 5,7 MByte schon für "Hello World"). Für eine öffentliche Internet-Anwendung ist der Anwendungsstart von Blazor WebAssembly daher zu langsam. Bei Blazor Server sehen Benutzer hingegen schnell die erste Ansicht.
• Bei Blazor Server findet die in .NET übliche Übersetzung von Intermediate Language (MSIL) in Maschinencode per Just-in-Time-Compiler (JIT) statt. Bei Blazor WebAssembly wird ebenfalls MSIL in den Webbrowser geladen, dort aber interpretiert von einem MSIL-Interpreter innerhalb der dortigen .NET-Laufzeitumgebung, die eine WebAssembly-basierte Variante von Mono ist. Diese Architektur macht Blazor WebAssembly vergleichsweise langsam. Die für Blazor WebAssembly geplante Ahead-of-Time-Kompilierung (AOT) in WebAssembly-Bytecode, die die Ausführung beschleunigen könnte, hat Microsoft leider vertagt (sie wird auch nicht in .NET 5.0 erscheinen).
• Die Interoperabilität zwischen dem C#-Programmcode und JavaScript ist in beiden Blazor-Varianten vorhanden. In Blazor Server ist die JavaScript-Interoperabilität allerdings nicht im Rahmen der sogenannten Pre-Rendering-Phase einer Razor Component möglich, das heißt nicht in den Lebenszyklusereignisbehandlungsroutinen OnInitialized() und OnInitializedAsync(), sondern erst in OnAfterRenderAsync().
• Ein Zugriff auf den Titel des Browserfensters oder andere Daten im <head>-Element der Webseite ist in Blazor WebAssembly nur über JavaScript möglich. Unter Blazor Server können Entwickler über die Razor Page _host.cshtml darauf zugreifen, die im gleichen Prozess läuft wie die Razor Component von Blazor Server.
• Unter Blazor WebAssembly erzeugt der Aufruf der Methode Console.WriteLine() eine Ausgabe in der Entwicklerkonsole des Webbrowsers. Unter Blazor Server landet diese Methode auf dem Webserver; für die Ausgabe in der Entwicklerkonsole des Webbrowsers muss man per JavaScript-Interoperabilität die JavaScript-Funktion console.log() aufrufen.
• Blazor Server kann ohne die Einschränkung einer Sandbox alle in .NET Core erreichbaren Programmierschnittstellen verwenden, also sowohl .NET-Assemblies und COM-Komponenten als auch direkt die Windows-Betriebssystem-APIs Windows 32 (Win32) und Windows Runtime (WinRT) nutzen. Die WebAssembly-VM, auf der Blazor WebAssembly aufsetzt, läuft hingegen genau wie JavaScript in der Sandbox des Webbrowsers. Das schränkt die Nutzung von APIs und Ressourcen stark ein.
• Blazor Server kann alle .NET Core 3.x-fähigen Assemblies (also alle Assemblies, die .NET Standard bis Version 2.1 unterstützen) laden und nutzen. Blazor WebAssembly 3.2 kann nur .NET-Standard 2.1-Assemblies verwenden.
• In Blazor Server ist ein direkter Datenbankzugriff möglich via ADO.NET, Entity Framework Core oder anderen Datenzugriffstechniken. Auch Dateisystem und beliebige andere Ressourcen (z. B. Verzeichnisdienste) sind erreichbar. Bei Blazor WebAssembly ist ein Zugriff auf Datenbanken, Dateisystem und andere Ressourcen nur über einen HTTP-/HTTPS-basierten Webservice (WebAPI/REST-Dienst sowie Google RPC) möglich. Lediglich die lokale Browserdatenbank lässt sich in Blazor WebAssembly einsetzen.