UI-Engineering im Zeitalter der KI

Am 12.12.2025 schloss Zed-Entwicklerin mikayla-maki einen PR, der eigene Shader für GPUI ergänzen sollte. Die Antwort war freundlich. Nach dem Dank für den Beitrag hieß es: “we’re shifting focus to core product work at Zed, and without a Zed use case, I can’t validate this code”. Am Ende stand ein Smiley.

GPUI ist Zeds selbst entwickeltes GPU-UI-Framework. In Gesprächen über Electron-Alternativen fällt sein Name häufig. Knapp vier Monate zuvor hatte Zed eine von Sequoia geführte Finanzierungsrunde über 32,000,000 US-Dollar bekannt gegeben. Insgesamt waren damit mehr als 42,000,000 US-Dollar eingeworben.

Gut neun Monate später, am 26.9.2026, legte Entwickler egoist ein Repository namens MyGo an. Nach 39 Tagen enthielt es 1,042 Commits, davon 890 mit Claude als Mitautor.

Claude stammt von Anthropic. Anthropics eigene Desktop-App verwendet Electron.

Zusammen wirken diese drei Tatsachen etwas widersprüchlich. Wir haben 10 Frameworks auf zwei Rechnern gemessen, um den Stand dieses Feldes zu prüfen.

Desktop-Apps wie Claude und Codex setzen weiterhin auf Electron: Das Web bietet ein ausgereiftes Ökosystem, eine Codebasis für mehrere Plattformen und ist den Modellen gut vertraut. KI senkt die Entwicklungskosten, doch plattformübergreifende Kompatibilität und Wartung erfordern weiterhin Arbeit.

Eigenes GPU-Rendering bietet einen anderen Weg, aber GPUI dient weiterhin vorrangig Zed. Plattformübergreifendes Rendering und ein Widget-Ökosystem brauchen langfristigen Aufbau. MyGo zeigt, wie KI und fertige Komponenten den Einstieg beschleunigen. Produktionsreife und langfristige Wartbarkeit müssen sich noch beweisen.

Flutter, Compose, Slint, egui und iced treffen unterschiedliche Abwägungen. Wir haben 10 Frameworks mit denselben Szenarien getestet und flüssige Darstellung, CPU, Speicher und Designtreue gemessen, um die tatsächlichen Kosten der Ansätze zu vergleichen.

Wir haben 10 Frameworks mit denselben Szenarien auf einem Apple M4 Max und einem ThinkPad T14 Gen6 getestet. Auf beiden Plattformen wurden CPU und Speicher gemessen; für Windows liegen zusätzlich externe Frame-Messungen mit PresentMon vor. Die Frame-Callbacks auf dem Mac unterscheiden sich je nach Framework und dienen nicht dem Vergleich. Auch Hardware und Speicherkennzahlen sind verschieden, daher vergleichen wir nur innerhalb einer Plattform.

Die Animation ist eine dichte Szene: 500 Karten mit je 96×64 logischen Pixeln überlappen sich in 25 Spalten. Jede hat einen Eckenradius von 12, einen 135°-Farbverlauf und einen Schatten mit blur 16 und vertikalem Versatz 4. Alle Positionen werden pro Frame aktualisiert; die Karten bewegen sich auf Kreisen mit Radius 12 und einer Periode von 4 Sekunden. Angegeben ist der Median aus fünf Durchläufen à 30 Sekunden.

Gemessen werden vor allem die CPU-Kosten für UI-Aktualisierung, Zeichenvorbereitung und Render-Übermittlung bei vielen kontinuierlich bewegten Elementen mit Effekten sowie die gleichmäßige Frame-Ausgabe. CPU umfasst den Prozessbaum der Anwendung, nicht die GPU-Auslastung oder einzelne Verarbeitungsschritte. Sie muss zusammen mit den Frame-Abständen betrachtet werden: Weniger ausgegebene Frames können ebenfalls weniger CPU benötigen. 500 bezeichnet die Karten in der Szene; Überdeckung und Fenster-Clipping verhindern, dass alle in jedem Frame vollständig gezeichnet werden.

