Shadcn/UI wechselt den Standard von Radix zu Base UI

 (ui.shadcn.com)
3 Punkte von GN⁺ 5 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • shadcn/ui stellt ab Juli 2026 den Standard-Flow für neue Projekte und die Dokumentation auf Base UI um und rückt damit vom seit dem Launch 2023 geltenden Radix-Standard ab
  • Base UI hat die stabile Version 1.6.0 erreicht und kommt auf mehr als 6 Millionen Downloads pro Woche; auch in shadcn/create-Projekten wird es im Verhältnis 2:1 häufiger als Radix gewählt
  • Radix wird nicht eingestellt; bestehende Apps können unverändert bleiben, und abgesehen von Komponenten, die nur in Base UI existieren, werden weiterhin Updates und neue Komponenten bereitgestellt
  • Die Migration wird nicht als codemod, sondern als Agent-skill angeboten: Geänderte Komponenten und ihre Verwendungsstellen werden komponentenweise schrittweise migriert, inklusive .migration/-Reports und Git-Commits
  • Mit Komponenten für Chat-UIs, GitHub-Repository-basierten Registries, shadcn eject und dem neuen Stil Rhea erweitert shadcn/ui seinen Umfang von der Komponentenverteilung bis zur gesamten Gestaltung von Produkt-UIs

Base UI wird zur Standard-Komponentenbibliothek

  • Ab Juli 2026 wird Base UI als Standard-Komponentenbibliothek von shadcn/ui festgelegt
  • shadcn/ui wurde beim Start im Januar 2023 auf Basis von Radix entwickelt; Radix war damals eine Option mit ungestylten Headless-Komponenten, APIs, Barrierefreiheit und praktischer Erfahrung im Einsatz in echten Apps
  • Base UI ist eine neue Bibliothek der Personen, die Radix entwickelt haben; shadcn/ui hat unter Beibehaltung der bestehenden Abstraktion alle Komponenten für Base UI neu umgesetzt
  • Im Dezember 2025 wurde es in npx shadcn create möglich, zwischen beiden Bibliotheken zu wählen, und im Januar 2026 wurde die Base-UI-Dokumentation fertiggestellt

Gründe für den Wechsel des Standards

  • Stabilität und Nutzungsmuster von Base UI

    • Die Base-UI-Version ist 1.6.0
    • Die wöchentlichen Downloads liegen bei über 6 Millionen
    • Das Base-UI-Team veröffentlicht regelmäßig neue und nützliche Komponenten
    • Neue shadcn/ui-Projekte verwenden Base UI
    • Projekte, die mit shadcn/create erstellt werden, wählen Base UI im Verhältnis 2:1 häufiger als Radix
    • shadcn/ui spiegelt dieses Nutzungsmuster nun im offiziellen Standard wider

Änderungen für neue Projekte und die Dokumentation

  • Wenn in einem neuen Projekt npx shadcn init ausgeführt wird, ist Base UI die Standardauswahl
  • shadcn/create zeigt Base UI zuerst an
  • Die Komponentenseiten in der Dokumentation öffnen standardmäßig den Base-UI-Tab; die Radix-Dokumentation ist mit einem Klick erreichbar

Was Radix-Nutzer wissen sollten

  • Radix wird weiterhin unterstützt

    • shadcn/ui behält die Radix-Unterstützung bei
    • Abgesehen von Komponenten, die nur in Base UI existieren, werden alle Updates und neuen Komponenten für beide Bibliotheken bereitgestellt
    • Bestehende Apps müssen nicht migriert werden
    • Radix ist eine ausgereifte und getestete Bibliothek
    • Auch shadcn/ui nutzt Radix weiterhin in Produktion und migriert die eigenen Projekte nicht
    • Wer Radix für neue Projekte bevorzugt, kann ein Flag verwenden
    • Wenn Skripte oder CI shadcn init nicht interaktiv ausführen und Radix erwarten, muss -b radix ergänzt werden, um den bisherigen Pfad beizubehalten
    • Wer beim Erstellen einer registry eine bestimmte Bibliothek festschreiben will, kann eine registry:base-Einstellung bereitstellen
    • Einträge ohne diese Einstellung werden nun mit Base UI initialisiert
    • Für neue Projekte wird Base UI empfohlen

