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. Zum Zeitpunkt der Erstellung dieses Dokuments hat Blazor noch einen experimentellen Status. Im April dieses Jahres hat Microsoft angekündigt, die erste serverseitige Variante von Blazor als Teil vom .NET Core 3.0 Release im September 2019 zu veröffentlichen.

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

1995 schrieb Brendan Eich in 10 Tagen JavaScript und löste den zweiten Browserkrieg aus. Dieses Mal geht es um die JavaScript-Leistung.

Herkömmliche JavaScript Verarbeitung im Browser

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

Quelle: https://www.heise.de/developer/meldung/Microsoft-will-Framework-Blazor-nun-zur-Produktreife-bringen-4409015.html

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

Quelle: https://www.heise.de/developer/meldung/Microsoft-will-Framework-Blazor-nun-zur-Produktreife-bringen-4409015.html

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).

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

Quelle: https://www.heise.de/developer/meldung/Microsoft-will-Framework-Blazor-nun-zur-Produktreife-bringen-4409015.html

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.

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 erste serverseitige Blazor Variante im Herbst 2019 offiziell veröffentlicht wird, ist es definitiv noch zu früh um strategisch wichtige Anwendungen mit der neuen Technologie zu implementieren. Es lohnt sich jedoch, sich bereits jetzt mit der Blazor-Technologie vertraut zu machen, weil es nur eine Frage der Zeit ist, dass Microsoft die volle Technologie zur Verfügung stellt.

Als der Auftraggeber mit ein paar 3.5 Zoll Disketten ins Sitzungszimmer trat, staunten wir nicht schlecht. «Unser Novell Server steigt immer öfter aus, wodurch die Produktion lahmgelegt wird. Könnt ihr die Software auf Windows portieren und an SAP anbinden?» – «Und die Firma welche die Software geschrieben hat?» – «Die gibt es nicht mehr.»

Es handelte sich um Steuerungs- und Visualisierungssoftware aus dem Jahr 1996 für ein paar Sondermaschinen geschrieben in Borland C, MS-DOS. Die Maschinen wurden vor sechs Jahren in die Tschechei verlegt. Niemand wusste genau wie sie funktionierten, Dokumentation gab es keine.

Wie groß würden Sie den Aufwand schätzen, um so einen Auftrag zum Erfolg zu bringen?

Mittlere bis große Softwareprojekte sind teuer und sollten daher möglichst lange leben. Auch für Software gilt: Was gut gepflegt wird, lebt länger. Was aber, wenn das Projekt erfolgreich abgeschlossen wird und dessen Quellcode in den Archivschrank verschwindet? Was, wenn nach zehn Jahren ein neues Modul an diese archivierte Software angebunden werden soll? Sind die Entwickler dann noch da? Ist das Domänenwissen von damals noch vorhanden? Kann man das Projekt mit der neuen Entwicklungsumgebung noch kompilieren? Gibt es NuGet [1], NPM [2] oder Yarn [3] in zehn Jahren noch?

Alles Wichtige an einem Ort

Das Domänenwissen in Confluence [4], die Anforderungen in Jira [5], externer Code auf einem NuGet-Server [1], Quellcode in Git [6] und der Buildprozess in der Azure Cloud [7]. So kann ein mittleres bis grosses .NET Projekt heute aussehen. Während der Entwicklungsphase funktioniert das wunderbar. Wenn das Projekt aber abgeschlossen ist, muss man alles für die Wiederbelebung Wichtige an einem Ort ablegen. Häufig dauert es nicht lang, bis eines der Systeme durch ein Neueres abgelöst wird. Auch der Kunde wird an einem funktionierenden Backup interessiert sein, da er keine Garantie hat, dass es seinen Dienstleister in ein paar Jahren noch gibt.

«Alles Wichtige» ist alles, was es braucht um das Projekt in zehn Jahren noch zu verstehen, zu kompilieren, zu deployen und laufen zu lassen. Dies bedingt Massnahmen in folgenden Bereichen:

• Dokumentation
• Beseitigen externer Abhängigkeiten
• Einfrieren der Entwicklungs- und Laufzeitumgebung
• Best Practices für nachhaltige Software

