Interview
17.03.2022, 08:10 Uhr
"Ich kann dies sowohl mit Blazor WebAssembly als auch mit Blazor Server lösen."
Blazor und C# genügen und das Web gehört Ihnen. dotnetpro sprach mit Experte Christian Giesswein, ob das tatsächlich stimmt.
(Quelle: Christian Giesswein)
Blazor ist die Technologie, die es .NET-Entwicklerinnen und -Entwicklern ermöglicht, .NET-Anwendungen schnell ins Web zu bringen. Kein JavaScript ist mehr nötig – so heißt es vollmundig. Aber ist das richtig? Wo liegen die Vorteile der Microsoft-Technologie, wo die Grenzen.
Wer bislang Microsoft-Technologien im Web verwendete, musste sich im Frontend mit JavaScript beschäftigen – von WebForms jetzt mal abgesehen. Kommt man mit Blazor nun um JavaScript herum?
Christian Giesswein: Oft wird damit geworben, dass man mit Blazor keinerlei JavaScript mehr benötigt. Als Marketingargument ist das verständlich, wenn man die Zielgruppe von Blazor betrachtet. Das sind in erster Linie wir .NET-Entwicklerinnen und -Entwickler. Wir haben uns vor vielen Jahren bereits in das Werkzeug und die Sprache C# verliebt. Mit JavaScript konfrontiert zu werden, ist für viele etwas Befremdliches.
Fakt ist, dass man eine Anwendung sehr lange ohne JavaScript entwickeln kann. Dennoch gibt es Randbereiche, wo man doch nicht ganz darum herumkommt. Aber es ist natürlich etwas anderes, wenn ein ganzes Team mit JavaScript entwickeln muss oder man ein oder zwei Spezialisten im Team hat, die sich um die speziellen Fragen kümmern und der Rest sich auf die Anwendung konzentrieren kann.
Nun setzen die Single Page Applications (SPA) in der Regel auf Frameworks wie React oder Angular. Bin ich da mit Blazor nicht außen vor?
Christian Giesswein: Ja und Nein. Wir sind im Jahre 2022 angekommen und wenn man heute Technologien mischen will oder auch muss, ist dem keine Grenze gesetzt. Deswegen ist es auch kein Problem, wenn man heute Teile von Anwendungen mit React, Angular oder Blazor entwickelt. Man ist hier mit Blazor nicht außen vor, sondern mittendrin. Aber gerade in diesem Bereich, kommt man um etwas JavaScript oder Ähnlichem definitiv nicht rum.
Es gibt Stimmen, die sagen, dass sich Blazor im Frontend nicht durchsetzen wird. Aber im Backend hätte es durchaus Potenzial. Kannst du bitte den Unterschied erklären und diese Meinung bewerten?
Christian Giesswein: Darüber wird gerne und heiß diskutiert. Ist man mit Blazor WebAssembly, das komplett im Browser betrieben wird oder mit Blazor Server (Server-Side Blazor), das auf dem Server läuft, besser bedient? Beide Welten sind einzigartig – würde ich behaupten.
Blazor Server bietet eine rasende Entwicklungsgeschwindigkeit und die volle Power von .NET. WebAssembly punktet natürlich mit seiner Dezentralität und der klassischen Browserausführung. Pauschal ist hier eine Antwort unmöglich zu finden. Es gibt Projekte, wo die eine oder andere Welt argumentativ vorne liegt. Es gibt aber auch Projekte, wo weder die eine noch die andere Welt von Blazor die passende ist.
Deswegen ist ein fundamentales Verständnis von Blazor und Razor wichtig und ich vermittle nun schon mehrere Jahre in meinen Workshops und Vorträgen: Leute, wiegt ab was ihr erreichen wollt.
Ist eine komische Konstellation: Aber könnte ich theoretisch das Backend mit Node.js betreiben und das Frontend mit Blazor?
Christian Giesswein: Wir könnten das Backend mit was auch immer betreiben: ob nun Node.js, Java oder mit einem alten ASP.NET .NET Framework Webservice – alles kein Problem. Das ist gerade der Vorteil von Blazor. Wichtig ist: Ich kann dies sowohl mit Blazor WebAssembly als auch mit Blazor Server lösen – dies wird oft vergessen.
Der neueste Schrei im Web ist ja JAMStack, also die Kombination aus JavaScript, APIs und Markup. Höhere Performance und bessere Entkopplung sind Gründe für den Erfolg dieser Technologien. Wie passt hier Blazor ins Bild?
Christian Giesswein: Egal welche Technologie, Framework oder Vorgehen oder der neueste Schrei: Man muss abwägen, was man erreichen will und vor allem, mit welchen Leuten. Blazor ist und bleibt eine Technologie, die im .NET-Umfeld starken Rückhalt hat. Arbeitet ein Team nun mit Windows Forms, WebForms oder WPF, kann man dieses sehr schnell auf Blazor schulen. Da ist der Sprung zu anderen Technologien eine ganz andere Hausnummer.
Was lernen die Teilnehmer in dem Training? Können sie anschließend eine Blazor-Anwendung aufbauen? Wie sieht es mit der Anbindung an Datenbanken aus?
Christian Giesswein: Wir sehen uns Blazor Server und Blazor WebAssembly an, und wiegen auch die Vor- und Nachteile gegeneinander auf. Mir ist aber wichtig, dass ein Grundverständnis der Blazor-Technologie geschaffen wird, frei nach dem Motto: Hilfe zur Selbsthilfe. Dabei bauen wir eine Anwendung mit Blazor mit HTML, CSS, Razor und auch JavaScript und auch mit einem Backend natürlich. Diese Anwendung lassen wir dann am Schluss sogar simultan im Server-Side Mode und im WebAssembly Mode laufen, was oft für Erstaunen sorgt.
Wem würdest du Blazor empfehlen, in welchen Situationen nicht?
Christian Giesswein: Wenn das Team bereits existiert, das Wissen im .NET-Bereich breit und tief ist, ist Blazor eine Idee und Überlegung wert. Sollte ein Team jedoch fit und agil mit anderen Technologien sein, sehe ich (aktuell noch!) ein paar Hindernisse und auch fehlende Argumentationen, warum jemand auf Blazor setzen sollte, wenn das gesamte Ökosystem fremd ist. Aber gerade für alle .NET-Projekte da draußen, die in den letzten 20 Jahren entstanden sind, ist Blazor ein Sprungbrett ins Web.
Christian Giesswein studierte Wirtschaftsinformatik in Wien und entwickelt seit vielen Jahren Software mit .NET und C#. In Tirol hat er sein Unternehmen „Giesswein Software-Solutions“ gegründet, das sich auf Individualsoftware, Consulting und Schulungen im Microsoft-Bereich spezialisiert hat.
