Eine Single-Page-Applikation (kurz SPA) ist eine Webanwendung, die in der Regel aus einem einzigen HTML-Dokument besteht und deren Inhalte dynamisch nachgeladen werden. Bis jetzt wurden diese Anwendungen in JavaScript (beziehungsweise TypeScript) mit Angular, React, VueJS, Aurelia und Co. programmiert.
Blazor ist ein neues Framework von Microsoft mit dem es möglich ist, eine SPA in C# mit Standard .NET Bibliotheken zu programmieren. In September 2019 wurde mit dem .NET Core 3.0 «Blazor Server» veröffentlicht. Microsoft hat angekündigt in Mai 2020 die Clientseitige Version «Blazor WebAssembly» auf den Markt zu bringen.
Geschichte
Der Browser ist eine der wichtigsten Anwendungen auf unseren Computern. 1994 kam die erste Version von Netscape auf den Markt, 1995 die erste Version vom Internet Explorer. Die Hersteller wollten natürlich so viele Benutzer wie möglich für sich gewinnen. Deshalb versuchten die Hersteller mehr HTML-Funktionen als ihre Konkurrenten anzubieten. Das ‘World Wide Web Consortium (W3C)’ veröffentlichte am 28. Oktober 2014 die endgültige HTML5-Spezifikation. Damit war der erste Browserkrieg beendet.
Browser Kriege
Quelle: http://royalmulti.blogspot.com.au/2012/07/holy-browser-wars.html
Historische WEB Meilensteine
1995 schrieb Brendan Eich in 10 Tagen JavaScript und löste den zweiten Browserkrieg aus. Dieses Mal geht es um die JavaScript-Leistung.
Klassische Ausführung JavaScript
Vor der WebAssembly-Technologie wurde JavaScript in den Browser geladen, analysiert, in Bytecode kompiliert und anschließend in systemeigenen Code konvertiert. Das binäre Format wird in einer virtuellen Maschine (die JavaScript Engine) ausgeführt.
WebAssembly
Mit der WebAssembly-Technologie (ab 2017) kompiliert der Server den Code in WASM (WebASseMbly). Der WASM Code wird in den Browser geladen und dann in systemeigenen Code konvertiert. Die JavaScript Engine führt den konvertierten Code wie zuvor aus.
JavaScript vorkompiliert auf dem Server zur WebAssembly
WebAssembly ist ein binäres Format, welches für die Ausführung im Browser optimiert ist. Es ist KEIN JavaScript.
Dies sind die Merkmale der WebAssembly (kurz WASM):
- WASM wird von der W3C vorangetrieben und wird ohne Plug-in von allen führenden Browsern (Chrome, Edge, Firefox und WebKit) auf Desktop und Mobilplattformen unterstützt.
- Es ist ein binäres Format für eine virtuelle Maschine. Sprachen wie C++ können in WASM übersetzt werden.
- WASM wurde nicht ausschließlich für den Browser konzipiert, sondern kann generell als Standard für portablen Code genutzt werden (z.B. Electron).
- WASM läuft in einer Sandbox im Browser und man kann mit WASM JavaScript aufrufen und umgekehrt.
- WASM ist bei der Ausführung so schnell wie nativer Code.
- Es gibt ein Textformat für WASM, damit man mit dem Code leichter umgehen kann und Debuggingunterstützung hat.
ASP.NET Core MVC & Razor Pages
Für die serverseitigen Erstellung von HTML Pages gibt es von Microsoft seit jeher Web Forms und seit 2008 ASP.NET MVC. Mit dem ASP.NET Core 2.0 Release kamen die Razor Pages. Das konventionelle MVC Model wird mit Razor Pages wieder vereinfacht: das ViewModel und der Controller sind integriert in die Razor Seiten. Im Internet findet man das Statement:
«Razor Pages ist Web Forms aber dann richtig gemacht».
All diese Technologien generieren HTML auf dem Server und senden die Seiten zum Browser. Serverseitige Internetseiten benötigen keine Dienste wie REST Schnittstellen, um die Daten im Browser zu laden, das wird bereits auf dem Server erledigt. Dadurch sind die Sicherheitsvorkehrungen bei serverseitig generierten Internetseiten einfacher.
ASP.NET Core MVC & Razor Pages
Der grösste Nachteil sind die Roundtrips, die es braucht um neue Inhalte für den Browser zu generieren. Eine Lösung ist die AJAX-Technologie, welche nur Teile der Seite aktualisiert.
Ein anderer Ansatz sind die Single Page Applikationen (SPA); progressive Webseiten, welche die Inhalte meist über REST-Schnittstellen dynamisch nachladen. Diese Seiten werden auch clientseitige Webanwendungen genannt, weil sich viel Logik im Browser befindet. Die Applikation reagiert dadurch so schnell, als ob es eine Desktop-Anwendung wäre.
Bis jetzt wurden JavaScript-lastige Technologien wie Angular und React verwendet. Mit Blazor wird es jetzt möglich, eine SPA in C# zu programmieren. Das neue SPA Blazor Framework baut auf dem gleichen Konzept auf wie die Razor Pages (Blazor = Browser enabled Razor).
Clientseitige Blazor
WebAssembly und Mono
Mono ist eine Open-Source-Implementierung der .NET-CLI-Spezifikation, was bedeutet, dass Mono eine Plattform für die Ausführung von .NET-Assemblies ist. Der ursprüngliche Zweck von Mono war, die .NET Runtime Plattform unabhängig zu machen. Mono wird in Xamarin zum Erstellen mobiler Anwendungen verwendet, die auf Android, Windows Phone und iOS ausgeführt werden. Die Mono Runtime ist in C++ geschrieben, wodurch es möglich ist, Mono in eine WebAssembly umzuwandeln.
Dem Mono-Team ist es gelungen, das Mono-Runtime in eine WebAssembly zu kompilieren.
Das WASM Mono-Runtime läuft im Browser und führt direkt .NET Assemblies aus. Die .NET Assemblies müssen also nicht erst in WASM kompiliert werden. Der Nachteil ist, dass man viele .NET Assemblies im Browser laden muss. Dieser Code kann minimiert werden durch Anwendung von Tree Shaking Algorithmen, welche unbenutzten Code entfernen. Diese sind im Moment aber noch in Entwicklung.
Clientseitiger ASP.NET Blazor
Wie es funktioniert
Wie bei serverseitigen Razor Pages funktioniert Blazor mit Razor Seiten. Razor Seiten (*.razor) beinhalten HTML mit embedded C# Code. Eine Razor Seite hat optional eine Code-Behind Datei (*.razor.cs), in welcher nach Best Practices der ViewModel-Code ausgelagert ist (muss aber nicht).
@page "/counter"
<h1>Counter</h1>
<p>Current count: @currentCount</p>
<button class="btn btn-primary" @onclick="@IncrementCount">Click me</button>
@code {
int currentCount = 0;
void IncrementCount()
{
currentCount++;
}
}
Die Razor Seite wird kompiliert und ausgeführt im Blazor Engine. Das Resultat ist ein render tree, welcher zu JavaScript gesendet wird. Das JavaScript gleicht das DOM vom Browser ab, um den render tree abzubilden (also kreieren, aktualisieren und löschen von HTML Elementen und Attributen).
Wenn auf der Seite eine Aktualisierung stattfindet (z.B. nach einer Methode, die ausgeführt wird auf einem Button Click Handler) werden die Änderungen erneut an JavaScript gesendet, welche das DOM aktualisiert.
Clientseitiger Blazor Code kann ausgeführt werden in Electron Desktop Applikationen (wird z.B. für Visual Studio Code verwendet).
Vorteile Clientseitige Blazor
- Der Server wird entlastet, weil die Arbeit im Browser erledigt wird.
- Es ist eine pure clientseitige SPA ohne .NET serverseitige Abhängigkeiten.
Nachteile Clientseitige Blazor
- Die App läuft in der Sandbox des Browsers und hat (wie alle clientseitige Anwendungen) limitierte Möglichkeiten.
- Es dauert viel länger bis die App gestartet ist, weil erst die DLLs heruntergeladen werden müssen.
Serverseitige Blazor
Diese Variante bezieht sich auf ein serverseitiges Ausführungsmodell von Blazor. Die Anwendung fühlt sich wie eine SPA an, aber anstatt .NET-Code im Browser auszuführen, wird der Code auf einem Server ausgeführt.
Serverseitiger ASP.NET Blazor
Wie es funktioniert
Herkömmliche serverseitige Apps wie MVC erfordern eine vollständige Aktualisierung der Seite, um den Browser zu aktualisieren. Blazor ähnelt eher einer Ajax-Anwendung, wenn es um die Anzeige von Updates geht. Die Benutzeroberfläche ist jedoch viel gesprächiger als bei einer durchschnittlichen Ajax-Anwendung. Grundsätzlich erhält der Browser über eine Web-Socket-Verbindung inkrementelle Ansichtsaktualisierungen vom Server. Jedes Mal, wenn die Ansicht aktualisiert werden muss, wird über eine Socket-Verbindung (SignalR) eine Anforderung an den Server gesendet. Nachdem die Anforderung auf dem Server ausgeführt wurde, wird die inkrementelle Ansichtsänderung an den Browser zurückgegeben.
Vorteile Serverseitige Blazor
- Die App startet sehr schnell, da im Vergleich mit clientseitigem Blazor keine DLLs zum Browser transferiert werden müssen (z.B. mono.wasm oder .NET Assemblies).
- Der volle .NET Framework Stack steht auf dem Server zur Verfügung.
- Gewohnte .NET Entwicklungsumgebung samt Debugging funktioniert nach wie vor.
Nachteile Serverseitige Blazor
- Schlecht skalierbar für viele Benutzer. Ursachen: SignalR Technologie, für jeden Benutzer müssen die States verwaltet werden, serverseitige Rechnerlast.
- Höhere Latenzzeiten als clientseitige Blazor, fühlt sich aber immer noch an wie eine SPA.
- Kein offline Betrieb möglich, weil eine Verbindung zum Server notwendig ist.
Ausschau (Stand 12.2019)
Mai 2020, Blazor WebAssembly = Client-side Blazor
Kann auch offline funktionieren.
2020, Blazor Progressive Web Application (PWA)
Funktioniert gleich wie im Browser. Hat Ikon auf Desktop und Eintrag im Start-Menu. Funktioniert auch offline.
2020, Electron + Blazor
Basiert nicht mehr auf WebAssembly und Mono aber auf nativen .NET Core. Hat Ikon auf Desktop und Eintrag im Start-Menu. Funktioniert auch offline.
Microsoft plant C# direkt in WASM zu kompilieren wodurch Mono nicht mehr gebraucht wird.
Konzept: Native UI + Blazor (.NET Core)
Rendert kein HTML aber eigenes UI. Mit Blazor kann man z.B. Flutter nachmachen.
Flutter ist ein Open Source Entwicklungs-Kit von Google. Es wird verwendet um Apps für Android, iOS, Windows, macOS, Linux, Google Fuchsia und das Web zu erstellen. Flutter apps sind in Dart geschrieben und nutzen viele der erweiterten Funktionen dieser Sprache.
[WikiPedia]
Fazit
Nach Silverlight startet Microsoft mit Blazor einen zweiten Versuch, um Webanwendungen mit der .NET Framework Technologie zu erstellen. Dieses Mal braucht es im Browser keine Microsoft Abhängigkeiten und die unterliegende WebAssembly Technologie wird vom W3C unterstützt.
Weil die server-seitige Blazor Variante im Herbst 2019 offiziell veröffentlicht wurde und die Veröffentlichung der client-seitige Version in Mai 2020 zugesagt wurde, kann man mit weinig Risiko neue Projekte mit Razor realisieren. Es braucht nur ein paar Codezeilen-Änderungen um server-seitiges Blazor in client-seitiges Blazor um zu wandern.
