Rust-Cross-Platform-GPUI-Komponenten

• Rust-basierte GPUI-Framework für den Aufbau von plattformübergreifenden Desktop-Anwendungen mit einer UI-Komponentenbibliothek
• Bietet mehr als 60 UI-Komponenten im nativen Stil und verbindet das Designgefühl von macOS und Windows mit der modernen Ästhetik von shadcn/ui
• Umfangreiche Funktionen integriert, darunter virtualisierte Tabellen, ein leistungsstarker Code-Editor, Markdown/HTML-Rendering und Diagrammvisualisierung
• Auf Erweiterbarkeit und Anpassbarkeit ausgelegt, mit Theme-System, Mehrsprachigkeit (i18n) und Docking-Layout
• Im Rust-Ökosystem hebt es sich im Vergleich zu Iced, egui und Qt durch modernen UI-Stil und starke Performance bei der Verarbeitung großer Datenmengen ab

---

Projektüberblick

• gpui-component ist eine in Rust geschriebene Sammlung plattformübergreifender Desktop-UI-Komponenten, die auf der GPUI-Rendering-Engine basiert
  • Ziel ist es, „fantastic desktop applications“ schnell und konsistent entwickeln zu können
  • Die offizielle Website ist longbridge.github.io/gpui-component
• Apache-2.0-Lizenz

Hauptfunktionen

• Umfangreiche Komponentenausstattung: Enthält mehr als 60 UI-Elemente, darunter Buttons, Listen, Tabellen, Diagramme und Editoren
• Design mit nativer Anmutung: Setzt eine moderne Oberfläche um, inspiriert von den Standard-Controls von macOS und Windows und kombiniert mit dem Stil von shadcn/ui
• Einfache Nutzbarkeit: Die zustandslose RenderOnce-Komponentenstruktur ermöglicht einfachen und intuitiven Code
• Theme- und Farbsystem: Unterstützt mit Theme und ThemeColor mehrere Themes sowie variablenbasierte Konfiguration
• Flexibles Layout: Mit Dock layout lassen sich Panels anordnen, skalieren und frei kachelartig organisieren
• High-Performance-Rendering: Mit Virtualized Table/List werden auch große Datenmengen flüssig dargestellt
• Content-Rendering: Unterstützt Markdown und einfaches HTML nativ
• Diagrammfunktionen: Integrierte Diagramme zur Datenvisualisierung
• Code-Editor: Enthält einen leistungsstarken LSP-basierten Code-Editor mit Unterstützung für bis zu 200.000 Zeilen
  • Unterstützt Funktionen wie Diagnosen, Autovervollständigung und Hover
• Syntax-Highlighting: Bietet mit Tree Sitter Syntaxhervorhebung sowohl im Editor als auch in Markdown

Tech-Stack und Kennzahlen

• Sprachzusammensetzung: Rust 98,2 %, Tree-sitter Query 0,8 %, HTML 0,2 %, Shell 0,2 %, Python 0,1 %, C 0,1 %
• Repository-Kennzahlen: 5,4k Stars, 223 Forks, mehr als 45 Mitwirkende
• Neueste Veröffentlichung: v0.3.1 (27. Oktober 2025)

Zusammenfassende Bedeutung

• gpui-component wird im Rust-Ökosystem als neues Desktop-UI-Framework bewertet, das modernes UI/UX mit High-Performance-Rendering verbindet
• Es ergänzt die Grenzen bestehender Rust-GUI-Frameworks und bietet praxisnahe Funktionen wie Verarbeitung großer Datenmengen, Theming und Markdown-Integration
• Das Projekt gilt als aussichtsreicher Kandidat für eine standardisierte UI-Schicht in der künftigen Entwicklung plattformübergreifender Apps auf Rust-Basis

[GN⁺]

Hacker-News-Kommentare

