Microsoft will Framework Blazor nun zur Produktreife bringen

Microsofts Framework zum Implementieren von Single Page Applications (SPAs) wurde nun zu einem offiziellen Produkt hochgestuft.

In Pocket speichern vorlesen Druckansicht 9 Kommentare lesen
Microsoft will Blazor nun tatsächlich zur Produktreife bringen
Lesezeit: 4 Min.
Von
  • Dr. Holger Schwichtenberg
Inhaltsverzeichnis

Microsoft hat ASP.NET Blazor zum Implementieren von Single Page Applications (SPAs) im Web-Browser auf Basis von .NET und C# nun zu einem offiziellen Produkt hochgestuft. Bisher hatte das Projekt lediglich den Status "experimentell" und es war unklar, ob Blazor jemals zur Produktreife geführt wird. Das erste Mal angekündigt worden war es am 6. Februar 2018.

Nun können sich .NET-Entwickler darauf freuen, in absehbarer Zukunft tatsächlich Webbrowserprogrammierung mit .NET und C# statt mit JavaScript beziehungsweise TypeScript und Angular, React, VueJS, Aurelia und Co. durchzuführen – mit dem großen Vorteil, das Know-how und auch bestehenden Programmcode von der Serverprogrammierung im Webbrowser wiederverwenden zu können. Bisher gab ew diese Form der Wiederverwendung nur, wenn auch auf dem Webserver mit JavaScript/TypeScript in Form von Node.js programmiert wurde.

Zudem hat Microsoft angekündigt, die "Razor Components" wieder in "Server-Side Blazor" umzubenennen. Seit der Preview-0.5-Version von ASP.NET Blazor gab es neben der Möglichkeit, eine SPA mit .NET und C# auf Basis von Mono und Web Assembly (WASM) im Browser zu betreiben, auch eine serverseitige Variante von Blazor, bei der der Programmcode auf dem Server läuft, aber der Benutzer der Webanwendung dennoch das Gefühl einer SPA bekommt, da der Server keine ganzen Seiten, sondern nur die jeweils geänderten Seitenteile via ASP.NET SignalR/WebSockets überträgt.

Das klassische ASP.NET-Programmiermodell im Vergleich zu "Server-side Blazor" und "Client-side Blazor"


Genau wie das clientseitige Blazor basiert auch das serverseitige Blazor auf einem Shadow Document Object Model (Shadow DOM). Da dies beim serverseitigen Blazor auf dem Webserver pro angeschlossenem Browser liegt, ist das serverseitige Blazor weniger skalierbar, bietet aber zahlreiche Vorteile wie eine geringe Anforderung an den Browser, die Vermeidung einer WebAPI-Schicht und einen schnelleren Anwendungsstart. Durch die große Ähnlichkeit kann ein Entwickler leicht zwischen dem clientseitigen und dem serverseitigen Modell wechseln.

Auf der connect();-Konferenz im Dezember 2018 hatte Microsoft das serverseitige Modell dann in "ASP.NET Razor Components" umbenannt, um mehr begriffliche Distanz zwischen dem clientseitigen und dem serverseitigen Modell zu kommen. Diese Entscheidung hat Microsoft nun revidiert: Ab sofort spricht der Softwarekonzern wieder von "Server-side Blazor" und "Client-side Blazor".

In der neuen Preview 4 von ASP.NET Core hat Microsoft nun auch die in den letzten Vorschauversionen etwas auseinandergelaufenen Programmiermodelle von "Server-side Blazor" und "Client-side Blazor" wieder vereinheitlicht. So verwenden nun beide Modelle bei den Template-Dateien die Dateinamenserweiterung .razor. Die Datei components.server.js, die die vom Server gesendeten Änderungen im Browser verarbeitet und Ereignisse zum Server sendet, heißt nun wieder blazor.server.js. Auch die Datei _ViewImports.cshtml wurde nun in _Imports.razor umbenannt. Anwendungen, die auf der bisherigen Preview basieren, müssen erheblich geändert werden. Außerdem gibt es nun Blazor-Unterstützung nicht nur in Visual Studio, sondern auch in Visual Studio Code.

Es bleibt aber bei der Ankündigung, dass "Server-side Blazor" und "Client-side Blazor" nicht zusammen erscheinen werden: "Server-side Blazor" wird Teil von ASP.NET Core 3.0 sein, das im 2. Halbjahr 2019 erscheinen soll. Der genaue Termin soll auf der Build-Konferenz im Mai verkündet werden (siehe .NET Core Roadmap). Das "Client-side Blazor" wird erst später erscheinen. Auch wenn das Projekt nun offiziell ist: Es gibt weiterhin keinen konkreten Erscheinungstermin für die clientseitige Variante. (ane)