Browser-Apps mit Avalonia entwickeln

Das UI-Framework Avalonia spielt am Desktop seit Längerem seine Stärken aus. Mit Version 11 wurde im Jahr 2023 Unterstützung für den Browser eingebaut – Zeit, sich damit zu beschäftigen.

Avalonia ist ein bekannter Vertreter klassischer UI-Frameworks. Es weist hohe Ähnlichkeiten mit WPF auf, ist im Gegensatz zu diesem aber nicht auf Windows limitiert. Das Framework wurde bei der dotnetpro bereits mehrfach vorgestellt. So hat Fabian Hügle in seinem Artikel „Das bessere WPF“ einen Überblick über das Framework gegeben. Darauf aufbauend hat der Autor dieses Beitrags den Artikel „UIs für Linux“ geschrieben, bei dem die Entwicklung von Desktop-Applikationen unter Linux im Fokus steht. Der hier vorliegende Artikel betrachtet die Entwicklung von Browser-Applikationen auf Basis von Avalonia.

Unterstützung für den Browser in Avalonia

Damit eine Avalonia-Applikation im Browser ausgeführt werden kann, nutzt es ein Feature von .NET: Die Unterstützung für WebAssembly. WebAssembly ist ein Bytecode, der von Browsern ausgeführt werden kann. Es ermöglicht die Ausführung von Code aus verschiedenen Programmiersprachen wie C/C++, Rust oder eben C# im Browser.

Um eine Avalonia-Applikation für den Browser fit zu machen, wird sie nach WebAssembly kompiliert und im Browser ausgeführt. Was wir im Browser erhalten, unterscheidet sich deutlich von dem, was wir bei den bekannten Vertretern im Web wie Angular, React, Vue.js oder ASP.NET Core Blazor bekommen. Anders als all diese UI-Frameworks erzeugt Avalonia im Browser kein HTML. Stattdessen rendert Avalonia alles selbst – ohne HTML und ohne CSS. Unter der Haube wird dazu wie auch auf anderen Plattformen die Bibliothek SkiaSharp verwendet.

Bild 1 zeigt eine kleine Avalonia-Applikation zur Anzeige von Messdaten im Browser. Es handelt sich um das Beispiel aus dem oben verwiesenen Artikel „UIs für Linux“. Leser können die Applikation auch selbst ausprobieren: Der Sourcecode wird zusammen mit diesem Artikel bereitgestellt.

Mit Avalonia im Browser starten

Um eigene Avalonia-Applikationen für den Browser zu entwickeln, ist nicht viel Arbeit notwendig. Zunächst benötigen wir die .NET WebAssembly Buildtools. Mit folgendem Befehl können wir diese installieren.

dotnet workload install wasm-tools

Im nächsten Schritt können die Templates von Avalonia mit folgendem Befehl installiert oder aktualisiert werden.

dotnet new install avalonia.templates

Anschließend steht das Template „Avalonia Cross Platform Application“ zur Verfügung. Bei einer neuen Applikation mit dem Namen TestApp auf Basis dieses Templates erhalten wir eine Struktur aus mehreren Projekten:

• TestApp
• TestApp.Android
• TestApp.Browser
• TestApp.Desktop
• TestApp.iOS

Das Projekt TestApp bildet den Kern und beinhaltet unsere Applikation. Also alle Views, ViewModels, Assets und alles Weitere, was wir für unsere Applikation benötigen. Das Projekt ist als Klassenbibliothek und nicht als ausführbares Programm konfiguriert. Die Idee dahinter ist die folgende: Der überwiegende Großteil des Codes der Avalonia-Applikation ist auf allen Plattformen gleich und wird in diesem Projekt definiert. Andere, sogenannte Kopfprojekte, verweisen darauf und hosten die Applikation auf den jeweiligen Plattformen. TestApp.Desktop macht das für die Desktop-Plattformen Windows, Linux und macOS. TestApp.Browser ist wenig überraschend für den Browser gedacht. Die Projekte TestApp.Android und TestApp.iOS kümmern sich um die mobilen Plattformen – für diesen Artikel sind sie nicht relevant.

Schauen wir uns das Projekt TestApp.Browser genauer an. Hier sind mehrere Stellen anders, als wir es von Desktop-Projekten kennen. Das SDK ist Microsoft.NET.Sdk.WebAssembly, das Zielframework ist net9.0-browser. Zusätzlich wird das Paket Avalonia.Browser referenziert, das die notwendige Funktionalität von Avalonia für Browser enthält.