• Im Rust-UI-Ökosystem wirkt das wie die am weitesten ausgereifte Komponenten-Sammlung, die ich bisher gesehen habe
  Es gibt zwar noch kaum Anwendungsfälle, aber die Dokumentation wird nach und nach besser aufbereitet
  Ein ähnlich ausgereiftes anderes Beispiel ist fyrox-ui. Allerdings wird es außerhalb der Fyrox-Engine kaum genutzt
  Rust UI wird zunehmend reifer, aber beliebte Frameworks wie iced, egui, dioxus und slint scheinen bei der Ausgereiftheit der Komponenten noch hinterherzuhinken
  Um das zu aktualisieren: Dieses Projekt zeigt einen großen Fortschritt im Rust-UI-Ökosystem.
  Eine Widget-Galerie-App, in der man alle Komponenten sehen kann, lässt sich hier ausführen — direkt mit cargo run --release

  • gpui ist ein von Zed Editor abgespaltenes Projekt, daher dürfte die tatsächliche Nutzung viel höher sein als bei anderen Rust-UI-Crates
  • Fyrox sorgt eher für Skepsis gegenüber Rust-Spieleentwicklung. Es ist die ausgereifteste Engine, und trotzdem nutzt sie niemand. Stattdessen sind alle nur vom ECS von Bevy begeistert. Am Ende waren sie wohl eher am System selbst interessiert, nicht daran, wirklich Spiele zu machen
  • Rust-UI-Frameworks wirken vermutlich deshalb weniger ausgereift, weil sie sich noch schnell verändern. Trotzdem ist der Schwung eindeutig da. Das ist nur meine persönliche Erfahrung, aber ich konnte bereits Enterprise-UI in Rust bauen
  • Ich habe die Longbridge-App selbst installiert, und sie fühlt sich wirklich wie eine native Mac-App an. Sie läuft viel flüssiger als Electron
  • Die Widget-Galerie-App ist beeindruckend, aber die über 900 Abhängigkeiten machen mir etwas Sorgen. Ich weiß nicht, ob das bei GUI-Apps normal ist

• Selbst das einfachste Beispiel hat mehr als 1000 Abhängigkeiten. Es hängt von Toolkits wie GTK, GDK und pango ab. Diese Struktur, bei der man noch von anderen Toolkits abhängt, wirkt etwas merkwürdig

  • GNOME implementiert keine serverseitige Dekoration, deshalb ist man auf libadwaita angewiesen. Das scheint der Grund zu sein, warum all diese GTK-bezogenen Abhängigkeiten hereingezogen werden
  • Unter Linux ist so eine Struktur üblich. Es ist normal, GTK oder Qt zu verwenden, um übergeordnete Fenster oder Menüs zu zeichnen
  • Ich halte 1000 kleine, kombinierbare Abhängigkeiten für besser. Sie lassen sich viel leichter auditieren als eine riesige monolithische Codebasis
  • Schade, dass aktuelle Rust-Projekte immer mehr in diese Richtung wachsen

• Es ist bitter, dass viele Grundlagentechnologien im Open-Source-Bereich von Trading- und Krypto-Unternehmen entwickelt werden. Positiv ist immerhin, dass sie damit der Gesellschaft etwas zurückgeben

  • gpui wird vom Team von Zed.dev gepflegt, und Longbridge wirkt wie ein normales Brokerage-Unternehmen, das die Longbridge Pro App entwickelt. Das scheint nichts besonders Problematisches zu sein
  • Ich finde, der Bitcoin-Geist ähnelt der Hacker-Kultur. Diese Haltung von „Lasst uns reparieren, was kaputt ist“. Kurzfristiger Schmerz kann langfristig zu Gewinn führen
  • In einigen Ökosystemen wie Rust oder OCaml (Jane Street) gibt es diese Tendenz zwar, insgesamt ist das aber wohl eine übertriebene Behauptung
  • Facebook, das React entwickelt hat, war in Dinge wie den Cambridge-Analytica-Skandal oder das Massaker an den Rohingya verwickelt. Vor diesem Hintergrund könnte man sogar sagen, dass Beiträge von Trading-/Krypto-Unternehmen zu Open Source moralisch eher die bessere Variante sind

• Ich frage mich, ob moderne UI-Toolkits heutzutage keine visuellen UI-Editoren mehr haben
  Mit Qt konnte man dank Tools wie QtCreator oder QtDesigner UIs vollständig per Drag-and-drop bauen
  Außerdem sind einige Punkte in der Vergleichstabelle zu Qt falsch — zum Beispiel die minimale Binärgröße oder die Beschreibung von QSyntaxHighlighter

  • Frameworks wie Slint unterstützen Figma-Integration und lassen sich daher ähnlich wie Qt Design Studio verwenden. Viele scheinen heute gar nicht mehr zu wissen, wie leistungsfähig die nativen GUI-Designer früher waren
  • Auf Basis einer ausgereiften Komponentenbibliothek ließe sich so ein visueller Editor auch in Rust umsetzen. Wenn man eine XML-/Markup-basierte Struktur mit Makros verbindet und eine Live-Vorschau-App baut, könnte das wie Glade oder XAML funktionieren
  • Die minimale Größe von Qt liegt tatsächlich unter 20 MB, aber in der Praxis sind es eher 30–40 MB. Die Module Core, Gui, QML und Widget sind jeweils etwa 8 MB groß, daher braucht sogar Hello World 2 oder 3 davon
  • Qt Designer ist für einfache UIs okay, aber sobald man Custom-Styling anwendet, geht es schnell kaputt. Deshalb habe ich die UI-Dateien am Ende direkt von Hand geschrieben. Das war viel sauberer und kleiner
  • Die Behauptung, Qt6 unterstütze keine Themes, ist schlicht falsch

