Vor- und Nachteile vom neuen Webframework Blazor

Blazor ist ein von Microsoft entwickeltes, open-source Webframework, welches erlaubt WebApps in C# zu schreiben. Dies ist möglich, indem Blazor einen kleinen JavaScript Teil hat, welcher nach Anweisungen des C# Teils den HTML DOM updatet. Zudem sendet der JavaScript Teil Browser-Events an den C# Teil weiter. Dieser Aufbau erlaubt es Blazor in zwei Modi zu operieren, Server Side and Client Side. Im ersten Fall läuft die App auf dem Server, und alle Änderungen am DOM sowie Events werden mit SignalR über ein Websocket ausgetauscht.

Im Client Side Fall wird die ganze C# App von einem statischen Webserver in den Browser geladen und dort in WASM ausgeführt. Daten werden wie in einer klassischen WebApp über eine Web API geladen.

Das Framework 

Blazor verwendet, wie die etablierten Web-Frameworks, einen komponentenbasierten Ansatz. Jede dieser Komponente besteht, wie in Angular, aus Code und HTML-Templates, sowie unter Umständen aus komponentenspezifischem CSS. Blazor ist komplett in .Net und Visual Studio (VS) integriert. So hat man die Möglichkeit, Blazor Projekte und Komponenten direkt von der Command Line oder in VS zu generieren. Die Integration in VS stellt zudem Autovervollständigungs- und Autoformatierungs-Funktionen für Code, Templates und beschränkt für CSS zur Verfügung.

Vorteile von Blazor

Eines der grössten Vorteile von Blazor ist, dass man Fullstack in einer Sprache entwickeln kann. Dies erlaubt den geschriebenen Code möglichst effizient wiederzuverwenden. Wurde für das Backend eine Validierungslibrary geschrieben, muss man die Logik im Frontend nicht nochmals neu implementieren, sondern kann einfach die gleiche Library einbinden. Dasselbe gilt für Data Transfer Objects (DTO). Eine Definition reicht für beide Seiten. Zudem können auch NuGet-Packete in Blazor Projekte integriert werden, was einem Zugriff gibt auf ein sehr reichhaltiges Ökosystem mit vielen schon existierenden Implementationen für die verschiedensten Funktionalitäten. Etwas Vorsicht ist geboten, wenn man Blazor Client Side verwendet. Einer Applikation, die in einem Browser läuft, fehlen aus sicherheitstechnischen Gründen viele Funktionen, welche einer Nativen Applikation zur Verfügung stehen. So kann sie zum Beispiel nicht auf lokale Dokumente oder native Libraries zugreifen. Somit können im Client Side Fall nur NuGet Pakete verwendet werden, die nicht auf solche Funktionalitäten angewiesen sind.

Das Routing ist in Blazor direkt ins Framework eingebaut. So ist es in Blazor Applikationen einfacher zu verwenden ist als in den meisten anderen Web-Frameworks. Man muss nur eine Page Direktive hinzufügen, damit die Komponente unter diesem Pfad gefunden wird. Eine Registrierung, wie in Angular, ist nicht nötig. Selbst Komponenten mit mehreren Pfaden können ohne Probleme umgesetzt werden.

@page "/hello"
@page "/greeting"

<h1> 
	Hello 
</h1> 

Mit der Page Direktive, können auch Parameter im Pfad ganz einfach erfasst werden.

@page "/hello/{Name}"

<h1> 
	Hello @Name
</h1>

@code{
	[Parameter]
	public string Name {set; get;}
} 

Ein weiterer Vorteil von Blazor ist die Einfachheit der Form-Validierung. Blazor bietet die Möglichkeit, direkt Data Annotation für die Validierung zu verwenden. Dies erlaubt diese Attribute direkt auf den DTOs zu definieren. Somit kann man die Validierung überall überprüfen, wo das Objekt gebraucht wird, was auch das Backend mit einschliesst.

@page "/settings"
@using System.ComponentModel.DataAnnotations

<EditForm Model="FormModel" OnValidSubmit="HandleValidSubmit">
    <DataAnnotationsValidator />
    <label>
        Name:
        <InputText id="Id" @bind-Value="FormModel.Id"/>
    </label>
 
    <input type="submit" value="Submit"/>
    <ValidationSummary />
</EditForm>

@code {
    protected Settings FormModel { get; set; } = new Settings();

    async Task HandleValidSubmit()
    {
        Console.WriteLine($"{FormModel.Id}");
    }

    protected class Settings
    {
        [Required]
		[Range(0,100)]
        public string Id{ get; set; }
    }
} 

Nachteile von Blazor

Der grösste Nachteil, der mir im Vergleich mit Angular aufgefallen ist, ist die Change Detektion. In Angular funktioniert diese einfach, in Blazor hingegen funktioniert sie nur teilweise. Wenn eine Änderung durch eine Benutzeraktion passiert, zum Beispiel das Klicken auf einen Knopf, wird diese automatisch erkannt. Passiert die Änderung hingegen durch eine andere Ursache, wie durch einen Timer oder ein Update, welches vom Backend gepusht wird, wird sie oft nicht automatisch erkannt und die Change Detektion muss manuell gestartet werden. Es ist auch möglich, dass die Change Detection in einer Update-Loop stecken bleibt. Um diesen zu stoppen, muss man manuell validieren, ob beim Setzen eines Parameters dieser einen neuen Wert erhält oder nicht.

Neben diesen funktionellen Nachteilen, bemerkt man schnell, dass Blazor auch noch die verschiedenen Komponenten-Libraries fehlen, welche man bei Angular findet. Kommerzielle Komponenten-Libraries gibt es unterdessen, aber im Open-Source Bereich sind viele Libraries erst im Aufbau. Doch wenn das Interesse an Blazor weiterhin so hoch bleibt, wird dieses Problem wohl bald gelöst sein.

Fazit

Der erste produktive Release war im letzten Jahr (2020), aber trotzdem hat sich schon eine grosse Community gebildet. Soll man das Framework im beruflichen Alltag einsetzen? Vorläufig merkt man an verschiedenen Stellen, dass das Framework noch sehr jung ist. Ein Einsatz ist gut abzuwägen. Wenn man schon C# verwendet und man keine EntwicklerInnen hat, die TypeScript oder JavaScript können und somit nicht mit einem der traditionellen Frameworks gearbeitet werden kann, auf jeden Fall.
Falls man hingegen TypeScript bzw. JavaScript Know-how hat, würde ich vorerst auf die bereits-bekannten Frameworks (Angular, React, Vue) setzen. Blazor sollte aber definitiv im Auge behalten werden. Es ist zu erwarten, dass nach einer oder zwei weiteren Versionen Blazor die momentan noch fehlenden Funktionen ebenfalls abdecken wird.

Weiterführende Links