Windows

Beim Listenscrollen kamen alle mit. Die Unterschiede zeigten sich in der Animation: Bei 500 Karten mit Schatten und Verläufen hielten die selbst zeichnenden Rust- und Go-Frameworks weitgehend 120Hz. Flutter, Electron, Tauri und Compose kamen auf Frame-Abstände von 80 bis 160ms. Die 684ms von WPF entstanden durch 500 einzelne Schatteneffekte. Ohne sie waren es wieder 8.3ms, also kein allgemeines Problem.

Textbearbeitung ist eine weitere Hürde. Bei 10 eingefügten Zeichen pro Sekunde in einem Dokument mit 5,000 Zeilen lasteten Flutter, Compose und Slint jeweils einen Kern aus. Flutter verlor unter Windows zudem dreißig Prozent der Eingaben.

Mac

Auf dem Mac lag die Animations-CPU bei GPUI, MyGo, egui und iced bei etwa 15%–20%, bei Flutter bei 237% und bei Electron und Compose um 100%. Bei der Textbearbeitung beanspruchten Flutter und Compose weiterhin fast einen ganzen Kern. Slint lag bei 52%, unter seinen 99% auf Windows.

In der Listenszene beschreiben SwiftUIs etwa 40 MiB, GPUIs 340 MiB und eguis 800 MiB zunächst den Footprint der App-Prozesse. Native UI kann systemeigene Rendering-Dienste außerhalb der App nutzen: Apple dokumentiert AppKits bevorzugtes prozessexternes Rendering von Layer-Bäumen. Ein Teil des Zeichnens und Compositings findet daher anderswo statt. Eigene Renderer nutzen ebenfalls System-Compositing; die Arbeitsteilung lässt sich nicht allein anhand der App-Prozesse vergleichen. Der vereinheitlichte Speicher der M-Chips bedeutet gemeinsam genutzten physischen Speicher für CPU und GPU, nicht die Zurechnung sämtlicher Kosten zum phys_footprint der App.

In jeweils fünf kurzen GPU-Traces der SwiftUI-Listen- und Animationsszene wurden keine GPU-Ausführungsereignisse der App-PID beobachtet, während WindowServer aktiv war. Das bedeutet weder, dass SwiftUI keine GPU nutzt, noch lässt sich die gesamte Desktop-Aktivität dieser App zurechnen. WindowServers Speicherbasis schwankte um etwa 205 MiB; fehlende große gemeinsame Objekte in Momentaufnahmen schließen die Wiederverwendung vorhandener Systemressourcen nicht aus. Belegt ist nur ein kleinerer App-Prozess-Footprint für SwiftUI, kein geringerer gesamter Rendering-Aufwand und keine vollständige Übernahme der Differenz durch das System.

Diese Zahlen gelten nur für diese zwei Rechner, diese Versionen und unsere Testprogramme. Methode und vollständige Daten stehen in Abschnitt 05.

Editoren, Entwicklungswerkzeuge und Geschäftsanwendungen stellen unterschiedliche Anforderungen an Texteingabe, Animation, Speicher, plattformübergreifende Auslieferung und Widgets. Jeder hat eigene Einsatzfälle. Bei der Auswahl geht es darum, welche Kompromisse akzeptabel sind.

Viele Frameworks nutzen außerdem Retention, Caching und Teilaktualisierungen, um wiederholte Layout- und Zeichenarbeit zu vermeiden. GPUI kombiniert Immediate und Retained Mode. Das UI-Modell, die wiederverwendbare Arbeit und die Zeit zum Zeichnen eines Frames sind verschiedene Fragen.

