Blazor: WebAssembly für .NET

Microsoft Blazor wird 2020 im Mainstream ankommen
Keine Kommentare

Webentwicklung war bisher immer gleichbedeutend mit JavaScript-Entwicklung. Das ist jetzt nicht mehr der Fall. Als Softwareentwickler mit langjähriger Erfahrung in der Webentwicklung war ich von dem neuen Blazor-Framework von Microsoft sofort begeistert. Blazor ist ein Single-Page-Application-(SPA)-Framework, das nun zum Mainstream wird. Der Erfolg beruht auf der einzigartigen WebAssembly-Implementierung, die das Web-Ökosystem für .NET-Entwickler öffnet.

WebAssembly (wasm) ist ein binäres Anweisungsformat für Webbrowser, das als Kompilierungsziel für Hochsprachen wie C++ dient. Im Jahr 2017 begann Microsoft mit WebAssembly zu experimentieren, um .NET mithilfe der Mono-Laufzeitumgebung in den Browser zu integrieren.

Mono schafft die Voraussetzungen, damit .NET-Bibliotheken (DLLs) in WebAssembly ausgeführt werden können. Der WebAssembly-Mono-Blazor-Stack verschafft Webentwicklern eine vollständige .NET-Anwendungsplattform, die komplett ohne JavaScript auskommt. Außerdem muss der Benutzer keine Browser-Plugins installieren.

Die Einführung eines Webentwicklungskonzepts ohne JavaScript wirft sofort die Frage auf: „Was bietet WebAssembly, was JavaScript oder TypeScript nicht bietet?“.

Meine Meinung dazu ist nicht ganz unvoreingenommen, aber das ist normal, denn nicht alle Entwickler, Projekte und Tools sind gleich. Meine Antwort lautet kurz und knapp: Wahlfreiheit. Die Aufhebung der Beschränkung auf JavaScript bedeutet Wahlfreiheit und eröffnet über JavaScript und .NET hinaus viele weitere Optionen. Genauer gesagt, und aus persönlicher Erfahrung gesprochen, habe ich jetzt die Wahl, eine Webanwendung mit Tools und Sprachen zu entwickeln, mit denen ich bereits vertraut bin.

npm und Webpack

Einer der Vorteile des Öffnens des Webs für .NET besteht darin, dass wir jetzt Alternativen zu npm und Webpack haben. Als erfahrener .NET-Entwickler habe ich den NuGet-Paketmanager und MSBuild mit Spannung erwartet. Für mich sind diese Technologien unproblematisch, vertraut und produktiv einsetzbar. Obwohl nichts jemals perfekt ist, waren meine Erfahrungen mit NuGet und MSBuild größtenteils positiv.

Zunächst mag dies den Eindruck erwecken, dass npm und Webpack irgendwie schlecht sind und ich von der Nutzung dieser Tools abraten möchte, aber genau das Gegenteil ist der Fall. npm und Webpack sind großartige Tools und werden wahrscheinlich noch lange Zeit verfügbar sein. Wenn Sie mit den JavaScript-Tools für die von Ihnen erstellten Apps gut zurechtkommen, ist dies eine wunderbare Sache. Aufgrund meiner langjährigen Erfahrung als Webentwickler weiß ich die große Leistungsfähigkeit von npm und Webpack zu schätzen, und ich bin überzeugt davon, dass diese Tools viel bewirkt haben und noch viel bewirken werden.

Reduzierte Lernkurve

Eine Sache, die mich an Blazor besonders fasziniert hat, ist die Leichtigkeit seiner Benutzung. Blazor kombiniert die Leichtigkeit von Razor mit anderen .NET-Konzepten. Es hat die besten Muster aus gängigen JavaScript-Frameworks wie Angular und React übernommen. Es nutzt Razor-Vorlagen und es bietet Parität mit anderen .NET-Konventionen. Diese Kombination aus unterschiedlichen Funktionen ermöglicht die Weiterverwendung bereits vorhandener Fähigkeiten auf eine Weise, die zuvor nicht gegeben war. Gleiches gilt für Node-Entwickler, die in Full-Stack-JavaScript-Apps eine einzige Sprache und vertraute Konzepte verwenden.

BASTA! 2020

Entity Framework Core 5.0: Das ist neu

