Wingo UI vs shadcn/ui: gleiches Modell, anderer Umfang

Wenn du shadcn/ui schon nutzt, ist die Frage „Wingo UI vs shadcn“ enger gefasst, als sie aussieht. Beide legen TypeScript-Quellcode in components/ui ab, beide stylen ihn mit Tailwind CSS und CSS-Variablen, und beide installierst du über eine CLI. Wingo UI lässt sich sogar über die shadcn CLI als Namespace-Registry installieren. Die Entscheidung dreht sich also um den Umfang: was jede Bibliothek abdeckt, was sie auf dem Smartphone macht, was passiert, wenn upstream einen Fix ausliefert, und was sie kostet.
Wir bauen Wingo UI, das hier ist also der Vergleich eines Anbieters. Jede Angabe zu shadcn/ui unten stammt von ui.shadcn.com (opens in a new tab) und wurde am 13. Oktober 2026 geprüft; jede Zahl zu Wingo UI stammt aus unserer Registry in Release 1.8.0. Wo shadcn/ui allein die bessere Wahl ist, sagen wir das. Für das ganze Feld vergleicht unser Guide zu shadcn-Alternativen 14 Bibliotheken.
Was haben Wingo UI und shadcn/ui gemeinsam?
Das Verteilungsmodell. Keine der beiden ist ein npm-Paket, das du aus node_modules importierst. Eine CLI holt die Dateien der Komponenten und schreibt sie in dein Projekt, und ab dann gehört der Code dir: Du kannst ihn lesen und ändern. Beide setzen auf React 19 und Tailwind CSS v4 und lesen ihre Farben aus CSS-Variablen in deinem globalen Stylesheet.
Wingo UI ist eine shadcn kompatible Komponentenbibliothek, gebaut für den Einsatz in einem shadcn/ui-Projekt. Die Installations-Doku beschreibt drei Wege:
Die dritte Zeile braucht einen Registry-Eintrag mit deinem API-Key:
Ein Haken wiegt seit Juli 2026 schwerer. shadcn/ui hat Base UI für npx shadcn init zum Standard gemacht (opens in a new tab), und Projekte mit einem Base-UI-Style schreiben asChild um. Die Komponenten von Wingo UI bauen auf Radix und verlassen sich auf asChild. In einem Projekt mit Base-UI-Style installierst du sie deshalb mit npx wingo-ui@latest add statt mit der shadcn CLI.
Wie schneiden Wingo UI und shadcn/ui im Vergleich ab?
Geprüft am 13. Oktober 2026. Die Angaben zu shadcn/ui verlinken auf die Doku; die zu Wingo UI stammen aus unserem Katalog und unserer Doku, die Wingo UI Preise von der Preisseite.
Wingo UI ist eine von mehreren Registries, die Quellcode nach demselben Modell verkaufen. Wenn du allgemein kostenpflichtige shadcn Komponenten vergleichst, listet der Guide zu den Alternativen die anderen mit ihren Preisen.
Den größten Unterschied zeigt die Tabelle nicht: die Größe der Community. shadcn/ui hat ein großes Ökosystem aus Registries, Tutorials und beantworteten Fragen. Wingo UI ist jung und hat eine kleine Community. Wenn etwas kaputtgeht, liest du also eher unseren Quellcode und unsere Doku, als einen Forenthread zu finden.
Wann ist shadcn/ui allein die bessere Wahl?
Öfter, als ein Anbieter gern zugibt. Nimm nur shadcn/ui und belass es dabei, wenn:
- Das Budget null ist oder die Lizenz MIT sein muss. shadcn/ui ist für jeden Zweck kostenlos. Open-Source-Projekte, die ihren UI-Code weiterverteilen, sollten ebenfalls bei MIT-Komponenten bleiben.
- Du Base UI oder React Aria als Unterbau willst. shadcn/ui liefert Updates und neue Komponenten für Base UI und Radix (
npx shadcn init -b radixbehält Radix), und React Aria kam im Juli 2026 als dritte Basis dazu (-b aria). Wingo UI gibt es nur mit Radix. In einem Base-UI-Projekt schleppst du also zwei Primitive-Bibliotheken mit. - Deine App vor allem am Desktop läuft. Wenn Smartphones Nebensache sind, bringt dir der Aufwand, den Wingo UI standardmäßig in Bottom Sheets steckt, wenig.
- Du auf das Ökosystem setzt. Community-Registries, Blocks und Beispiele entstehen zuerst für shadcn/ui, und sein MCP-Server kann sie alle durchsuchen und daraus installieren.
- Dein Design-System das Produkt ist. Wenn du sowieso jede Komponente neu stylen willst, ist der Code von shadcn/ui ein schlanker Startpunkt mit weniger Props, die du entfernen musst.
Wann bringt Wingo UI einen Mehrwert?
Wenn deine App auf Smartphones genutzt wird, wenn du ganze Screens statt Einzelteile brauchst oder wenn du Komponenten weiter ändern und trotzdem Fixes von upstream übernehmen willst.
Overlays, die auf dem Smartphone zu Sheets werden
shadcn/ui gibt dir einen Drawer und dokumentiert ein Rezept, das auf dem Desktop einen Dialog und auf dem Smartphone einen Drawer rendert. Das schreibst du für jedes Overlay einmal. In Wingo UI erledigen das die Overlay-Komponenten selbst. Der kostenlose Drawer ist auf dem Smartphone ein ziehbares Bottom Sheet, und sein Prop desktop legt fest, was er ab 768px wird: dasselbe Sheet, ein Seitenpanel oder ein zentrierter Dialog.
$ npx wingo-ui@latest add drawerDer Button in diesem Footer folgt denselben Regeln: Die mittlere Größe ist mit der Maus 40px hoch und wächst auf Touchscreens auf 44px, die kleine Größe behält ihr Aussehen und bekommt eine Trefferfläche von 44px.
Komponenten statt Kompositionen
Manche Einträge von shadcn/ui sind Anleitungen, die du selbst zusammenbaust. Sein Date Picker (opens in a new tab) ist eine Komposition aus Popover und Calendar ohne Root-Komponente DatePicker, und seine Data Table (opens in a new tab) ist eine Anleitung, wie du deine eigene auf TanStack Table v9 baust. Das ist eine nachvollziehbare Designentscheidung: Du formst jede Variante selbst.
Wingo UI liefert diese Teile als Komponenten mit Props. Der Date Picker ist ein Feld zum Tippen, das Daten in deinem Locale parst, Grenzen, gesperrte Tage und Presets annimmt und auf dem Smartphone ein Bottom Sheet mit 44px großen Tagen öffnet, damit die Tastatur den Kalender nie verdeckt:
$ npx wingo-ui@latest add date-pickerDie Data Table funktioniert genauso: Suche, Filter, Sortierung, Sammelaktionen, Pinning, Größenänderung und Virtualisierung auf TanStack Table v9, mit Zeilen, die unter 768px zu Karten werden. Beide sind Pro-Komponenten. Über den Komponenten liegen 43 Blocks (Anmeldung, Einstellungen, Dashboards, Checkout) und 45 Seitenvorlagen.
Updates, die deine Änderungen behalten
Den Quellcode zu besitzen heißt, dass du ihn änderst, und dann fixt upstream einen Bug in derselben Datei. Die shadcn CLI kann den Unterschied zeigen (add --diff) und einen Lauf vorab simulieren (--dry-run), aber einen Fix in eine Datei zu bringen, die du geändert hast, ist ein manueller Merge. Unser Guide zum Aktualisieren von shadcn-Komponenten, ohne Änderungen zu verlieren, automatisiert diesen Merge mit einem git-Skript.
Die Wingo UI CLI speichert die Version jedes Eintrags in wingo-ui.json und behält die installierte Kopie. So kann sie den 3-Way-Merge selbst ausführen:
Einträge, die du über die shadcn CLI installierst, haben keinen Versionseintrag, deshalb kann wingo-ui update nicht in sie mergen. Wenn dir Updates wichtig sind, installier Wingo-UI-Einträge mit der eigenen CLI.
Standardwerte, die du einmal setzt
Jeder visuelle Aspekt einer Wingo-UI-Komponente ist ein Prop mit Standardwert: Größe, Variante, Tone, Radius, Beschriftungen, Icons. UIProvider setzt app-weite Standardwerte, damit die neuen Komponenten zu deinem bestehenden shadcn/ui-Look passen, ohne dass du an jeder Aufrufstelle Props übergibst:
Wie schneiden die Werkzeuge für KI-Agenten ab?
Beide Bibliotheken veröffentlichen einen MCP-Server, aber die beiden erledigen unterschiedliche Aufgaben. Der shadcn MCP-Server (opens in a new tab) durchsucht und installiert Einträge aus jeder Registry in der components.json, auch aus Drittanbieter-Registries wie unserer, und npx shadcn@latest mcp init --client claude richtet ihn für Claude Code ein. Der shadcn Skill (opens in a new tab) liest mit shadcn info --json deine Projektkonfiguration, bevor der Agent Code schreibt.
Der Wingo UI MCP-Server beantwortet Suchanfragen und liefert Props mit Standardwerten, Design-Regeln und Theme-Tokens ohne Account; für den Quellcode brauchst du einen API-Key (einen kostenlosen Account für kostenlose Einträge, Pro für den Rest). Sein Tool check_updates vergleicht die Versionen in wingo-ui.json mit dem neuesten Release. Ein Befehl fügt den Server und eine Regeldatei für deinen Agenten hinzu:
Weil der shadcn MCP-Server die components.json liest, kann ein damit verbundener Agent auch aus @wingo-ui installieren, sobald der Registry-Eintrag da ist. Du kannst beide Server parallel betreiben. Das Tutorial zur shadcn Registry zeigt, wie du den Eintrag @wingo-ui hinzufügst und prüfst, was eine Installation schreibt, bevor du sie committest.
Wie nutzt du beide in einem Projekt?
Die meisten Teams, die Wingo UI ausprobieren, behalten shadcn/ui. Ein Setup, das funktioniert:
- Behalt shadcn/ui für die Teile, die es gut abdeckt und die du schon gestylt hast.
- Installier die Wingo-UI-Teile, die dir fehlen, mit
npx wingo-ui@latest add <slug>, einzeln, und committe vor jeder Installation. - Achte auf Kollisionen. Beide Bibliotheken schreiben
components/ui/button.tsx,dialog.tsxunddrawer.tsx. Die Wingo UI CLI behält eine vorhandene Datei, die abweicht, und bittet dich, den Befehl mit--overwriteerneut auszuführen. So entscheidest du, welche gewinnt. - Pass die Aufrufstellen an, wenn du eine Komponente austauschst. Der Button von shadcn/ui nutzt
variant="destructive"undvariant="secondary"; Wingo UI trennt Rolle und Farbe, daraus werden alsotone="danger"undvariant="soft". - Setz Standardwerte im
UIProvider, damit Radius und Größen zu den Komponenten passen, die du behalten hast.
Wingo UI oder shadcn: Was solltest du nehmen?
- Eine kostenlose, MIT-lizenzierte Desktop-first-App oder ein Design-System, das du komplett neu stylst: shadcn/ui.
- Ein Projekt mit Base UI oder React Aria: shadcn/ui, weil Wingo UI Radix mitbringt.
- Eine App, die auf Smartphone und Desktop genutzt wird, in der Overlays, Picker und Tabellen bei 390px funktionieren müssen: Wingo UI dazunehmen.
- Screens, die du sonst aus Einzelteilen baust, etwa eine filterbare Admin-Tabelle, Einstellungen oder ein Checkout: Blocks und Pro-Komponenten von Wingo UI (shadcn Blocks vs. Komponenten erklärt, wann du mit einem Block startest).
- Komponenten, die du änderst und trotzdem aktualisieren willst: die CLI von Wingo UI, wegen des 3-Way-Merge.
Der günstigste Test ist eine kostenlose Komponente auf deinem eigenen Smartphone. Installier den Drawer mit npx wingo-ui@latest add drawer (kein Account nötig), häng ihn in deinem shadcn/ui-Projekt hinter einen einzigen Trigger und öffne ihn bei 390px. Weitere direkte Vergleiche findest du unter Vergleiche und Alternativen.
Häufige Fragen
Ist Wingo UI mit shadcn/ui kompatibel?
Ja. Kostenlose Wingo-UI-Einträge installierst du über ihre URL mit npx shadcn@latest add, Pro-Einträge über die Namespace-Registry @wingo-ui in der components.json mit deinem API-Key. Die Ausnahme ist ein shadcn-Projekt mit einem Base-UI-Style, das asChild umschreibt; dort nimmst du npx wingo-ui@latest add.
Ist shadcn/ui für kommerzielle Projekte kostenlos?
Ja. shadcn/ui steht unter der MIT-Lizenz, du darfst es also kostenlos nutzen, ändern und in kommerziellen Produkten ausliefern. Die 75 kostenlosen Einträge von Wingo UI sind ebenfalls kostenlos, der Rest braucht eine Pro-Lizenz für $8 im Monat, $80 im Jahr oder $150 einmalig pro Entwickler.
Kann ich Wingo UI und shadcn/ui im selben Projekt nutzen?
Ja. Beide schreiben nach components/ui und nutzen Tokens von Tailwind CSS v4, das übliche Setup ist also shadcn/ui als Basis plus Wingo UI für die Komponenten, die du brauchst. Committe vor jeder Installation, denn gleichnamige Dateien wie button.tsx kollidieren.
Wie unterscheiden sich Updates bei shadcn/ui und Wingo UI?
Die shadcn CLI zeigt mit add --diff, was sich geändert hat, und ersetzt die Datei mit --overwrite; deine Änderungen zusammenzuführen bleibt deine Aufgabe. Die Wingo UI CLI speichert jede installierte Version und behält die installierte Kopie, deshalb führt npx wingo-ui@latest update einen 3-Way-Merge aus und behält deine Änderungen.
Funktionieren beide mit Claude Code und Cursor?
Ja. shadcn/ui hat einen MCP-Server und einen Skill für Coding-Agenten. Wingo UI hat einen MCP-Server, der auch die installierten Versionen auf Updates prüft, plus npx wingo-ui@latest agents install, das Regeldateien für Claude Code, Codex, Gemini CLI, Grok und Cursor schreibt.
- shadcn/ui
- Vergleiche
- React
- Tailwind CSS
- Mobile UI


