Die Auswahl einer JavaScript-GUI-Stack basierend darauf, was Ihre Benutzer tatsächlich herunterladen

Die Suche nach einem „JavaScript GUI Toolkit“ führt oft zu Listen, in denen Electron neben Material UI genannt wird, als wären sie Konkurrenten. Das sind sie jedoch nicht: Das eine bietet ein installierbares Fenster, das andere Buttons, die man darin platzieren kann – und die meisten echten Produkte benötigen beides. Diese Anleitung trennt diese beiden Ebenen voneinander, geht die wichtigsten Optionen jeder Ebene durch und stellt für beide eine entscheidende Frage: Wie viel Code landet letztendlich auf den Maschinen der Nutzer, und wie viel davon war tatsächlich notwendig?

Zwei Ebenen, die andere Sprachen zusammenfassen

In Ökosystemen wie Qt, GTK oder WinForms übernimmt ein GUI Toolkit alles auf einmal: Es öffnet ein natives Fenster und stellt die darin enthaltenen Widgets bereit. JavaScript verteilt diese Aufgaben auf zwei Arten von Tools – und gerade das Verwechseln dieser führt dazu, dass die meisten Vergleiche verwirrend sind.

• Desktop-Shells packen Web-Code als installierbare Anwendung zusammen. Was sie liefern, ist der Anwendungsrahmen: ein natives Fenster, Integration in den Systemtray, Zugriff auf lokale Dateien sowie einen Installer. Widgets gehören nicht dazu.
• Komponentenbibliotheken stellen die interaktiven Elemente bereit, wie z. B. Schaltflächen, Tabellen, Datumsauswähler und Dialogfelder. Sie laufen im Browser und sind unabhängig davon, ob dieser Browser in einer Desktop-Anwendung eingebettet ist oder ein gewöhnliches Tab-Fenster darstellt.

Ein Desktop-Produkt könnte Tauri mit MUI kombinieren; ein Web-Produkt könnte ausschließlich MUI verwenden. Die Wahl eines Shells und die Auswahl einer Komponentenbibliothek sind zwei getrennte Entscheidungen.

Die Frage, die tatsächlich die Optionen voneinander trennt

In einigen Ökosystemen ist die Lizenzierung der entscheidende Faktor, denn eine falsche Verpflichtung kann dazu zwingen, das Produkt unter Open Source zu veröffentlichen. In der Welt der JavaScript-GUIs ist fast alles unter der MIT-Lizenz verfügbar, wodurch die Lizenz selten den Auswahlbereich einengt. Was ihn tatsächlich einschränkt, ist das Gewicht. Bei Shell-Programmen liegt der Unterschied zwischen einem Installer von einigen Megabyte und einem von mehreren Hundert. Bei Komponentenbibliotheken besteht der Unterschied darin, entweder ein ganzes Design-System zu liefern oder nur die wenigen Komponenten, die tatsächlich verwendet werden. Behalten Sie diese Frage im Hinterkopf, während Sie die folgenden beiden Abschnitte lesen.

Die hier angegebenen Versionszahlen beziehen sich auf npm zum Zeitpunkt der Erstellung; überprüfen Sie das Registry-System, bevor Sie sich darauf verlassen. Für eine detailliertere Betrachtung insbesondere der Desktop-Versionen, einschließlich neuer Laufzeiten, sehen Sie unsere Vergleichstabelle der Electron-, Tauri-, Electrobun- und Deno-Desktop-Lösungen.

Desktop-Shells

Electron: das bewährte Standardtool mit eigenem Browser

Electron (Version 44.3.0 zum Zeitpunkt der Erstellung, MIT-Lizenz) wird als Entwicklungskomponente hinzugefügt:

npm install --save-dev electron

Es packt einen vollständigen Chromium-Browser zusammen mit einem Node.js-Laufzeitumfeld in Ihre Anwendung ein. Die Benutzeroberfläche besteht aus einer Webseite und der Backend-Bereich wird von Node betrieben. Sein stärkstes Argument ist die Reife: VS Code, Slack, Discord, Figma und 1Password wurden alle darauf gebaut, und für das Verpacken, die automatische Aktualisierung, die Signierung von Code sowie den Bericht über Abstürze gibt es gut dokumentierte Werkzeuge, die viele Teams bereits kennen.