Dokumentation

Wenn ein Wiki nicht nachhaltig genug ist um wichtige Informationen zu speichern, wohin dann mit dem Projekt relevanten Domänenwissen? Eine gute Lösung ist ein technisches Handbuch, das zusammen mit dem Quellcode gepflegt und gespeichert wird. Ein solches Dokument eignet sich ebenfalls, um alle Softwarefunktionen zu beschreiben, da diese in der Regel als Softwareanforderungen innerhalb eines Ticketsystems gefangen sind. Das Handbuch kann man während dem Buildprozess automatisch versionieren und als PDF exportieren. Das PDF kann wiederum als Online-Hilfe im Produkt integriert werden. Dies verlangt vom Entwickler (oder zum Beispiel dem Product Owner), dass dieser nach der Implementation einer neuen Funktion das Handbuch aktualisiert. Ein Eintrag in der Definition of Done der User Stories sorgt dafür, dass nichts vergessen geht.

Software-Kommentare sind ein weiteres Hilfsmittel, um das Projekt zu dokumentieren. Sobald etwas nicht offensichtlich ist oder an einer Stelle spezielles Domänenwissen gefordert wird, sollte der Entwickler dies ausführlich in einem Kommentar beschreiben. Damit ist nicht nur seinem Nachfolger geholfen, sondern auch ihm selbst. Was jetzt kristallklar ist, kann nach einem Jahr schon ein Rätsel sein. Zur Projekt relevanten Dokumentation gehören auch Handbücher von Drittanbietern (API Dokumentation, Peripherie). Auch diese sollen am gleichen Ort wie das Handbuch im Projekt gespeichert werden. Zur Sicherheit exportieren Sie das Wiki und das Ticketsystem als PDF und archivieren es gleich mit.

Beseitigen externer Abhängigkeiten

Extern ausgelagerter Code ist ein Risiko für die Wiederbelebung der archivierten Software. Spätestens in der Abschlussphase sollte der gesamte externe Code lokal im Projekt integriert sein. Wer garantiert Ihnen, dass es die verwendeten Pakete in zehn Jahren noch auf NuGet oder NPM gibt? Gibt es diese Paketmanager dann überhaupt noch?

Ein paar Tipps für die Nachhaltigkeit:

• Verzichten Sie wo immer es geht auf externe Pakete. Ein AutoMapper ist mit zwei einfachen Unit-Tests zum Beispiel überflüssig.
• Integrieren Sie wenn möglich die Funktionalität als Quellcode im Projekt. Nicht mehr weiter entwickelte Bibliotheken können so für neuere Framework-Versionen kompiliert werden.
• Verstecken Sie externe Funktionalität hinter einer Facade; das macht sie einfacher austauschbar.
• Bleiben Sie an der Oberfläche; benutzen Sie nur Basisfunktionalität. So verhindern Sie, dass Sie sich abhängig machen von einem bestimmten Hersteller nur weil sein Produkt diese spezielle Funktionalität anbietet.
• Schalten Sie alle automatischen Updates aus (Dependencies, Entwicklungsumgebung, usw.). So verhindern Sie, dass Sie später in Teufels Küche kommen.
• Vergessen Sie nicht die lokal installierten Bibliotheken oder spezielle DLLs, die sich gern im GAC (Global Assembly Cache) verstecken [8]. Am besten werden die originalen Installer ebenfalls im Projekt abgelegt.

Einfrieren der Entwicklungs- und Laufzeitumgebung

Den Quellcode von heute können Sie mit grosser Wahrscheinlichkeit bereits in fünf Jahren nicht mehr kompilieren ohne das Projekt zuerst mühsam zu konvertieren. Dies ist insbesonders dann ineffizient, wenn nur ein kleiner Fehler schnell behoben werden muss. Erstellen Sie deshalb beim Projektabschluss eine virtuelle Maschine mit der gesamten Entwicklungsumgebung. Übrigens ist die Virtualisierung der Laufzeitumgebung von Servern heute schon gang und gäbe.

Automatisierte Tests