Vorgehen bei der Migration zu Base UI

  • Die Migration ist nicht verpflichtend, kann aber bei Bedarf mit einem skill erfolgen
  • Einen Coding-Agent kann man zum Beispiel so beauftragen
    • migrate accordion to base-ui
  • Der Standardansatz ist eine schrittweise Migration
    • Komponenten und ihre Verwendungsstellen werden einzeln migriert
    • Das Projekt bleibt weiter im grünen Zustand und deploybar
    • Während der Arbeit koexistieren beide Bibliotheken
    • Man kann zwischendurch stoppen und später fortfahren
    • Bei Bedarf kann auch das gesamte Projekt auf einmal angefragt werden

Warum ein skill statt eines codemod gewählt wurde

  • shadcn/ui-Komponenten sind Code, den Nutzer besitzen und verändern; ein codemod mag für unveränderte Komponenten passen, kann bei modifizierten Komponenten aber brechen
  • Der skill enthält Namensänderungen, prop-Änderungen und Verhaltensunterschiede, die anhand beider Bibliotheken manuell geprüft wurden
  • Der Agent erkennt die vom Nutzer vorgenommenen Änderungen und übernimmt sie auch in das Migrationsziel
  • Mechanisch verarbeitbare Änderungen werden projektweit angepasst
    • Beispiel: asChild wird zu render
  • Verhaltensänderungen werden nicht stillschweigend gepatcht, sondern angezeigt; die endgültige Entscheidung trifft der Nutzer

Ergebnisse der Migration

  • Jeder Lauf hinterlässt drei Ergebnisse
    • Funktionierender Code: Vor dem Erfolgsbericht werden Typecheck und Build ausgeführt
    • Komponentenbezogener Report: In .migration/ im Projekt-Root werden Änderungen, unveränderte Teile und eine Checkliste für manuelle Prüfung abgelegt
    • Saubere Git-Historie: Auf dem Branch wird pro Komponente ein Commit erstellt; für ein Rollback reicht es, den Branch zu löschen
  • Ein Beispielreport ist .migration/accordion.md und enthält folgende Abschnitte
    • Changed
    • Left alone
    • Behavior changes
    • Verify by hand
  • Da der Fortschritt ohne versteckten Zustand in Dateien und der Git-Historie verbleibt, kann jeder Agent und jede Session die Arbeit fortsetzen
  • Funktioniert mit Claude Code, Cursor und Agenten, die skills unterstützen
  • In Tests mit echten Projekten waren von mehr als 60 Komponenten 36 Radix-basiert; die vollständige Migration dauerte etwa 25 Minuten und benötigte rund 10.000 Token pro Komponente
  • Der Build lief sauber durch, und Customizing blieb erhalten

Neue Komponenten für Chat-Interfaces

  • Im Juni 2026 wurden neue Komponenten zum Erstellen von Chat-Interfaces hinzugefügt
  • Der erste Schritt besteht aus den Kernbausteinen für eine Konversationsebene
    • Scrollen
    • Nachrichtenzeilen
    • Sprechblasen
    • Anhänge
    • Marker
  • MessageScroller ist ein Scroll-Container für Konversationen
    • anchored turns
    • streamed replies
    • saved thread restore
    • prepended history
    • jump-to-message
    • scroll controls
    • visibility tracking werden verarbeitet
  • MessageScroller besitzt keine Nachrichten, AI-Zustände, Versand, Speicherung oder Modellzustände; den Content-Renderer stellt der Nutzer bereit
  • MessageScroller ist auch als ungestylte Headless-Komponente in @shadcn/react verfügbar

Rolle von Message, Bubble, Attachment und Marker

  • Message layoutet eine Zeile der Konversation
    • Avatar
    • Ausrichtung
    • Header
    • Inhalt
    • Footer
    • gruppierte Nachrichten
  • Bubble rendert die Oberfläche einer Nachricht
    • variants
    • Ausrichtung
    • reactions
    • links
    • buttons
    • collapsible content werden unterstützt
  • Attachment rendert Dateien und Bilder
    • media
    • metadata
    • upload state
    • actions
    • bietet einen full-card trigger, der separat anklickbare actions beibehält
  • Marker rendert Statusupdates, Systemnotizen, Randzeilen und Label-Trennlinien
    • Wird für streaming state
    • tool activity
    • und date breaks verwendet
  • Diese Komponenten sind klein gehalten und lassen sich für AI-Chat, support inbox, team thread, group chat und produktspezifische Konversations-UIs kombinieren

