Moderne Business-Applikation aber auch Games oder Office Tools werden seit einigen Jahren meist als Webapplikationen anstelle von klassischen Windows Applikation umgesetzt. Webapplikationen bestehen aus dem Frontend, welches, wie einleitend erwähnt, im Browser des Benutzers ausgeführt wird. Die eigentliche Logik (z. B. Kalkulationen oder das Validieren von Daten) sowie die Datenhaltung der Applikation werden hingegen auf einem oder auf mehreren Servern ausgeführt. Das Frontend verbindet sich z. B. bei einem Klick in der Applikation mit dem Server, um eine Kalkulation auszuführen oder um Daten abzufragen oder zu speichern.
Bekannte Web-Frontend-Frameworks
Webapplikationen waren in den ersten Jahren im Bereich des Frontends, im Vergleich zu Windows (oder anderen Betriebssystemen) basierten Applikation, oft sehr einfach aufgebaut. Um den Funktionsumfang sowie die Darstellung und damit die Usability auch bei Webapplikationen zu verbessern, entstand in den letzten Jahren eine Vielzahl von sogenannten Web Frontend Frameworks. Diese umfassen Komponenten für Tabellen, Slider, Cards, Panels, PopUps, Info- und Fehlermeldungen und sie erleichtern oder standardisieren häufig auch die Kommunikation mit dem Server. Daten können damit oft dynamisch nachgeladen werden. Es wird also nicht eine gesamte Seite neu geladen, sondern nur die zu ändernden Elemente. Dadurch werden die Applikationen viel mehr “responsive”.
Einige Frameworks beinhalten oder unterstützen auch die angesagten Designs wie Bootstrap und Material Design. Diese vereinfachen es dem Programmierer attraktive und einheitliche Frontends zu entwickeln. Viele bekannte Applikationen oder Webseiten basieren auf dieser Basis.
Ein weiterer Vorteil dieser Frameworks ist die Reduktion von Javascript Code resp. der Wechsel auf TypeScript. Javascript hat es ermöglicht eine gewisse Dynamik in Webapplikationen zu bringen, wurde aber von vielen Programmierern nie geschätzt und hat Applikationen oft komplex und schwerer wartbar gemacht, und es gab eine gewisse Abhängigkeit zu den verwendeten Browser-Versionen.
Verschiedene Agenturen bewerten diese Web Frontend Frameworks regelmässig und man kann feststellen, dass alle paar Monate neue Frameworks präsentiert werden und teilweise nach kurzer Zeit auch bereits erfolgreich sind. Erfolgreich bedeutet, dass sie von Entwicklern gut angenommen und in Projekten produktiv verwendet werden. Bekannte Vertreter sind Angular, React, Vue oder früher JQuery. Jedes dieser Frameworks hat seine Vorteile. Einzelne sind auf umfangreiche Applikationen andere eher für eine schnelle und einfache Entwicklung ausgelegt.
Blazor — ein neuer Gigant in der Welt der Webframeworks?
Seit 2018 gibt es einen neuen Player, Microsoft Blazor. Mit Blazor wird eine der grossen Herausforderungen gelöst: viele Webprogrammierer waren stark in der Programmierung in c#, der meist genutzten Programmiersprache im Microsoft.Net-Ökosystem, konnten sich aber mit Web Frontend Frameworks, und im Speziellen mit Javascript, nie richtig anfreunden. Mit Blazor wird zwar weiterhin HTML und CSS verwendet man kann aber das Frontend mehrheitlich via den gewohnten c# Code (statt mit Javascript) steuern. Steuern heisst, Inhalte aus dem Backend laden, im Dialog visualisieren, plausibilisieren und ans Backend zum Speichern übergeben.
Durch das nähere Zusammenbringen von Frontend und Backend erwartet man eine deutlich schnellere Programmierung. Dies kommt wiederum den Kunden entgegen, welche Programmier-Arbeiten intern oder extern in Auftrag geben.
Bereits haben sich viele Anbieter von Komponenten (Tabellen, Slider, Cards, Panels, PopUps, Info- und Fehlermeldungen) auch auf Blazor spezialisiert, was die Attraktivität von Blazor für Entwickler weiter steigert. Dies zeigt auch die wachsende Anzahl Entwickler, welche Blazor bereits für produktive Applikationen nutzt.
Mit Microsoft als Herausgeber dieser neuen Technologie kann man davon ausgehen, dass sie stetig weiterentwickelt wird und auch über viele Jahre unterstützt wird.
Die Verwendung von Blazor hat keinen negativen Einfluss auf die Usability und das Design von Webapplikationen. Weiterhin ist empfohlen, dass Expert:innen in diesem Bereich die Dialoge und die Usability visuell gestalten und der Entwickler diese Vorgaben in die Applikation übernimmt.
Blazor gibt es als “Server” und “Webassembly” Variante. Diese beiden Varianten werden in den folgenden beiden Kapiteln kurz erklärt. Für die Benutzer ist der Unterschied kaum erkennbar, technisch ist die Unterscheidung aber relevant. Nicht in Bezug auf die Programmiersprache (in beiden Fällen werden c# und das.Net Ökosystem verwendet), aber in der Verteilung der Elemente auf den Server und den Client (Browser des Benutzers).
Weiterführende technische Informationen finden sie in unzähligen Online Berichten.
Blazor “WebAssembly”
Bei dieser Variante wird die gesamte Applikation im Browser ausgeführt. Die Applikation wird vom Browser beim ersten Start (oder nachdem eine neue Version publiziert wurde) auf den PC oder Notebook des Benutzers heruntergeladen. Dies merkt der Benutzer aber höchstens in einer etwas längeren Ladezeit (wenige Sekunden) bei der ersten Verwendung, er muss aber nichts installieren. Der Browser des Benutzers wird nun als eine Art Betriebssystem verwendet, in welcher die Blazor Applikation läuft.
Üblicherweise werden die Businesslogik und die Verbindung auf die Datenbank weiterhin auf einem separaten Server ausgeführt. Der Server bietet dem Frontend eine Rest API-Schnittstelle. Die Implementierung auf dem Server kann ebenfalls auf Microsoft .Net basieren, muss aber nicht. Relevant ist nur, dass ein Rest API den Zugang “von aussen” ermöglicht. Es macht oft Sinn, die Business Logik auszulagern (nicht direkt in der Blazor Applikation), falls andere Applikationen dieselben Funktionen verwenden oder wenn verschiedene Clients (z. B. eine Webapplikation und eine App) entwickelt werden.
Falls eine Applikation entwickelt wird, bei welcher keine umfangreiche Business Logik und keine Datenhaltung benötigt wird, dann kann das Blazor Webassembly auch ausschliessliche im Browser ausgeführt werden (ohne API-Anbindung).
Es ist anzunehmen, dass diese Variante von Blazor erfolgreicher sein wird. Bei dieser Variante spricht man von einer SPA (Single Page Application).
Blazor “Server”
Bei Blazor Server werden der Frontend Teil der Applikation auf einen Browser und einen Server Teil aufgeteilt. Dieses Setup entspricht eher bisherigen Webapplikationen. Im Browser wird z. B. ein Klick des Benutzers entgegengenommen und an den Server gesendet. Der Server bereitet eine Antwort (z. B. eine Tabelle mit Daten) auf und sendet das generierte HTML zurück an den Browser. Der Browser muss bei dieser Variante nicht die ganze Applikation herunterladen, sondern erhält vom Server immer nur so viel HTML Code für die Darstellung, wie nötig.
Egal ob WebAssembly oder Blazor Server, die wachsende Community und die geplante Weiterentwicklung, lassen darauf schliessen das Blazor seinen Platz unter den Frontend Technologien finden und sich langfristig etablieren wird. Bei Rückfragen stehen wir Ihnen zur Verfügung und beraten Sie gerne.