Der zweite Vorteil ist die konsistente Darstellung. Da Sie den Browser mitliefern, sieht die Anwendung auf Windows, macOS und Linux identisch aus, und Sie testen anhand einer einzigen Chromium-Version statt anhand von drei verschiedenen System-Webview-Implementierungen. Zudem handelt es sich um eine rein JavaScript-basierte Lösung, sodass jeder Frontend-Entwickler am Hauptprozess arbeiten kann.

Der Nachteil ist, dass jede App einen Browser mit sich bringt. Die Pakete haben in der Regel ein Volumen von 80 bis 200 MB, und da jede Electron-App einen eigenen Chromium-Prozess startet, steigt der RAM-Verbrauch schnell an, wenn ein Benutzer mehrere davon ausführt. Auch das Patchen dieses eingebetteten Chromiums liegt in Ihrer Verantwortung und muss nach Ihrem eigenen Zeitplan erfolgen.

Tauri: der System-Webview plus ein Rust-Backend

Tauri (zum Zeitpunkt der Erstellung v2.11.4, doppelt lizenziert unter Apache-2.0 oder MIT) verfügt über einen eigenen create-Befehl:

npm create tauri-app@latest

Anstatt einen Browser mitzuliefern, verwendet Tauri den bereits vom Betriebssystem bereitgestellten Webview, und seine Backend-Logik ist in Rust statt in Node geschrieben. Der Größenunterschied ist strukturell und nicht durch zusätzliche Optimierungen bedingt: Üblicherweise liegen die Größen der Tauri-Bundles bei etwa 3 bis 10 MB im Vergleich zu 120 bis 200 MB bei Electron, wobei der Speicherverbrauch um 50 bis 75 Prozent geringer ist und das Starten schneller erfolgt. Da dieser Unterschied auf der Architektur beruht und nicht auf Optimierungen, bleibt er auch in den verschiedenen Versionen bestehen.

Auch das Sicherheitsmodell unterscheidet sich. In Electron kann JavaScript im Frontend über Node auf das Betriebssystem zugreifen, es sei denn, man schränkt dies ein. Bei Tauri startet das Frontend ohne Systemzugriff; privilegierte Operationen sind Rust-Funktionen, die das Frontend per Name aufruft. Zudem führte Tauri v2 ein Fähigkeitsystem ein, das steuert, welche APIs jede Fensteranwendung aufrufen darf. Tauri 2 ist zudem für iOS und Android geeignet, was Electron überhaupt nicht kann – ein wichtiger Vorteil für Teams, die eine einzige Codebasis für Desktop- und Mobilgeräte möchten.

Die Nachteile sind real. Die eigene Webview jeder Plattform rendernt leicht unterschiedlich, sodass man nun drei Engines statt einer testet. Alles, was über die Frontend-Bereitstellung hinausgeht, erfordert etwas Rust. Unter Windows setzt Tauri auf WebView2, das in nahezu allen modernen Installationen vorhanden ist, aber gelegentlich einen Bootstrapper benötigt. Eine sinnvolle Regel: Wenn die Größe des Bundles noch kein Klagemotiv der Kunden ist, ist es zu früh, Tauri ausschließlich zum Sparen von Megabyte zu wählen. Wählen Sie es, wenn kompakte Installer, ein geringer Speicherverbrauch, strengere Isolation oder eine mobile Version tatsächliche Anforderungen sind.

NW.js: der ältere Chromium-Bundler

NW.js (zum Zeitpunkt der Erstellung v0.115.0, MIT-Lizenz) wird als reguläres Paket installiert:

npm install nw

Es enthält außerdem Chromium und ist tatsächlich älter als Electron. Sein besonderes Merkmal ist, dass Node und der DOM denselben Kontext teilen, sodass eine Webseite direkt auf Node-APIs zugreifen kann – ohne die Trennung in Haupt- und Render-Prozesse wie bei Electron. Für einige Anwendungen ist das einfacher zu verstehen. Der Nachteil ist eine weitaus kleinere Community: weniger Lernmaterial, weniger Verpackungstools und weniger Unterstützung, wenn man auf Probleme stößt, während die Größe der Pakete weiterhin so groß bleibt wie bei Electron.