Tests sind wie eine Versicherung: Sie verhindern möglichen Schaden, haben aber auch ihren Preis. Die Kosten für das Schreiben und insbesondere für die Aufrechterhaltung automatisierter Tests werden oft unterschätzt. Wie viele Projekte haben Sie schon erlebt, in denen nicht alle Tests grün (passed) waren, weil der Zeitdruck zu hoch war oder das Budget dafür fehlte am Ende?
Automatisierte Tests können sehr hilfreich sein für den Nachfolger. Weil dieser am Anfang unmöglich den ganzen Code verstehen kann, ist die Chance groß, dass seine Änderung an einem anderen Ort etwas kaputt macht. Ein guter Test würde diesen Fehler aufdecken. Meistens aber muss der Test nur nachgepflegt werden, damit dieser nach der Änderung wieder grün wird. Dadurch wird der Nachfolger gezwungen, sich mit anderen Codestellen zu beschäftigen und er wird schneller mit dem Projekt vertraut.

Sonstiges

Rechnen Sie damit, dass die Entwickler von heute in ein paar Jahren nicht mehr da sind. Daher muss der Arbeitgeber auf den Verlust seiner Entwickler vorbereitet sein. Ingenieure werden auf manchen Portalen sogar darauf hingewiesen, dass

«Mehr als fünf Jahre Verweildauer vor einem Jobwechsel mit Vorsicht zu genießen sind» [9].

Die oben genannte Dokumentation ist daher ein Muss für den in der Regel nicht überlappenden Wissenstransfer. Wichtig ist es auch, bei Lösungen an der Oberfläche zu bleiben und eher pragmatisch vorzugehen. Entwickler wählen gern die kompliziertere Lösung, weil sie sich damit verwirklichen können (Software-Ego). Durch unnötige Komplexität verliert der Nachfolger aber viel Zeit damit, sich einzuarbeiten und das Risiko, dass er einen Fehler macht, ist unnötig groß. Die Lösung soll nicht komplizierter sein als das Problem.
Bleiben Sie konservativ: wenden Sie nur etablierte Technologien an, vermeiden Sie neue Technologien mit Hype Status.

Teilen Sie den Code so gut es geht in unabhängige, eigenständige Komponenten auf. Diese Komponentenbasierte Entwicklung stand vor 15 Jahren im Vordergrund, ist aber heute irgendwie untergegangen. Eigenständige Komponenten sind einfacher zu testen und, wenn sie gut geschrieben sind, ideal zur Wiederverwendung. Der Nachfolger kann sich auf eine Komponente konzentrieren, ohne den Rest der Software verstehen zu müssen.

Fazit

Die oben erwähnten Best Practices sorgen dafür, dass archivierte Software nach langer Zeit mit möglichst wenig Aufwand wiederbelebt werden kann. Viele der erwähnten Maßnahmen gelten aber auch für Projekte, die kontinuierlich gepflegt werden. Die meisten Software-Entwickler sind schon zufrieden mit einer funktionierenden Lösung. Ein erfahrener Entwickler aber hat einen breiteren Horizont und macht sich Gedanken über Nachhaltigkeit und den Kostenaspekt einer Lösung.

[1] NuGet Package Manager for .NET, https://www.nuget.org
[2] NPM, JavaScript Package Manager, https://npmjs.com
[3] Yarn JavaScript Package Manager, https://yarnpkg.com
[4] WiKi-Software, https://de.atlassian.com/software/confluence
[5] Webanwendung zur Fehlerverwaltung, Problembehandlung und operativem Projektmanagement, https://de.atlassian.com/software/jira
[6] Software zur verteilten Versionsverwaltung von Dateien, https://github.com/git
[7] Cloud Computing-Plattform für Unternehmen, https://azure.microsoft.com
[8] Code Project, Copy DLL from GAC, https://www.codeproject.com/Articles/43775/Copy-DLL-from-GAC
[9] INGENIEUR.DE, Technik-Karriere-News, https://www.ingenieur.de/karriere/arbeitsleben/wie-lange-sollten-ingenieure-bis-zu-einem-jobwechsel-warten/