Über 20 Jahre Softwareentwicklung bringen eine gewisse Allergie gegen unnötigen Overhead mit sich. Trotzdem haben wir Electron viele Jahre lang bewusst eingesetzt. Und das aus gutem Grund. Wer erinnert sich noch an GTK, Cocoa oder WinForms? Genau diese Optionen hatten wir früher im Einsatz, wenn es um plattformübergreifende Desktop-Clients ging. Das Problem: Eine wirklich schöne, native App gleichzeitig für Windows, Linux und macOS zu bauen, war damit wirtschaftlich kaum zu stemmen. WPF hätte es technisch schon lange gegeben, aber eben nur für Windows. Auf Linux und Mac wäre die App hässlich geworden, und der Aufwand für eigene Ports auf allen drei Plattformen stand in keinem Verhältnis zum Nutzen. Electron hat dieses Dilemma jahrelang gelöst, mit spürbaren Kompromissen bei Bundle-Size und Performance, die wir bewusst in Kauf genommen haben.
Der Zeiterfassungs-Client selbst war bei uns also längst im Einsatz. Die Entscheidung war, ihn neu zu bauen, allen voran die Oberfläche. Da haben wir uns gefragt: Lässt sich das heute besser lösen? Mit Avalonia gibt es inzwischen ein Framework, das WPF-artiges Arbeiten auf allen drei Plattformen ermöglicht, ohne die alten Kompromisse. Der Wechsel von Electron zu Avalonia war eine der besten technischen Entscheidungen der letzten Zeit, und genau darüber wollen wir hier berichten.
- Autor
- David Roth
- Datum
- 22. September 2026
- Lesedauer
- 6 Minuten
Performance & Ressourceneinsparung
Der Schnitt war radikal: weg von der hybriden Electron-Plattform, hin zu reinem C#. Und die Zahlen sprechen für sich. Unsere Bundle-Size ist von 300 MB auf 100 MB geschrumpft. Kein Tippfehler, sondern der Unterschied zwischen »wir liefern ein komplettes Chromium samt Node.js-Runtime mit aus« und »wir liefern eine kompilierte .NET-Anwendung aus«. Noch deutlicher zeigt sich der Effekt beim Start: Das Hauptfenster öffnet sich in wenigen Millisekunden, während wir bei Electron mit ~200 ms oder mehr gerechnet haben, je nach System und Kaltstart.
Und das ist noch nicht das Ende der Fahnenstange: Wir wollen uns in Zukunft auch noch Native AOT genauer ansehen. Damit ließen sich Startzeit und Bundle-Size vermutlich nochmal deutlich unterbieten.
TL;DR: Kleinere Bundles, schnellere Startzeiten, weniger Ressourcenverbrauch im Hintergrund. Genau das, was man von einem Tool erwartet, das den ganzen Tag im Hintergrund mitläuft.
Sicherheit & Architektur
Wäre es nicht ideal, wenn eine Desktop-App gar nicht erst die Angriffsfläche eines Browsers mitschleppen müsste? Electron-Anwendungen laufen häufig über lokale Webserver auf Localhost-Ports und überbrücken Chromium- und Node.js-Kontexte. Das sind zwei Welten, die eigentlich nicht zusammengehören, aber über Bridges künstlich verbunden werden müssen. Das funktioniert, ist aber strukturell eine zusätzliche Sicherheits- und Wartungsdimension, die man sich einhandelt.
Bei einer Avalonia-App ist das systembedingt anders: Sie läuft direkt als kompiliertes natives C#-Binary. Kein eingebetteter Webserver, keine versteckten Web-Abhängigkeiten, kein JavaScript im Hintergrund. Auch beim Fenster-Management merkt man den Unterschied. Neue Fenster öffnen bei uns jetzt direkt die passende View, statt intern unsauber über Web-URLs geroutet zu werden. Weniger Komponenten bedeuten weniger potenzielle Fehlerquellen, und das schlägt sich am Ende auch in der Wartbarkeit nieder.
Entwickler-Experience & coole Features
Dass sich mit HTML, CSS und Blazor richtig gute UIs bauen lassen, war für mich nie die Frage, denn das Web war in Sachen UI-Möglichkeiten schon immer stark. Das eigentliche Problem lag für mich woanders: bei den Bridges zwischen der Web-Welt und dem nativen Desktop. Genau diese Brücken haben sich in der Praxis immer wieder wie eine Krücke angefühlt, und das Handling war oft unnötig kompliziert.
Besonders deutlich wurde das für mich an der schieren Menge an Konzepten, die für eine einzige Desktop-App zusammenkommen mussten. Electron bootet ein C#-Programm, das wiederum einen Webserver bootet, den ich dann über URIs anspreche, die teilweise wieder zurück auf native APIs zugreifen. Dazu kommt zwangsläufig JavaScript, dazu ein TypeScript-Compiler, dazu das ganze npm-Ökosystem drumherum. Für eine Desktop-App, die im Kern einfach nur schnell und stabil laufen soll, war mir das schlicht zu viel unnötige Komplexität. Auch beim Packaging selbst hatte ich nie ein gutes Gefühl. Die Electron-Packages und der Electron Builder fühlten sich für mich nie wirklich solide an. Mit Velopack habe ich dafür jetzt ein Tool, das spürbar mächtiger und sauberer arbeitet, und auch das Zusammenspiel mit dem Betriebssystem selbst geht bei Avalonia einfach direkter vonstatten.
Ein weiterer Gewinn, den ich im Alltag jeden Tag spüre, ist, dass der XAML-Previewer für MVVM in Rider und VS Code extrem gut funktioniert. Änderungen an der View sehe ich praktisch live, ohne ständig neu zu bauen. Animationen und Design-Tokens lassen sich damit sauber und ohne Verrenkungen umsetzen, und insgesamt fühlt sich die gesamte Entwicklung spürbar flüssiger an.
Auch bei Versionssprüngen zeigt sich der Unterschied: Ein Wechsel von .NET 10 auf .NET 11 ist bei mir heute ein Einzeiler im csproj. Früher hätte ich bei einem vergleichbaren Sprung Electron selbst, diverse npm-Packages und Buildpacks hochziehen müssen, mit allem, was daran hängt. Dazu kommen konkrete Features, die mir vorher zu viel Aufwand gekostet hätten:
- Ein eigener, eleganter Keyboard-Shortcut- bzw. Hotkey-Picker, direkt ins UI integriert.
- Ein integrierter Update-Prozess für Linux (Ubuntu, Debian, RPM), der sudo-Rechte direkt über ein eingebettetes Terminal anfordert, ohne dass Nutzer:innen selbst ein Terminal-Fenster öffnen und Befehle abtippen müssen.
Kleine Dinge, die in Summe den Unterschied zwischen »funktioniert« und »fühlt sich gut an« ausmachen. 🚀 Dass das kein rein subjektiver Eindruck von mir ist, hat mir kürzlich auch ein Kollege aus dem Team bestätigt:
»Man kann sagen, was man will, aber die native Oberfläche fühlt sich einfach spürbar besser an als die alte Electron-Oberfläche. Alles läuft smoother und man hat nicht mehr ständig das Gefühl, dass die UI aus rein technischen Gründen hinterherhinkt.«
Genau das war ja auch das Ziel.
Ein kleiner Nebeneffekt, den ich so nicht eingeplant hatte, aber gerne mitnehme: Avalonia orientiert sich zu rund 95 % an WPF-Konzepten, und mit 25 Jahren WPF-Erfahrung ist das für mich vertrautes Terrain. Das merke ich auch, wenn KI-Agents mitschreiben. Dank jahrzehntelanger WPF-Trainingsdaten und der strikten Typisierung von C# fängt der Compiler viele KI-Fehler sofort ab, statt dass sie erst als Laufzeitfehler auffallen. Kein Kernargument für den Wechsel, aber ein angenehmer Bonus obendrauf.
Fazit & Einsatzbereiche
Für uns vereint Avalonia genau die Eigenschaften, die uns wichtig waren: Performance, Sicherheit, Wartbarkeit und Flexibilität, ohne den Overhead einer eingebetteten Web-Plattform. Und das Ganze ist nicht auf interne Business-Clients beschränkt. Die Kombination aus nativer Performance und stabiler KI-Unterstützung macht Avalonia für uns generell zu einer ernstzunehmenden Alternative, wo auch immer ein performanter, sicherer Desktop-Client gefragt ist.
Wenn dich interessiert, wie wir den Update-Prozess für Linux im Detail gebaut haben oder wie unser Hotkey-Picker technisch funktioniert, melde dich gerne. Das wäre Stoff für einen eigenen Deep-Dive.
Stehst du vor einer ähnlichen Entscheidung?
Du planst eine neue Desktop-Anwendung oder willst weg von Electron? Wir entwickeln Software mit genau diesem technischen Tiefgang. Schreib uns, wir sprechen unverbindlich über dein Vorhaben.
