Microsoft Build 2020: Blazor WebAssembly ist fertig

Gut zwei Jahre nach der Erstankündigung ist die erste Version von Blazor WebAssembly erschienen, mit der C# im Browser läuft.

In Pocket speichern vorlesen Druckansicht 16 Kommentare lesen
Microsoft Build 2020: Blazor WebAssembly ist fertig

(Bild: metamorworks/Shutterstock.com)

Lesezeit: 5 Min.
Von
  • Dr. Holger Schwichtenberg
Inhaltsverzeichnis

Die frisch veröffentlichte erste Variante von Blazor WebAssembly trägt die Versionsnummer 3.2 in Kontinuität zu dem im Dezember 2019 veröffentlichten .NET Core 3.1. Das nächste Release soll im November zusammen mit .NET 5.0 erscheinen und ebenfalls die Versionsnummer 5 tragen.

News von der Build 2020

Blazor WebAssembly ermöglicht das Entwickeln von Single Page Web Applications (SPA) mit der Programmiersprache C#. Der C#-Code wird wie üblich in die Microsoft Intermediate Language (MSIL) übersetzt und als .NET-Assembly in den Webbrowser geladen. Dort verarbeitet ein Interpreter den MSIL-Code. Er basiert auf der .NET-Variante "Mono" und läuft seinerseits als WebAssembly-Code.

Den im WebAssembly-Standard fehlenden Zugriff auf das Document Object Model (DOM) überbrückt Microsoft mit der JavaScript-Bibliothek blazor.WebAssembly.js. Sie lädt nicht nur beim Start der Anwendung die Mono-Laufzeitumgebung und die .NET-Assemblies (System-Assemblies und eigene), sondern aktualisiert auch ständig das DOM im Browser auf Basis der Änderungen, die Blazor WebAssembly in einem sogenannten Virtual DOM vornimmt (s. Abb. 1).

Blazor WebAssembly vs. Blazor Server (Abb. 1)

Blazor WebAssembly ist etwas anderes als Blazor Server, das seit September 2019 als Teil von .NET Core 3.0 bzw. 3.1 verfügbar ist. Bei Letzterem existiert das Virtual DOM auf dem Webserver, und die Synchronisation mit dem tatsächlichen Browser-DOM erfolgt mit ASP.NET Core SignalR über Websockets. Eine Blazor-Server-Anwendung wirkt zwar auf den Benutzer wie eine SPA, erfordert aber eine kontinuierliche Verbindung zum Webserver. Lediglich kurze Verbindungsabbrüche lassen sich überbrücken.

Microsoft-Sprecher Scott Hunter demonstrierte in seinem "The Journey to One .NET" (eine Langfassung davon ist auf Channel 9 verfügbar), dass Blazor WebAssembly inzwischen auch die lange fehlenden Debugging-Möglichkeiten sowohl in der Browserkonsole als auch innerhalb von Visual Studio besitzt (s. Abb. 2). Allerdings gibt es in der Entwicklungsumgebung noch Einschränkungen im Vergleich zu den bei .NET gewohnten Debugging-Optionen. So startet der Debugger noch nicht automatisch bei Laufzeitfehlern und zeigt nicht für alle Datenstrukturen die Inhalte an.

Debugging in Blazor WebAssembly (Abb. 2)

(Bild: Microsoft Channel 9)

Dem ersten Blazor-WebAssembly-Release fehlt zudem die seit der ursprünglichen Ankündigung diskutierte Option, .NET-Assemblies "ahead of time" in WebAssembly zu kompilieren. Microsoft reduziert aber die Dateigrößen durch Einsatz des IL Linkers und durch Brotli-Komprimierung.

Neben der AOT-Kompilierung fehlen noch weitere Funktionen, die in JavaScript-basierten Webframeworks üblich sind wie die Modularisierung und das Nachladen von Komponenten sowie die Isolation von CSS. Auf GitHub findet man eine Roadmap für weitere Funktionen in der kommenden Version 5.0.

Derzeit müssen Entwickler selbst für vermeintlich einfache Funktionen wie den Zugriff auf den Titel des Browserfenster oder andere Daten im <head>-Element der Webseite auf die Interoperabilität mit JavaScript zugreifen. Immerhin ist der Zugriff in beide Richtungen möglich, also sowohl von C# zu JavaScript als auch von JavaScript zu C#.

In Blazor WebAssembly 3.2 ist die Unterstützung für Progressive Web App (PWA) bereits enthalten. Entwickler können eine Blazor-WebAssembly-Anwendungen beim Anlegen als PWA deklarieren, sodass Endbenutzer sie im Browser installieren können. Das Vorgehen zeigt das genannte Video (s. Abb. 3).

Installieren der Blazor Apps als PWA (Abb. 3)

(Bild: Microsoft Channel 9)

Blazor WebAssembly 3.2 hat den Status "Current Version", erhält also nicht den Long-term Support (LTS) der .NET Core-Version 3.1 aus dem Dezember 2019. Das bedeutet, dass Anwender nach dem Erscheinen der nächsten Version, die für den 10. November 2020 geplant ist, nur drei Monate Zeit haben werden, die Blazor WebAssembly-Version zu wechseln. Die erste LTS-Version von Blazor WebAssembly soll nach aktuellem Stand erst im November mit Version 6.0 in .NET 6.0 erscheinen.

Voraussetzung für die aktuelle Blazor WebAssembly-Version 3.2 ist das .NET Core SDK ab Version 3.1.300. Notwendig ist es beim Kompilieren, auch wenn die Anwendung anschließend auf Mono-Version 6.13 läuft. Als Entwicklungsumgebung darf Visual Studio 2019 v16.6, Visual Studio for Mac 8.6 oder Visual Studio Code mit den aktuellen C#-Erweiterungen zum Einsatz kommen.

Es gibt bereits zahlreiche kommerzielle und nicht kommerzielle Zusatzkomponenten für Blazor, von denen die meisten sowohl auf Blazor WebAssembly als auch mit Blazor Server laufen. Ein Verzeichnis findet man auf GitHub unter "Awesome Blazor". (rme)