Blazor
Wer sich gelegentlich mit der Produktpalette von Microsoft auseinandersetzt, ist wohl nicht um den Begriff «Blazor» gekommen. Je nachdem, mit wem man eine Unterhaltung führt, kann der Begriff verwirrend wirken. Es handelt sich aber definitiv nicht um ein Kleidungsstück. Kurzgesagt, ist Blazor eine Alternative zu JavaScript.
- Autor:in
- Dömu Brunner
- Veröffentlicht
Was ist Blazor und wie funktioniert es?
Um Inhalte bzw. ein User Interface (UI) in einem Webbrowser darzustellen, werden vielfach zusätzliche Frameworks wie Vue.js, React oder Angular verwendet. Diese decken sich in der Regel nicht mit den genutzten Technologien auf einem Webserver:

Unter Umständen müssen sich Entwickler:innen mit einer zusätzlichen Technologie auseinandersetzen, welche sie bis dahin nicht beherrschen. Ich bin grundsätzlich der Meinung, dass dies nichts Schlimmes ist. Nur ist man dann nicht effizient und verliert unnötig Zeit. Vor allem, wenn die entsprechende Technologie eine steile Lernkurve aufweist.
Hier kommt nun Blazor ins Spiel, welches uns erlaubt, ein clientseitiges UI in C# Code zu schreiben. Bye bye JavaScript
Gründe für die Verwendung von Blazor
- Entwickler:innen müssen keine neue Technologie lernen. Sie können ihr C# Knowhow verwenden.
- Im Gegensatz zu JavaScript (die Ausnahme bildet TypeScript), ist C# streng typisiert und es können Fehler während des Kompilierens erkannt bzw. behoben werden. Auch wird von C#, die strenge Typisierung während der Laufzeit unterstützt.
- In Blazor können alle gängigen .NET Standard kompatible Libraries bzw. NuGet Packages wiederverwendet werden.
- Visual Studio kann als IDE genutzt werden (IntelliCode, IntelliSense, Debugging Support, etc.).
- C# und JavaScript Code, können miteinander interagieren bzw. sich gegenseitig aufgerufen.
Unterschiedliche Architekturen von Blazor
Blazor WebAssembly
Mit der Verwendung von Blazor WebAssembly wird der C# Code zu Bytecode konvertiert und im Webbrowser dargestellt. Dazu braucht es eine .NET Runtime, welche ebenfalls zu WebAssembly kompiliert worden ist. Diese .NET Runtime läuft im Browser und kann alle .NET Assemblies (DLLs) benutzen. Auch C# Code, welcher in Blazor geschrieben wurde:

Zusammenfassend kann man die Vor- und Nachteile folgendermassen definieren:
| Vorteile | Nachteile |
|---|---|
| Extrem hohe Performance. | Man ist auf die Funktionalität des Webbrowsers beschränkt. |
| Die App funktioniert offline, nachdem alles (HTML, CSS, JavaScript, .NET Standard DLLs, .NET Runtime) initial in den Webbrowser runtergeladen wurde. | Der Webbrowser verrichtet die ganze Ar-beit. Je nach Leistung des Geräts kann das ein Nachteil sein. |
| Es braucht keinen Server. Nur ein Dienst, welcher die notwendigen statischen Datei-en zur Verfügung stellt (Content Delivery Network oder Azure Storage Static Websi-te). | Je mehr runtergeladen werden muss, des-to länger die Dauer. |
| Client-Ressourcen werden genutzt. | Secrets werden auf dem Client gespeichert. |
| Läuft in allen grossen Webbrowser (auch auf mobilen Geräten)., ohne zusätzliche Plugins. | WebAssembly ist notwendig. Es gibt auch Webbrowser, in denen WebAssembly nicht verfügbar ist. |
Blazor Server
Eine Alternative zu Blazor WebAssembly bietet Blazor Server. Besonders dann, wenn ein Webbrowser kein WebAssembly unterstützt.
Mit der Verwendung von Blazor Server läuft die Blazor App in einer ASP.NET Core Website, welche mit der .NET Core Runtime läuft. Diese Website stellt nun die Blazor Komponente zur Verfügung, welche über eine SignalR Websocket Verbindung geladen wird. UI Updates werden so in Echtzeit im Webbrowser angezeigt. Das Grossartige daran ist, dass alles out of the box verfügbar ist und nichts speziell konfiguriert werden muss.

Auch hier kann man die Vor- und Nachteile folgendermassen definieren:
| Vorteile | Nachteile |
|---|---|
| Clients, welche nicht besonders Leistungsstark sind, können verwendet werden. | Es ist eine konstante Verbindung zu dem Server erforderlich, da die Updates über die SignalR Verbindung erfolgen. |
| Alles läuft auf dem Server und es müssen keine Dateien heruntergeladen werden. Die Ladezeit ist relativ kurz. | Ein Server, welche die notwendige Umgebung zur Verfügung stellt, wird benötigt. Dieser muss zusätzlich gewartet werden und erfordert erheblichen Zusatzaufwand. |
| Voller Zugriff auf das ASP.NET Framework. | Die Latenz ist höher, da immer wieder Ab-fragen auf den Server gemacht werden. Dies macht die Applikation ein wenig langsamer. |
| Es besteht keine Abhängigkeit zu WebAssembly. | |
| Secrets können serverseitig gespeichert werden. |
Wann verwende ich welche Architektur?
| Blazor WebAssembly | Blazor Server | |
|---|---|---|
| Wenn eine extreme Performance benötigt wird. Hier spielt es eine Rolle ob beispielsweise Responsiveness (Blazor WebAssembly) ausschlaggebend ist oder eher die rohe Rechenpower benötigt wird (Blazor Server). | ✅ | ✅ |
| Wenn serverseitige Ressourcen (DB, etc.) benötigt werden. | ✅ | |
| Wenn man sich nicht sicher sein kann, dass WebAssembly verfügbar ist. | ✅ | |
| Wenn man die App offline anbieten will. | ✅ | |
| Wenn man keinen ASP.NET Server betreiben will. | ✅ | |
| Wenn man schnelle, interaktive Webapplikationen mit C# erstellen will. | ✅ | ✅ |
Verwandte Themen
Weiterführende Projekte und Inhalte zum Thema