Blazor Server und Blazor WebAssembly: Alternativen zu JavaScript?

Inhaltsverzeichnis

Sowohl Blazor WebAssembly als auch Blazor Server basieren auf Microsoft .NET, und man programmiert beide mit C#. Anders als sonst üblich bei .NET hat Microsoft eine andere Programmiersprache nicht vorgesehen. Aus der Community gibt es noch Bolero, das Blazor WebAssembly mit F# ermöglicht.

Offiziell heißt Blazor "ASP.NET Core Blazor". Erinnert sei, dass "ASP" früher für "Active Server Pages" stand. Damit stößt man direkt auf einen Widerspruch, denn bei Blazor Server läuft der C#-Code zwar auf dem Webserver, bei Blazor WebAssembly läuft das Programm hingegen im Webbrowser und hat damit das "S" im Namen nicht verdient. Der Ausführungsort ist der fundamentale Unterschied zwischen beiden Architekturen (s. Abb. 1). Dennoch sehen sowohl Softwareentwickler bei der Programmierung der Webanwendungen als auch Benutzer bei deren Einsatz nur geringe Unterschiede zwischen Blazor Server und Blazor WebAssembly.

Um Gemeinsamkeiten und Unterschiede zwischen Blazor WebAssembly und Blazor Server zu verstehen, muss man in deren Entstehungsgeschichte schauen. Microsoft entwickelte von 2007 bis 2012 sehr aktiv das Browser-Plug-in Silverlight, das beliebt war für die Entwicklung interaktiver Anwendungen im Webbrowser. Dann aber stellte Microsoft die Weiterentwicklung ein (u. a. weil die Firma Apple keine Browser-Plug-Ins auf Mobilgeräten zulassen wollte) und setzte auf JavaScript-basierte Webframeworks von Drittanbietern. Von Microsoft selbst gab es nur zaghafte Versuche in dem Markt dieser Frameworks. Microsofts für die Windows-App-Programmierung erschienene WinJS-Bibliothek ist inzwischen auch eingefroren.

Bei der Erstankündigung von Blazor im Februar 2018 hatte Microsoft zunächst nur ein Blazor auf Basis von WebAssembly vorgestellt. Hier laufen C#-Code und .NET-Assemblies direkt innerhalb des Browsers. Man denkt sofort an Silverlight, aber Blazor ist besser, denn es erfordert keine Browser-Plug-ins, sondern läuft in allen zeitgemäßen Webbrowsern, die WebAssembly unterstützen.

Blazor WebAssembly versus Blazor Server

Wie der obere Teil in Abbildung 1 zeigt, ist die Softwarearchitektur von Blazor WebAssembly durchaus komplex, denn die WebAssembly-VM des Browsers hat laut W3C-Standard keinen Zugriff auf dessen DOM. Das umgeht Microsoft mit einem Trick: Eine von dem Unternehmen entwickelte JavaScript-Bibliothek (blazor.webassembly.js) kommt hier zum Einsatz, um zwischen der WebAssembly-VM des Browsers und dem Document Object Model des Webbrowsers (DOM) zu synchronisieren. Jedes Ereignis im Browser sendet die JavaScript-Bibliothek an die Blazor-WebAssembly-Anwendung. Diese kann auf Ereignisse mit der Ausführung von C#-Code oder sogenannten Razor-Templates (mit Platzhaltern in der Syntax @xy) reagieren. C#-Code und Templates manipulieren aber mangels Zugangs nicht das echte DOM, sondern eine Kopie davon innerhalb der WebAssembly-VM, was "Virtual DOM" genannt wird. Der vordefinierte Code synchronisiert die Änderungen auf das echte DOM und ändert so die sichtbare Oberfläche im Webbrowser.

Ursprünglich gab es nur diesen Ansatz. Etwas später kam Microsoft auf die Idee, die JavaScript-Bibliothek und das Virtual DOM auch auf zwei Prozesse aufteilen (im Sinne eines "Remote Rendering") und ein Netzwerk dazwischen legen zu können, sofern das Synchronisierungsverfahren kompakt und effizient ist.

Am 10. August 2018 folgte dann in Preview 0.5 ein serverseitiges Blazor, bei dem der gleiche Programmcode auch auf dem Webserver laufen konnte. Dieses Feature wurde unter dem Stichwort "Out of Process Execution" entwickelt. Danach bezeichnete Microsoft zur Abgrenzung das ursprüngliche WebAssembly-basierte Architekturmodell nun als "Client-Side Blazor", später dann in Blazor WebAssembly umbenannt. "Server-Side Blazor" wurde nun Blazor Server genannt.

Bei Blazor Server läuft der .NET-Programmcode auf dem Webserver. Eine JavaScript-Bibliothek (blazor.server.js) agiert im Browser als Gegenpart. Die Synchronisierung zwischen DOM im Webbrowser und Virtual DOM auf dem Webserver erfolgt hier in einzelnen Datenpaketen mit ASP.NET Core SignalR via Netzwerk über eine kontinuierliche Websocket-Verbindung. Wie bei Blazor WebAssembly aktualisiert auch bei Blazor Server die JavaScript-Bibliothek die Oberfläche und sendet Ereignisse zurück an Blazor (in diesem Fall über das Netzwerk).

Manche Entwickler denken, "Blazor Server" sei der Server zu einer Blazor-WebAssembly-Anwendung. Jedoch ist Blazor Server ein eigenes Softwarearchitekturmodell für die Entwicklung von Single-Page Applications.