MyGo, iced, GPUI, Slint und egui halten bei Animationen mit und haben eine niedrige CPU-Auslastung. Slint benötigt am wenigsten Speicher, egui eher viel, und bei GPUI muss man die Editierkomponenten selbst ergänzen. MyGo wird derzeit hauptsächlich für die eigenen Anwendungen des Autors genutzt und ist noch nicht in großem Maßstab im Produktivbetrieb erprobt.

Flutter, Electron und Compose zeigten in diesem Animationslasttest zudem ungünstige Frame-Abstände und hohen Ressourcenbedarf. Das Paket von Tauri ist nur 11 MB groß, der Speicherbedarf zur Laufzeit ist aber ähnlich wie bei Electron.

Wir halten die Überprüfung inzwischen für wichtiger als das Rendering.

Code zu schreiben ist günstiger geworden. Zu prüfen, ob er korrekt ist, kostet weiterhin Zeit. In der Entwicklerumfrage von Stack Overflow 2025 hatten 66% KI-Lösungen erlebt, die “almost right, but not quite” waren. 45.2% brauchten mehr Zeit zum Debuggen von KI-Code. In einer 01/2026 veröffentlichten Sonar-Umfrage vertrauten 96% nicht vollständig auf die funktionale Korrektheit von KI-Code. Nur 48% prüften ihn nach eigener Aussage immer vor dem Commit. Sonar verkauft Codeprüfwerkzeuge; die Zahlen sind daher mit etwas Vorsicht zu lesen. Sie passen aber zur anderen Umfrage.

Die beiden Releases von Slint und egui fanden wenig Beachtung. Wir halten sie für wichtiger als Fortschritte beim Rendering. Agenten müssen Eingaben einspeisen und Screenshots aufnehmen können, um etwas zu ändern, anzusehen und erneut zu ändern. Früher musste jemand vor dem Rechner sitzen und eine Oberfläche durchklicken. Diese Arbeit lässt sich nun allmählich Maschinen übertragen.

Derzeit gibt es drei Vorgehensweisen. Plattformübergreifendes Web hat die meisten vorhandenen Mittel. Selbst gezeichnete GPU-UIs brauchen keinen Browser, und die Einstiegshürde ist niedriger als früher. Native Apps für jede Plattform sind der älteste Weg. Früher konnten nur große Firmen mehrere Teams finanzieren. Die Schwierigkeit liegt heute in der Verdreifachung der Bugs und des Supportumfangs, die Breunig beschreibt. Wird die Überprüfung günstiger und die Qualität besser, könnte auch das direkte Erzeugen einer nativen App je Plattform funktionieren.

Auch wir erproben eine eigene GPU UI. Der Unterschied: Wir übernehmen viel von der DX der Web-Entwicklung. Dazu gehören JSX-ähnliche Komponenten, CSS-ähnliche Stile, flexbox-Layout, reaktiver Zustand und DevTools wie im Browser. Am Ende entsteht nativer Code. Das Projekt steht noch am Anfang.

Wir wissen nicht, welche Antwort gewinnt. Vielleicht bestehen mehrere lange nebeneinander. Die drei Tatsachen vom Anfang sind bis heute unverändert. Der PR bleibt geschlossen, MyGo wächst, und Claudes Desktop-App nutzt weiter Electron. Es ist eine sehr interessante Zeit.

Die Tests liefen vom 4. bis 6. November 2026. Für jedes Framework wurden dieselben Szenarien mit empfohlenen Verfahren, Standardeinstellungen und Release-Builds umgesetzt. Nach der Korrektur der Unschärfe wurden die Designseite von Compose und das Leerlaufszenario mit derselben Implementierung erneut gemessen.