Neutralino: die kleinste mögliche Umhüllung

Neutralino (CLI v11.7.2 zum Zeitpunkt der Erstellung, MIT-Lizenz) wird durch eine global installierte CLI angetrieben:

npm install -g @neutralinojs/neu

Es handelt sich um ein leichtes natives Binärprogramm, das um den System-Webview herum arbeitet und weder Node noch Chromium enthält. Die Pakete sind in der Regel 1 bis 5 MB groß, sogar kleiner als bei Tauri, da weniger Frameworks involviert sind. Wenn man lediglich eine bestehende Web-Oberfläche einpacken und ein Tray-Icon hinzufügen sowie einfache Persistenzfunktionen und eingeschränkten Dateizugriff bieten möchte, ist Neutralino die Lösung mit der geringsten Komplexität. Es verfügt über das kleinste Ökosystem sowie die engste Palette an nativen Funktionen von allen vier Optionen – daher sollte es eher als Hilfsframework denn als Plattform für komplexe Anwendungen betrachtet werden.

Komponentenbibliotheken

Alles in diesem Bereich läuft im Browser, sodass jede Option genauso gut innerhalb einer Desktop-Oberfläche oder in einem normalen Tab funktioniert. Hier verschiebt sich die Frage nach dem Gewicht vom Größe des Installers auf die Menge an Bibliothekskodieren, die das Paket mit sich führt.

MUI: maximale Abdeckung, standardmäßig Material

MUI (zur Zeit der Erstellung Version 9.4.0, MIT-Lizenz) wird zusammen mit seinem Stilungsmechanismus Emotion installiert:

npm install @mui/material @emotion/react @emotion/styled

Unter den React-Komponentenbibliotheken ist sie die größte und am längsten etablierte und folgt Googles Material Design-System. Die Abdeckung der Komponenten ist enorm, die Dokumentation hervorragend und seine Datentabellen können große Datenmengen verarbeiten. Wenn Sie eine bestimmte Komponente benötigen, hat MUI sie fast sicherlich – und jemand anderes hat bereits dieselbe Frage gestellt.

Aber es handelt sich dabei auch um eine ziemlich große Bibliothek. Eine frische Installation nimmt in node_modules etwa 19 MB ein; das ist nicht das, was die Nutzer erhalten, zeigt aber den Umfang an. Ihr bereitgestelltes Bundle hängt davon ab, dass das Tree-Shaking ordnungsgemäß funktioniert – und es sei denn, Sie investieren in thematische Anpassungen, sieht alles wie Material Design aus, was einige Teams bevorzugen und andere wiederum als einschränkend empfinden.

shadcn/ui: Quellcode kopieren anstelle einer Abhängigkeit hinzuzufügen

shadcn/ui (CLI v4.21.0 zum Zeitpunkt der Erstellung, MIT-Lizenz) ist kein Paket, das man importiert. Seine CLI initialisiert ein Projekt und kopiert anschließend einzelne Komponenten hinein:

npx shadcn@latest init
npx shadcn@latest add button dialog

Jede Komponente kombiniert Radix UI-Primitiven mit Tailwind-Styling, und nach dem Ausführen der CLI handelt es sich dabei einfach um Quellcode in Ihrem Repository. Wenn eine Schaltfläche ein anderes Verhalten benötigt, editieren Sie diese direkt; es gibt keine Wrapper-Komponenten, keine Themen-API, mit der man kämpfen müsste, und keinen Betreuer, den man überzeugen muss. Zudem bleibt das Bundle transparent: Fügen Sie vier Komponenten hinzu, dann landen auch nur diese vier in Ihrer Build-Datei.

Die Kosten im Besitz sind die Wartungskosten. Kein npm update wird Ihre Komponenten verbessern; ein Upgrade bedeutet, die Änderungen manuell neu zu kopieren und abzustimmen. Zudem setzt es Tailwind voraus, was es für Projekte, die es nicht verwenden, ungeeignet macht. Das Modell funktioniert, weil es das übliche Kompromissverhältnis zwischen Bequemlichkeit und Anpassbarkeit umkehrt: Man erhält einen soliden Ausgangspunkt sowie volle Kontrolle, muss im Gegenzug aber selbst für Updates sorgen.