• Leider ist das ein Framework. Das heißt, es muss seine eigene Event-Loop mitbringen
  In Umgebungen, in denen bereits eine andere Loop existiert, ist die Integration schwierig. egui dagegen ist eher eine bibliotheksartige Struktur, die einfach pro Frame aufgerufen wird

• Ich frage mich, ob die Screenreader-Barrierefreiheit für Sehbehinderte gut funktioniert

  • Ich habe es nicht selbst ausgeführt, aber laut offizieller Dokumentation wird die ARIA-Spezifikation unterstützt. Man muss nur die nötigen Labels und Beschreibungen ergänzen
  • Allerdings ist der Zed Editor für Screenreader vollkommen undurchsichtig. Deshalb habe ich keine großen Erwartungen
  • Wenn ich ein neues UI-Framework sehe, ist Barrierefreiheit immer das Erste, wonach ich frage

• Ich frage mich, ob „nativ“ hier einfach bedeutet, dass es nicht Web ist, oder ob die nativen Widgets des Betriebssystems verwendet werden. In der Java-Welt war dieser Unterschied ebenfalls ein großes Thema

  • Nur macOS ist eine Plattform, auf der man wirklich native Apps bauen kann. Unter Linux ist alles zwischen GTK und Qt aufgeteilt, und unter Windows gibt es so viele gemischte Frameworks, dass selbst WebView nativ wirken kann
  • Mit nativ ist hier gemeint: „nicht Web“. Es ist eine Struktur, die direkt über eine GPU-API zeichnet
  • Also eine native ausführbare Datei, aber keine Nutzung von OS-Widgets
  • Es gibt keine OS-Integration, sondern vollständig eigenes Rendering

• Ich frage mich, ob dieses Framework Barrierefreiheit (a11y) implementiert hat. Rust-UIs sehen oft hübsch aus, aber sobald Barrierefreiheit gefordert ist, muss man sie komplett neu schreiben

  • Wenn dir Barrierefreiheit wichtig ist, könnte Dioxus einen Blick wert sein. Allerdings gibt es dort noch keine Komponentenbibliothek auf diesem Ausgereiftheitsniveau
  • GPUI baut zwar auf der Grundlage des Zed-Teams auf, ist für Screenreader aber weiterhin undurchsichtig. Wenn Barrierefreiheit wichtig ist, wären Slint oder Qt (cxx-qt) besser, und da System76 Iced übernommen hat, dürfte es dort ebenfalls Verbesserungen geben
  • Barrierefreiheit ist implementiert

• Die virtualisierten Listen und Tabellen sind wirklich hervorragend. In vielen UI-Frameworks musste man so etwas selbst implementieren, was mühsam war

• Rust hat zwar viele GUI-Toolkits, aber es fehlt an wiederverwendbaren Komponenten-Sammlungen
  Diese Sammlung wirkt nützlich, aber die meisten Komponenten erinnern an die Listen aus Web-Frameworks. Wirklich nativspezifisch ist höchstens die WebView. Für Dinge wie Dateiauswahldialoge muss man externe Bibliotheken wie rfd verwenden, wodurch die stilistische Konsistenz verloren geht

  • Dass die stilistische Konsistenz verloren geht, ist eher etwas Gutes. Nutzer wollen Konsistenz zwischen Apps. Deshalb sind native OS-Dialoge vertrauter. Professionelle Software wie Blender oder Photoshop ist eine Ausnahme, aber bei normalen Apps ist nativ wohl besser
  • Die meisten UI-Bibliotheken brauchen zumindest ein Mindestmaß an nativer Integration. Also etwa Tastenkürzel, Systemmenüs, Dateidialoge oder Kontextmenüs. Solche Dinge erhöhen die Vertrautheit für Nutzer
  • Ein Dateiauswahldialog sollte unbedingt den systemeigenen Dialog des Betriebssystems verwenden. Das selbst zu implementieren ist keine gute Idee