CSS-Utilities für Chat-UIs und @shadcn/react

  • Zwei neue CSS-Utilities wurden hinzugefügt
    • scroll-fade: Fügt an den Rändern eines Scroll-Containers einen Fade zur besseren Scroll-Wahrnehmung hinzu
    • shimmer: Fügt Live-Statustexten wie "Thinking…", "Generating response…", Tool-Ausführung und Streaming-Markern einen Shimmer hinzu
  • Beide Utilities sind in shadcn/tailwind.css enthalten
    • In Projekten, die mit npx shadcn@latest init initialisiert wurden, sind sie bereits enthalten
  • @shadcn/react ist ein neues Paket für ungestylte Headless-React-Komponenten
    • Das erste Primitive ist @shadcn/react/message-scroller
    • Registry-Komponenten umhüllen es im shadcn/ui-Stil, aber Scroll-Verhalten wie anchoring, auto-follow, prepend preservation, scroll commands und visibility liegen im Paket
  • Dieser Ansatz stellt Verhalten bereit, ohne an visuelle Styles gebunden zu sein, und ermöglicht es, schwierige Interaktionslogik an einer Stelle zu testen
  • Nutzbar sowohl mit Radix als auch mit Base UI

Verhältnis zu AI Elements

  • Die neuen Chat-Komponenten ersetzen AI Elements nicht
  • Die AI-Interface-Komponenten und Patterns von AI Elements können weiterhin verwendet werden
  • Dieser Release konzentriert sich darauf, die Kernbausteine für Chats Stück für Stück in shadcn/ui zu bringen
  • Wer bereits AI-Elements-Komponenten nutzt, muss die App nicht neu schreiben
  • Wenn neuere Abstraktionen, aktualisierte Styles oder Unterstützung sowohl für Radix als auch für Base UI benötigt werden, kann die shadcn/ui-Version ausprobiert werden

GitHub-Repositorys als registry verwenden

  • Seit Juni 2026 können öffentliche GitHub-Repositorys als registry verwendet werden
  • Fügt man im Repository-Root eine registry.json hinzu und definiert die zu verteilenden Einträge, können Nutzer sie mit der shadcn-CLI direkt von GitHub installieren
  • Eine GitHub-registry ist eine Source-registry
    • shadcn build muss nicht ausgeführt werden
    • Generierte item-JSON-Dateien müssen nicht veröffentlicht werden
    • Es muss kein registry-Server eingerichtet werden
  • Die CLI liest die registry.json im Root, interpretiert include-Einträge, findet den angeforderten Eintrag und installiert die entsprechenden Dateien
  • Registry-Einträge sind nicht auf Komponenten beschränkt
    • components
    • hooks
    • utilities
    • design tokens
    • feature kits
    • project conventions
    • agent instructions
    • testing setup
    • CI workflows
    • release workflows
    • templates
    • codemods
    • migration kits
    • und weitere Projektdateien können verteilt werden
  • GitHub-registry-Adressen funktionieren mit denselben Befehlen wie bestehende registry-Adressen
    • list
    • search
    • view
    • install

shadcn eject und shadcn/tailwind.css

  • Durch die Unterstützung sowohl von Radix als auch von Base UI wurde ein Ort für gemeinsam genutzte Tailwind-Utilities benötigt, von denen beide Bibliotheken abhängen
    • Beispiel: custom variants wie data-open: und data-closed:
    • Beispiel: utilities wie no-scrollbar
  • Auch einige Bugs während der RTL-Unterstützung ließen sich leichter an einer Stelle beheben, statt sie in allen Komponenten doppelt anzuwenden
  • Dafür wurde shadcn/tailwind.css erstellt
    • Bei init wird der globalen CSS-Datei @import "shadcn/tailwind.css" hinzugefügt
    • Es verhält sich wie ein CSS-Import à la tw-animate-css
    • In Produktion ist es eine kleine Abhängigkeit, die tree-shaken und zur Build-Zeit aufgelöst wird
  • Wer keine CSS-Abhängigkeit vom shadcn-Paket möchte, kann shadcn eject verwenden
    • shadcn/tailwind.css wird in die globale CSS-Datei inline eingefügt
    • Die shadcn-Abhängigkeit wird aus dem Projekt entfernt
  • In einem Monorepo muss der Befehl in dem Workspace ausgeführt werden, in dem sich components.json und die globale CSS-Datei befinden

Neuer Stil Rhea

  • Im Mai 2026 wurde der neue shadcn/ui-Stil Rhea hinzugefügt
  • Rhea ist ein kompakteres Luma mit kleineren Abständen und dichter angeordneten Surfaces, entwickelt für fokussierte Produkt-Interfaces
  • Rhea behält die Weichheit und Formen von Luma bei, platziert Buttons, Inputs, Menüs, Cards und Listen aber enger
  • Der Weg, --spacing von Luma anzupassen, wurde nicht gewählt
    • --spacing ist ein Multiplikator; eine Änderung würde die Bedeutung vertrauter Tailwind-Utilities wie p-2, w-4 und m-16 in der gesamten App verändern
  • Rhea wird als eigener Stil angeboten, um component size, gap und density direkt anzupassen, während die zugrunde liegende Utility-Skala vorhersagbar bleibt
  • Rhea ist in shadcn/create sowohl für Radix als auch für Base UI verfügbar

Verwandte Beiträge

1 Kommentare

 
GN⁺ 5 시간 전
Meinungen auf Hacker News

  • In diesem Beitrag ist Claudes typischer Schreibstil ziemlich deutlich zu spüren; inzwischen wirkt das auf mich ermüdend und distanziert.
    Wenn nicht einmal ein wichtiger Produktlaunch-Text die volle Aufmerksamkeit eines Menschen wert ist, weiß ich nicht, wo man die Grenze ziehen soll.

    • Der Text hat die nötigen Inhalte effektiv vermittelt und wirkte so, als sei er für Menschen gut lesbar geschrieben und strukturiert worden.
      Wenn er mit AI geschrieben wurde und dadurch mehr Zeit für die Entwicklung dieser großartigen Open-Source-Software blieb, sehe ich das eher positiv.
    • Ich weiß genau, was du meinst. Ich nutze Claude und plannotator häufig, und es wurde deutlich besser, nachdem ich einen bestimmten Styleguide angefordert hatte.
      Als Ausgangs-Prompt habe ich „MSDN-Referenz aus der CD-Ära und der Stil von Raymond Chens Blog“ genommen; dadurch ist meine Fähigkeit, AI-erstellte Pläne zu verarbeiten, stark gestiegen. Der Stil ist bescheiden, aufschlussreich und respektiert die Leserschaft – sehr zu empfehlen.
    • Ich habe den Text gelesen und er klang für mich nicht wie von AI geschrieben.
      Es wäre irgendwie lustig, wenn jetzt jemand aus dem Team vortritt und sagt, dass ein Mensch ihn geschrieben hat.
    • Ernst gemeinte Frage: Warum ist das wichtig? Sie könnten einen Entwurf geschrieben, dann Claudes Formulierungen geprüft und ihn veröffentlicht haben.
      Ich verstehe nicht, warum man jedes Mal versuchen muss, AI „zu erwischen“, wenn sie bei der Arbeit hilft; das ist kein F500-Unternehmen, sondern ein Open-Source-Projekt. Die Ressourcen sind begrenzt, und Englisch ist vielleicht nicht ihre Muttersprache.
    • Ich finde nicht, dass man es als ermüdend abtun sollte. Die Art, wie es derzeit verwendet und präsentiert wird, ist nämlich nahe an Täuschung und Lüge.
      Ich glaube, eine Kultur der Zusammenarbeit braucht Vertrauen und Wahrheit, und ich möchte keine Texte, in denen AI fälschlich sagt: „Ich habe das getan/gesagt“.
      Wenn dieser Text zum Beispiel wirklich von Claude geschrieben wurde, frage ich mich, warum er mit Formulierungen wie „I said“ oder „I meant it“ so tut, als spreche ein Mensch aus dem Team direkt. Das ist Imitation und täuschend. Eine Kultur, die Zusammenarbeit und Ehrlichkeit bewahrt, sollte sagen: „Mein Mensch hat gesagt“, oder zumindest klar kennzeichnen, dass hier eine AI stellvertretend für einen Menschen handelt.

  • Bei langweiligen Anwendungen frage ich mich, ob Leute den Copy-and-paste-Ansatz von shadcn wirklich traditionellen UI-Libraries wie Mantine vorziehen.
    Copy-and-paste lässt sich leicht anpassen, schafft aber auch neue Probleme. Aus etwas, bei dem man einfach nur die Versionsnummer erhöhen müsste, wird dann etwas, wofür man einen Upgrade-AI-Agenten braucht.

    • Die Aussage „einfach nur die Versionsnummer erhöhen“ unterschätzt die Kopfschmerzen, die Material UI in den letzten Jahren verursacht hat, gewaltig.
      Nicht bei langweiligen Apps, sondern bei sehr großen Apps wurden bei jedem Major-Version-Update die APIs stark umgekrempelt, sodass langweilige Migrationen nötig waren. Nach dem Wechsel zu shadcn wurde es einfacher: Man kann einzelne Komponenten upgraden und neue Komponenten frei hinzufügen. Bei Material UI musste man alles auf die neue API umstellen, wenn man irgendwo ein neues Feature nutzen wollte; bei shadcn geht das selektiv.
    • Den Copy-and-paste-Ansatz habe ich überhaupt nicht verstanden. Shadcn riecht einfach nach Hype, und auch nachdem ich es selbst kopiert und ausprobiert habe, weiß ich nicht, was daran so großartig sein soll.
      Aber wenn man es gern nutzt, nur zu; einer der Vorteile von AI ist immerhin, dass HN nicht mehr so sehr wie früher von Diskussionen über JavaScript-Frameworks verstopft ist.
    • Bei neuen Projekten tendiere ich immer stärker zu Vendoring.
      Eine fertige UI-Library einzubinden ist kurzfristig einfach, aber meist übermäßig komplex, implementiert Funktionen, die man gar nicht nutzt, ist schwer anzupassen, wenn man sich von zahllosen anderen Apps mit derselben Library unterscheiden will, und beim Upgrade gehen diese Anpassungen subtil kaputt. Meiner Ansicht nach ist der beste Ansatz, die eigene UI-Library zu bauen. Man besitzt sie selbst, kann sie über mehrere Projekte hinweg wiederverwenden, bei Bedarf denselben visuellen Stil beibehalten und nur die Funktionen hinzufügen, die man wirklich braucht.
    • Mantine ist großartig. Man kann damit sehr schnell fast alles bauen und es später erweitern oder Themes und einzelne Komponenten vollständig anpassen.
      Es gibt eine Lernkurve, aber ich finde nicht, dass sie riesig ist.
    • In vielen Systemen ist es in der Praxis fast nie „einfach nur die Versionsnummer erhöhen“. Das funktioniert nur, wenn die Komponenten-Library genau das tut, was man braucht.
      In der Realität liefern Komponenten oft nicht vollständig das gewünschte Verhalten, und Leute hängen häufig zusätzliches CSS an Komponenten. Wenn die Alternative mehrere Stunden Arbeit wären, sind zwei Zeilen CSS sehr verlockend; aber auch diese zwei Zeilen muss man bei jeder neuen Funktion der Komponenten-Library überprüfen. Wenn sich solche CSS-Flicken häufen, wird ein Upgrade zu einem eigenen Projekt.

  • Mich stört, dass diese beliebten UI-Toolkits übermäßig viele divs rendern.
    Wenn man sich Base UI anschaut, heißt es bei fast jeder Komponente sinngemäß, sie „rendert ein Element“; für ein Akkordeon gibt es aber native Elemente wie details/summary, die dasselbe leisten können. Ich bin kein Verfechter eines rein nativen Webs und sehe viele Probleme bei Web-APIs, besonders auch bei HTML, aber div-Missbrauch ist ebenfalls falsch.

  • Ich habe Shadcn benutzt und mag es insgesamt, aber die Radix-basierten Radio-Buttons waren etwas übertrieben. Es gibt auch Selects, bei denen eine ähnlich aufgeblähte Lösung verwendet wird.
    https://news.ycombinator.com/item?id=46688971

  • Interessant ist der Trend, dass Migrationsarbeit von codemod zu LLMs wandert
    Auch wenn codemod deterministischer ist, frage ich mich, ob diese Ära zu Ende geht

    • Ich frage mich, wie es wäre, mit LLMs deterministische codemods zu erstellen
      Danach könnte man den codemod ausführen, weitere deterministische Sicherheitsnetze hinzufügen und iterieren, und die Ergebnisse wieder ins LLM geben, um den codemod zu verbessern
    • Das Framing des Originalartikels ist eine gefährliche Denkweise. Der codemod selbst kann vorhanden sein oder auch nicht
      Was man will, sollte keine Skill-Datei für ein LLM sein, sondern Dokumentation für Menschen. Man sollte einfach einen Migrationsleitfaden für Menschen schreiben. Es wird wohl eine Weile dauern, bis man erkennt, dass Skill-Datei und Dokumentation letztlich dasselbe sein sollten
    • Ich frage mich, was codemod hier bedeutet
    • Ich denke, die beiden ergänzen sich perfekt und werden das auch künftig tun
      Für weiche Regeln nutze ich weiter eine AGENTS.md-Datei, für harte Regeln eigene Linter-Regeln; für mich ist das die Art, die Vorteile beider Welten mitzunehmen

  • Ich würde gern shad-CN verwenden, lande aber jedes Mal am Ende wieder bei Mantine
    Das ist viel schneller, als sich zu merken, welche Kontexte man verdrahten muss

  • Ich frage mich, ob diese Änderung für Nutzer bessere Ergebnisse bringt, etwa eine geringere Bundle-Größe
    Oder ob es eher eine Änderung ist, die die Lebensqualität der Shadcn-Maintainer verbessert

  • Ich frage mich, was in Angular dem Pendant zu shadcn/ui entspricht
    PrimeNG hat kürzlich die Lizenz geändert, daher suche ich nach einer passenden Alternative für neue Projekte

    • Zwei Versuche[1], die PrimeNG-Lizenzänderung auf HN zu platzieren, sind gescheitert, aber wenn ihr PrimeTek-Komponentenbibliotheken nutzt, solltet ihr diese Änderung kennen
      PrimeNG, PrimeReact und PrimeVue werden alle vollständig Closed Source, und ab 2027 kostet eine Lizenz für die fortlaufende Nutzung 800 Dollar pro Entwicklerplatz[2]. Die bestehenden Repositories werden archiviert[3]. PrimeFaces bleibt Open Source, wird aber nun von unabhängigen freiwilligen Entwicklern entwickelt und gewartet, nicht mehr von PrimeTek-Mitarbeitern
      [1]: https://hn.algolia.com/?q=The+Next+Chapter+of+PrimeTek
      [2]: https://primeui.dev/nextchapter
      [3]: https://github.com/primefaces/primeng
    • Bei uns ist es genauso. Wir haben bei der Arbeit in mehreren Apps PrimeNG verwendet und werden wohl an Angular 21 gebunden sein, bis wir einen geeigneten Ersatz finden
      Allerdings hat eine Gruppe PrimeNG geforkt und plant, es zu warten. Der neue Name steht noch nicht fest
      https://github.com/openng-org/open-prime
    • https://spartan.ng/
    • Als Reaktion darauf, dass ein System ähnlich Shadcn noch nicht direkt für verschiedene Stacks wie Svelte, Angular oder Nunchucks verfügbar ist, bauen wir das Lily Design System
      Alles ist kostenlos und Open Source; wenn ihr Feedback oder Vorschläge schickt, können wir sie leicht in Lily aufnehmen
      https://lilydesignsystem.github.io
    • https://www.zardui.com

  • Ich vermisse die alten skeuomorphischen Styleguides
    Der letzte war, glaube ich, Blueprint

  • Die URL sollte https://ui.shadcn.com/docs/changelog/2026-07-base-ui-default sein