GUI-Frameworks für .NET – Teil 4: Webframeworks
Unter dem Oberbegriff ASP.NET Core verbergen sich gleich mehrere Frameworks für das Web. Blazor, das modernste, spaltet sich nochmals in vier Varianten auf.
(Bild: erzeugt mit KI durch iX)
- Dr. Holger Schwichtenberg
Mit allen bisher in dieser Serie vorgestellten .NET-basierten GUI-Frameworks kommt man nicht in den Webbrowser. Gefragt, was Microsoft für Browseranwendungen anbietet, könnte man jetzt pauschal mit ASP.NET Core antworten, aber dies würde der Tatsache nicht gerecht, dass ASP.NET Core ein Oberbegriff über mehrere Frameworks ist, sowohl für WebAPIs/Webservices als auch für Webnutzeroberflächen mit HTML und CSS.
Um HTML/CSS-Oberflächen zu erzeugen, gibt es in ASP.NET Core drei Frameworks:
- NET Core Model View Controller (Nachfolger von ASP.NET MVC im klassischen .NET Framework, im modernen .NET seit .NET Core 1.0)
- NET Core Razor Pages (neu seit .NET Core 2.0)
- NET Core Blazor (neu seit .NET Core 3.0)
Dabei unterteilt sich Blazor nochmals in vier Arten:
- Blazor Static Server Side Rendering
- Blazor Interactive Server Side Rendering (alias Blazor Server)
- Blazor Client Side Rendering (alias Blazor WebAssembly)
- Blazor Hybrid (lässt sich in Blazor Desktop und Blazor MAUI unterteilen)
HTML vs. XAML
Alle genannten Frameworks rendern HTML-Oberflächen im Unterschied zu den bisher in dieser Serie vorgestellten Frameworks, die codebasierte Oberflächen erstellen (Windows Forms) oder mit XAML (eXtensible Application Markup Language) zur GUI-Definition arbeiten (WPF, WinUI 3, .NET MAUI). XAML und HTML haben viele Gemeinsamkeiten: Sie sind beide Markup-Sprachen mit Tags (Elemente mit Attributen und Inhalt im Stil <element attribut="wert">inhalt</element>).
In beiden Sprachen entsteht eine Baumstruktur, die man statisch zur Entwicklungszeit definieren oder dynamisch zur Laufzeit erzeugen kann. Dafür gibt es jeweils eine API zum Auslesen und Verändern des Baums. In XAML muss zu jedem Tag eine korrespondierende .NET-Klasse gehören. Ungültige Namen von Elementen und Attributen lehnt bereits der Compiler ab. In HTML werden nicht bekannte Element- und Attributnamen sogar im Browser noch einfach ignoriert, können aber im Document Object Model (DOM) durch das Metaobjektmodell (HtmlElement) verarbeitet werden. HTML ist damit flexibler für Erweiterungen, aber die Fehlersuche bei Tippfehlern ist erschwert. Ein weiterer Unterschied ist, dass es in XAML nicht nur einen, sondern zwei Bäume gibt: den logischen Baum der Tags und den visuellen Baum, in dem alle Steuerelemente in ihre Bestandteile aufgeteilt sind, zum Beispiel Rahmen und Inhalt.
HTML hat, wenn man CSS und im Einzelfall auch JavaScript hinzunimmt, eine ähnliche grafische Ausdruckfähigkeit wie XAML, manchmal sind aber die Tag-Folgen in der einen oder der anderen Sprache prägnanter, was oft zu hitzigen Diskussionen führt, wie dieser aus dem Jahr 2024 auf Reddit. Man kann aber festhalten: SVG ist nicht in allen XAML-Dialekten so gut integriert wie in HTML.
Während HTML aus der Browserwelt kommt und XAML vom Desktop, kann man heutzutage subsummieren, dass beide Sprachen innerhalb und außerhalb des Browsers anwendbar sind. Für die Erfassung durch Suchmaschinen sind aber XAML-Anwendungen nur dann eine Alternative, wenn sie per Framework in HTML umgewandelt werden. Die Uno Platform ermöglicht zwar eine Umwandlung von XAML nach HTML, aber dies nur clientseitig, nicht per Server-Side-Rendering. Das hilft also für Google & Co nicht. Bei XAML ist die Performance nur abhängig von Hardware und Betriebssystem. Bei HTML spielt auch der verwendete Webbrowser eine wesentliche Rolle.
XAML ist eine proprietäre Markup-Sprache von Microsoft mit diversen Dialekten. Dagegen ist HTML ein offizieller Standard (früher des W3C, heute der WHATWG). Allerdings gibt es auch im Jahr 2025 immer noch Unterschiede in der Implementierung der 2014 veröffentlichten HTML-5-Version in den verschiedenen Webbrowsern (vgl. caniuse.com).
In jedem der XAML-Dialekte existieren deutlich mehr und komplexere Steuerelemente als in HTML und die Steuerelementsätze unterscheiden sich in verschiedenen XAML-Dialekten. Höherwertige Steuerelemente in HTML mit Einsatz von CSS und JavaScript gibt es wie Sand am Meer, kostenlos aus der Community oder von kommerziellen Anbietern. Diese HTML-Steuerelemente gleichen Browserunterschiede selbst aus oder setzen auf verfügbare Polyfills. Während Datenbindung im Kern aller XAML-Dialekte existiert, braucht man dafür in HTML auch heutzutage immer noch ein Webfrontend-Framework. Auch wenn es bei XAML neben Microsoft noch andere Frameworkanbieter gibt (Avalonia und Uno, die in Teil 5 und 6 dieser Serie behandelt werden) und einige Steuerelementanbieter, ist das Ökosystem von HTML bedeutend größer.
Videos by heise
ASP.NET Core MVC & Razor Pages & Blazor Static SSR
ASP.NET Core Model View Controller, ASP.NET Core Razor Pages und Blazor Static Server Side Rendering sind vergleichbar, denn sie erzeugen eine Multi-Page-Web-Application (MPA) mit vollständigen Seitenrundgängen. Der Programmcode (nur C# ist möglich im modernen .NET, im klassischen .NET Framework mit ASP.NET MVC war auch noch Visual Basic .NET als Alternative vorhanden) läuft auf dem Webserver. Ein HTTP-Request geht ein, auf dem Server wird eine Klasse instanziiert, die HTML und CSS produziert. Bei ASP.NET Core MVC übernehmen diesen Job ein Controller und eine View. Bei Razor Pages spricht Microsoft von Page Model und Razor Page. Bei Blazor ist es eine Razor Component.
Diese drei Architekturen sind sich sehr ähnlich (siehe oberste vier Zeilen in Abbildung 1). Die Wahl fällt hier aber leicht, denn Blazor Static Server Side Rendering ist das neueste der drei Modelle mit der fortschrittlichsten Template-Syntax, einem echten Komponentenmodell, Streaming von HTML-Inhalten aus asynchronen Methoden in der gleichen HTTP-Antwort und Enhanced Navigation, die in einigen Fällen das Flackern der Seite im Browser verhindert.
(Bild: Holger Schwichtenberg)
Steuerelemente liefert Microsoft bei ASP.NET Core MVC und Razor Pages gar keine mit: Man arbeitet mit den HTML-Standard-Eingabesteuerelementen, von denen es eine minimale Abstraktion in Form sogenannter Tag Helper (Elemente und Attribute) und HTML Helper (Methoden) gibt, etwa für die Validierung. Wer mehr Funktionen benötigt, kann auf kommerzielle Drittanbieterkomponenten zurückgreifen, die typischerweise vollgepumpt mit JavaScript sind (siehe Tabelle 1).
| Hersteller | Produktname |
| Syncfusion | ASP.NET Core UI Controls Library |
| DevExpress | ASP.NET Core Components |
| Telerik | UI for ASP.NET Core |
| Infragistics | Ignite UI for ASP.NET Core |
| Mescius (vormals GrapeCity) | ComponentOne ASP.NET Core MVC Controls |
Tabelle 1: Ausgewählte GUI-Komponentenanbieter für ASP.NET Core MVC
In Blazor Static Server Side Rendering gibt es einige eingebaute Razor Components (zum Beispiel <InputNumber> statt <input type="number">) auf ähnlichem Abstraktionslevel und mit Validierungsoption. Hinzu kommt ein Datentabellensteuerelement (QuickGrid), das jedoch von Hause aus keinerlei Inline-Eingaben erlaubt und manche Features wie Sortieren und Blättern nur ermöglicht, wenn man eine der anderen, interaktiven Blazor-Varianten (Blazor Server, Blazor WebAssembly, Blazor Auto-Rendering) verwendet. Dazu folgt später mehr.
Microsoft bietet unter dem Namen Fluent UI Blazor Library eine Reihe von Steuerelementen für Blazor im Fluent Design an (etwa Menü, Dialog, MessageBox, Wizard, Tree View, Drag & Drop, Card, Accordion, Slider, Splitter, Rating, Autocomplete), inklusive Projektvorlagen, aber alles ohne Support und mit Einschränkungen beim statischen Blazor-Rendering. Für alle Funktionen ist auch hier eine der interaktiven Varianten von Blazor notwendig. Das in der Fluent UI Blazor Library enthaltene, auf QuickGrid basierende Fluent UI DataGrid hat ebenfalls keine eingebaute Eingabeunterstützung; Komponenten für Diagramme gibt es gar nicht.
Einen WYSIWYG-Designer sucht man wieder vergeblich, eine Live-Preview innerhalb von Visual Studio gibt es auch nicht, aber Hot Reloading existiert seit .NET 6.0. Das Deployment auf einen ASP.NET-Core-fähigen Webserver (ASP.NET Core muss man bei den Internet Information Services zuvor installieren!) erfolgt aus Visual Studio heraus oder mit Kommandozeilenwerkzeugen, per Dateisystem, FTP oder dem für die Internet Information Services verfügbaren Webdeploy-Verfahren. Self-Hosting ist auch ganz einfach möglich, denn beim Kompilieren entsteht eine .EXE-Datei, die den in ASP.NET Core integrierten Webserver Kestrel hochfährt.
Die Darstellungsfähigkeiten in HTML und CSS (ggf. unterstützt mit JavaScript und JavaScript-basierten Frameworks, zum Beispiel für Animationen und Datenbindung) entsprechen im Wesentlichen dem, was eXtensible Application Markup Language (XAML) kann. Vorteile von XAML liegen immer noch bei der besseren Windows-Integration unter anderem bezüglich Schriftdarstellung, Screenreadern und Drucken. XAML kann zudem damit punkten, dass es in einer Sprache mit einer einheitlichen, deklarativen Syntax das umsetzt, was in der Webwelt auf HTML, CSS und JavaScript verteilt ist. Allerdings ist XAML weit weniger universell einsetzbar als die Webtechniken, obwohl es mit Avalonia und Uno mittlerweile XAML auch außerhalb von Windows gibt (mehr dazu wird in den Teilen 6 und 7 dieser Serie folgen).
(Bild: coffeemill/123rf.com)
Das nächste LTS-Release steht an: Auf der Online-Konferenz betterCode() .NET 10.0 am 18. November 2025 – ausgerichtet von iX und dpunkt.verlag in Kooperation mit IT-visions.de – präsentieren der Autor dieses Artikels, Dr. Holger Schwichtenberg, und weitere Experten die wichtigsten Neuerungen. Dazu zählen die Updates im .NET 10.0 SDK sowie in C# 14.0, ASP.NET Core 10.0, Blazor 10.0, Windows Forms 10.0, WPF 10.0, WinUI 3, .NET MAUI 10.0 und die Integration von Künstlicher Intelligenz in .NET-Anwendungen.
Das Programm ist noch nicht veröffentlicht – bis dahin sind vergünstigte Blind-Bird-Tickets bereits im Online-Shop erhältlich. Das Vorjahresprogramm lässt sich im Archiv einsehen.