Im Projektordner liegen noch wenige weitere Dateien, so wie auch die Datei index.html im Ordner wwwroot.

<Project Sdk="Microsoft.NET.Sdk.WebAssembly">
    <PropertyGroup>
        <TargetFramework>net9.0-browser</TargetFramework>
        <OutputType>Exe</OutputType>
        <Nullable>enable</Nullable>
    </PropertyGroup>

    <ItemGroup>
        <PackageReference Include="Avalonia.Browser" Version="11.3.1"/>
    </ItemGroup>

    <ItemGroup>
        <ProjectReference Include="..\TestApp\TestApp.csproj"/>
    </ItemGroup>
</Project>

Das kann an dieser Stelle überraschen. Weiter oben im Artikel wurde nämlich geschrieben, dass Avalonia kein HTML rendert, hier haben wir aber eine HTML-Datei. Der Hintergrund ist denkbar einfach, denn es ist ein wenig HTML als Rahmen der Avalonia-Applikation notwendig. In der index.html wird etwa der Titel der Applikation definiert. Das Wichtigere ist aber das div-Tag mit der ID out – es definiert die Fläche, in die unsere Avalonia-Applikation gerendert wird.

<!DOCTYPE html>
<html>

<head>
    <title>Temperature Measurement</title>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <link rel="stylesheet" href="./app.css" />
</head>

<body style="margin: 0; overflow: hidden">
    <div id="out">
        <!-- Splashscreen -->
    </div>
    <script type='module' src="./main.js"></script>
</body>
</html>

In der Datei Program.cs wird der Bezug zur index.html-Seite schließlich klarer. Mit dem Aufruf StartBrowserAppAsync("out") weisen wir Avalonia an, die Applikation im HTML-Tag mit der ID out zu starten.

public static partial class Program
{
    private static Task Main(string[] args) => BuildAvaloniaApp()
        .WithInterFont()
        .StartBrowserAppAsync("out");

    public static AppBuilder BuildAvaloniaApp()
        => AppBuilder.Configure<App>();
}

Eigenschaften einer Avalonia-Applikation im Browser

Avalonia rendert im Browser kein HTML, sondern kümmert sich selbst um jedes einzelne Pixel. Das sorgt dafür, dass die Applikation dasselbe Look and Feel aufweist wie auch am Desktop. Der Testaufwand ist dadurch geringer, da weite Strecken des Codes gleich sind. Auch der Lernaufwand für HTML, CSS und JavaScript entfällt weitgehend.

Nachteile liegen in der Größe der Applikation und die dadurch schlechtere Startgeschwindigkeit. Auch die Performance ist schlechter als bei nativem HTML, auch wenn sie nach Beobachtung des Autors in den letzten Jahren mit der fortschreitenden Entwicklung von WebAssembly und .NET klar besser geworden ist. Die Funktionalität von .NET steht nur eingeschränkt zur Verfügung, da die Applikation in der Browser-Sandbox ausgeführt wird. Der HttpClient als wichtige Klasse zur Kommunikation mit dem Server funktioniert, andere Funktionen wie direkte Datenbankanbindung mit Entity Framework Core stehen aus dem Browser heraus aber nicht zur Verfügung.

Auch wenn Avalonia selbst kein HTML rendert: Um die Nutzung von Browser-Funktionen und JavaScript wird man in der Regel nicht vollständig herumkommen. Der Autor empfiehlt daher, im Team zumindest einige wenige Personen zu haben, die sich mit JavaScript und allgemein Webtechnologie tiefer auseinandersetzen. Native Funktionen des Browsers können mittels JavaScript interop aufgerufen werden.

Fazit

Der Weg, den das Avalonia-Team mit der Unterstützung für Browser geht, ist nur wenige Jahre alt. Er steht und fällt mit der Unterstützung für WebAssembly von .NET selbst. Wie gut und performant der Ansatz heute funktioniert, kann relativ einfach mit dem Avalonia UI Playground getestet werden. Es handelt sich dabei um eine Beispielsammlung, die als Avalonia-Applikation im Browser bereitgestellt wird. Der XAML-Code kann dabei live im Browser manipuliert werden.

UI-Frameworks wie Avalonia werden nach Meinung des Autors die vorherrschenden UI-Frameworks im Web wie Angular, Vue.js und React nicht verdrängen. Für .NET-Entwickler eröffnet sich aber eine weitere spannende Variante zur Umsetzung von Business-Applikationen im Browser. Der größte Vorteil liegt darin, einen möglichst großen Teil der Codebasis zwischen Browser- und Desktop-Variante zu teilen.