Jedes Szenario lief pro Framework 5-mal für jeweils 30 Sekunden, nacheinander in gemischter Reihenfolge. Alle Tabellenwerte sind Mediane. Die mediane Spannweite zwischen den 5 Durchläufen lag bei etwa 3%, neunzig Prozent lagen innerhalb von 24%. Liste und Animation wurden nach Vereinheitlichung der Vorgaben erneut gemessen. Die Spalten stammen daher nicht aus demselben Zeitraum. Ein logischer Kern entspricht 100% CPU. Bei Mehrprozess-Apps zählen alle Kindprozesse mit. Für Tauri auf dem Mac wurden auch die vom System dafür gestarteten WebKit-Prozesse erfasst. Windows-Frame-Daten verwenden nur Durchläufe, die eindeutig einem swapchain zugeordnet werden können und keine verlorenen Datensätze haben.

Für Streaming und Bearbeitung wurde die tatsächlich erledigte Menge geprüft: Flutter unter Windows schaffte bei der Bearbeitung nur 68%, alle anderen über 99%.

Designtreue

Beim Unschärfetest sollen die Farbstreifen in einem bestimmten Bereich innerhalb des Fensters weiche Übergänge zeigen. Mit Modifier.blur von 24 dp auf der Streifenebene von Compose 1.12.2 waren diese Übergänge in nativen Fensteraufnahmen unter macOS und Windows sichtbar. SwiftUI zeichnet ebenfalls zunächst die bekannte Streifenebene weich und legt dann eine halbtransparente weiße Fläche darüber. Beide Prüfungen beziehen sich auf diese konkrete Inhaltsebene. Compose Desktop API

Die getesteten Implementierungen von GPUI, iced, egui und Slint legten eine halbtransparente Fläche über die Streifen. Die Farbkanten blieben im erneuten Test scharf. Blurred in GPUI und window::Settings::blur in iced wirken auf Inhalte hinter dem Fenster. In den getesteten Versionen fanden wir keine eingebaute Zeichen-API für lokale Hintergrundunschärfe. iced ermöglicht lokale Effekte durch eigenes Rendering, egui kann über PaintCallback das Rendering-Backend ansprechen. GPUI · iced-Fenstereinstellungen · egui-Zeichen-Callback

Slint wurde in Version 1.18.1 mit FemtoVG getestet. Diese Version enthielt keine elementbezogene Eigenschaft backdrop-blur. Später ergänzte das Slint-Projekt sie für den Skia-Renderer. Die Aufnahmen zeigen den FemtoVG-Pfad von Version 1.18.1. Slint-Issue

Die Designseite umfasst 11 Prüfungen. GPUI, egui, iced, Slint und Compose reproduzierten das P3-Feld in der getesteten Mac-Ausgabe nicht. Windows-Aufnahmen haben kein Farbprofil, daher wird P3 nicht bewertet; Flaggen-Emoji erscheinen als Buchstaben.

Layouts nähern sich an. Die größten Unterschiede bleiben beim Text. Fordert iced unter macOS PingFang 700 an, fallen lateinische Buchstaben auf Menlo Bold zurück.

Einschränkungen:

• Nur ein Rechner je Plattform. Die Animationsergebnisse stammen von einer integrierten Intel-GPU und gelten womöglich nicht für dedizierte GPUs.
• Der Mac war während der Tests nicht im Leerlauf. Frame-Daten stammen nur aus App-Callbacks und werden nicht frameworkübergreifend verglichen.
• Die Bedeutung von Schatten-blur unterscheidet sich. egui, iced und GPUI verwenden Näherungen. Auch die Editierkomponenten sind nicht gleichwertig; GPUI nutzt einen angepassten Beispiel-Editor.
• CPU- und Speichertabellen erfassen die App und einbezogene Hilfsprozesse. WindowServer- und Treiberkosten wurden nicht pro Fenster zugeordnet, Vorteile gemeinsam genutzter Systemressourcen nicht quantifiziert; daraus folgt keine Rangfolge des gesamten System-Rendering-Aufwands.
• Für Kandidatenfenster der Eingabemethode, den Barrierefreiheitsbaum auf dem Mac und den Energieverbrauch wurden keine verwertbaren Messergebnisse erzielt.