Ant Design: entwickelt für dichte Unternehmensoberflächen

Ant Design (zum Zeitpunkt der Erstellung v6.6.3, MIT-Lizenz) stammt von Alibaba und wird als einziges Paket installiert:

npm install antd

Es bietet das umfassendste Set an Komponenten für datenintensive Business-Oberflächen: fortgeschrittene Tabellen, komplexe Formulare, Übertragungslisten sowie Baumauswahlfelder. Für Admin-Konsolen und interne Tools existiert vermutlich bereits die gewünschte Widget-Lösung. Zudem ist es die größte Bibliothek in dieser Liste – nach der Installation etwa 61 MB groß, das sind rund dreimal so viel wie MUI – und ihre starke visuelle Identität ist deutlich schwieriger abzulegen als die von Material.

Mantine: gute Standardeinstellungen ohne starre Vorgaben

Mantine (Version 9.6.1 zum Zeitpunkt der Erstellung, MIT-Lizenz) trennt seine Kernkomponenten von einem Hooks-Paket:

npm install @mantine/core @mantine/hooks

Teams, die MUI als zu vorgeschrieben und shadcn/ui als zu eingreifend empfinden, landen oft hier. Es verfügt über eine umfangreiche Komponentensammlung, sinnvolle Standardwerte, einfaches Theming, starke Unterstützung für TypeScript sowie solide Dunkelmodus-Funktionen ohne zusätzliche Einrichtung. Schon allein das Hooks-Paket mit Hilfsmitteln für die Erkennung von Klicks außerhalb des Elements, lokalen Speicher und Media Queries ist auch für sich genommen nützlich. Seine Community ist kleiner als die von MUI oder Ant Design, weshalb mit weniger Drittanbieter-Erweiterungen und weniger fertigen Lösungen zu rechnen ist.

Radix UI und Headless UI: Verhalten ohne Styling

Radix UI (zum Zeitpunkt der Erstellung v1.1.23) und Headless UI (v2.2.10), beide unter der MIT-Lizenz, werden entweder pro Primitivkomponente oder als einziges Paket installiert:

npm install @radix-ui/react-dialog
npm install @headlessui/react

Dies sind ungestylte Primitiven. Sie kümmern sich um das Verhalten, die Tastaturnavigation, die Fokussierung und die Barrierefreiheit und überlassen alle visuellen Entscheidungen Ihnen. Diese Trennung ist wertvoll, denn barrierefreie Widgets sind schwieriger zu gestalten, als es auf den ersten Blick scheint. Ein ordentlicher Dialog muss den Fokus während seiner Öffnung beibehalten, ihn beim Schließen wieder zurückgeben, per Escape-Taste schließbar sein und von Assistenztechnologien korrekt angekündigt werden; ein ordentlicher Dropdown benötigt Navigation mit Pfeiltasten, Auswahl per Eingabe sowie eine sinnvolle Platzierung nahe den Rändern des Ansichtsfensters. Die meisten Teams unterschätzen diese Arbeit und liefern letztendlich etwas, das subtil fehlerhaft ist.

Radix ist die Grundlage, auf der shadcn/ui aufbaut, und Headless UI wird vom Tailwind-Team gepflegt. Der offensichtliche Nachteil ist, dass Sie das gesamte Styling selbst schreiben müssen – was zwar der Sinn dahinter ist, aber dennoch echte Arbeit bedeutet.

PrimeReact: Vielfalt für ungewöhnliche Komponenten

PrimeReact (zum Zeitpunkt der Erstellung v11.1.0) gehört zur PrimeFaces-Familie, zu der auch Angular, Vue und Java gehören:

npm install primereact

Es bietet ein enorm breites Spektrum an Funktionen – von Diagrammen und Organigrammen über Baumtabellen, Planer, Upload-Widgets bis hin zu einer umfassenden Sammlung an Eingabefeldern, von denen viele andere Bibliotheken völlig auslassen. Wenn Sie etwas Ungewöhnliches benötigen, lohnt es sich, zunächst hier nachzusehen.

Überprüfen Sie vor dem Verwenden selbst die Lizenzbedingungen. Die npm-Metadaten verweisen auf eine Lizenzdatei ("SEE LICENSE IN LICENSE.md") anstelle eines SPDX-Identifikators, und der Anbieter bietet neben dem kostenlosen Paket auch bezahlte Themes und Vorlagen an. Die Kernbibliothek ist Open Source, lesen Sie jedoch vor der Entwicklung eines kommerziellen Produkts unbedingt die tatsächlichen Bedingungen.

Drei weitere, die man sich ansehen sollte

• Chakra UI (v3.37.0, MIT) stellt die Barrierefreiheit in den Vordergrund und gestaltet Komponenten über Props; es liegt irgendwo zwischen dem umfassenden Ansatz von MUI und den reinen Primitiven von Radix.
• daisyUI (v5.7.34, MIT) ist ein Tailwind-Plugin, das Komponentenklassen anstelle von React-Komponenten bereitstellt, wodurch es auch in Svelte, Vue oder statischem Markup verwendet werden kann.
• HeroUI (v3.2.4, MIT), der umgenannte Nachfolger von NextUI, kombiniert Tailwind mit React Aria.

Ein kurzer Entscheidungshilfe

Für die Desktop-Oberfläche:

• Eine bewährte Ökosystemstruktur, identische Darstellung überall sowie ein Team, das ausschließlich JavaScript verwendet, deuten auf Electron hin.
• Kleine Downloadgrößen, geringer Speicherverbrauch, ein strengeres Sicherheitsmodell oder ein Fokus auf mobile Geräte deuten auf Tauri hin.

Ein dünner Wrapper um eine bestehende Web-Oberfläche deutet auf Neutralino hin.

Der Wunsch nach Node und DOM in einem gemeinsamen Kontext deutet auf NW.js hin.

Was die Komponentenbibliotheken angeht:

• Der Bedarf an nahezu allen Komponenten zusammen mit hervorragender Dokumentation deutet auf MUI hin.
• Der Wunsch, den Code in einem Tailwind-Projekt selbst zu besitzen und anzupassen, deutet auf shadcn/ui hin.
• Dichte Unternehmensdatenansichten deuten auf Ant Design hin.
• Gute Standardwerte ohne starke Vorlieben deuten auf Mantine hin.
• Ein benutzerdefiniertes Designsystem mit integrierter Barrierefreiheit deutet auf Radix oder Headless UI hin.
• Eine ungewöhnliche, spezialisierte Komponente deutet auf PrimeReact hin.

Eine Regel überlagert die gesamte Liste: Wenn Ihr Team bereits eines dieser Tools gut kennt, wiegt dieses Wissen fast immer mehr als eine nur geringfügig bessere Passform an anderer Stelle.

Zusammenfassung

In beiden Schichten haben sich die Funktionslisten weitgehend angeglichen; diese Projekte hatten Jahre Zeit, die guten Ideen voneinander zu übernehmen. Bei der Größe des Pakets unterscheiden sie sich jedoch weiterhin auf eine Weise, die für die Nutzer spürbar ist. Electron gegenüber Tauri stellt die Frage nach der Größe der gesamten Anwendung: Soll ein Browser mit eingebunden werden, um Vorhersehbarkeit zu gewährleisten, oder soll auf den vom Betriebssystem bereitgestellten Browser zurückgegriffen werden, um ein Paket zu erzeugen, das zwanzigmal oder mehr kleiner sein kann? Die Wahl zwischen MUI und shadcn/ui wendet diesen Kompromiss auf die Komponentenschicht an: Soll man sich auf ein vollständiges Designsystem verlassen, das von anderen gepflegt wird, oder sollen nur die benötigten Elemente vom Anbieter geliefert und selbst gepflegt werden? Entscheiden Sie vor dem Vergleich der Funktionslisten, auf welcher Seite dieses Kompromisses Ihr Produkt steht – dann wählt sich die endgültige Auswahl in der Regel von selbst aus.