mit Dr. Holger Schwichtenberg (www.IT-Visions.de/5Minds IT-Solutions)

Memory Ownership in C# und Rust

mit Rainer Stropek (timecockpit.com)

Softwarearchitektur nach COVID-19

mit Oliver Sturm (DevExpress)

Das Arbeiten mit dem Razor Components-Modell ist einfach, wenn man bereits mit ASP.NET MVC oder Razor Pages vertraut ist. Razor Components enthält die Razor-Syntax mit einer neuen Methode zum Einkapseln von Markups in wiederverwendbare Komponenten. Mit Razor Components lassen sich die Bausteine für die Benutzeroberfläche Ihrer Anwendung schnell erstellen. Die Components sind .NET-Klassen, deren Eigenschaften Komponentenparameter sind. Dieses Grundkonzept erleichtert die Erstellung von Razor Components. Wenn man das Komponentenmodell in drei Konzepte – nämlich Direktiven, Markup und Code – aufteilt, wird klar, wie sie erstellt werden.

Während „Razor Component“ und „Blazor Component“ häufig synonym verwendet werden, lautet die korrekte Bezeichnung „Razor Component“. Dies ist wichtig bei der Online-Suche, da beide Begriffe weit verbreitet sind.

Abbildung 1: Gliederung von Razor Component als grundlegendem Baustein einer Blazor-Anwendung

In Abbildung 1 verwenden Komponenten Direktiven, um spezielle Funktionen wie Routing oder Abhängigkeitsinjektion hinzuzufügen. Die Syntax für Direktiven entspricht der in ASP.NET MVC oder Razor Pages verwendeten Syntax. Das Komponenten-Markup besteht hauptsächlich aus HTML, das um die Razor-Syntax erweitert wird. Die Razor-Syntax ermöglicht die Verwendung von C# im Einklang mit dem Markup und kann Werte in der Benutzeroberfläche rendern. Die Logik der Komponente wird in einen @code-Block geschrieben. Hier werden Komponentenparameter und datengebundene Werte definiert. Alternativ dazu kann auf Code mithilfe eines Code-Behind-Ansatzes verwiesen werden, ähnlich wie das bei ASP.NET WebForms der Fall ist. Wir werden den Code-Behind-Ansatz in einem späteren Kapitel behandeln; für den Moment genügt es aber zu wissen, dass diese Option vorhanden ist. Mit dem Razor Component-Modell können wir unsere Benutzeroberfläche in überschaubare Teile gliedern. Komponenten können dann zu größeren Benutzeroberflächen mit komplexen Komponenten und Seiten zusammengesetzt werden.

Blazor Interop

Blazor-Anwendungen können JavaScript aufrufen und einen Migrationspfad für APIs bereitstellen, die außerhalb der Reichweite von reinem WebAssembly liegen. Da Blazor neu ist, können Entwickler mit dem Blazor-Interop auf JavaScript zurückgreifen, wenn WebAssembly selbst unzureichend ist oder das Blazor-Framework keinen Zugriff bietet. Ein Blockdiagramm des Anwendungsstapels ist in Abbildung 2 zu sehen.

Das Interop ist eine Abstraktionsschicht, mit der viele Entwickler in C# arbeiten werden. Sie brauchen sich dann keine Sorgen zu machen, dass die zugrundeliegende Technologie weiterhin JavaScript-Code ausführt. Mit der Zeit und mit zunehmender Reife von WebAssembly wird die Notwendigkeit einer Abstraktionsschicht geringer werden.

Abb. 2: App Staple

Zukunftsaussichten

Wenn Sie an der Web-Entwicklung mit .NET als JavaScript-Alternative interessiert sind, lohnt es sich, Zeit in Blazor zu investieren. Ich bin nicht der Einzige, den die Aussicht auf ein erweitertes Ökosystem mit .NET fasziniert; es ist bereits eine florierende Community entstanden. Als passionierter Web-Entwickler bin ich an einer Weiterentwicklung des Webs und geeigneter Apps und Tools besonders interessiert. Die Aussicht, sich für die Entwicklung von Apps auf eine jahrelange .NET-Erfahrung stützen zu können, und so noch produktiver arbeiten zu können, ist auf jeden Fall eine aufregende Sache.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -