Ein Entwickler öffnet eine Komponentenvorschau im Browser, markiert den TypeScript-Quelltext und fügt ihn in sein Repository ein. Zwischen Vorschau und produktivem Code liegt nur eine Zwischenablage: kein Installationsbefehl, kein Paket, keine Versionsverwaltung. Opensource UI, eine Sammlung kostenloser React- und Next.js-Komponenten, macht dieses Kopieren zum Prinzip. Ein offener Werkzeugkasten, aus dem du einzelne Werkzeuge mitnimmst, statt den ganzen Kasten zu abonnieren. Das klingt nach einem kleinen Unterschied, verändert aber, wie ein Projekt altert.
Bei klassischen UI-Bibliotheken liegt zwischen dir und deinem Code immer eine Schicht: das Paket, seine Version, seine Breaking Changes. Bei einem kopierten Bauteil fällt diese Schicht weg. Der Preis: Du ziehst Aktualisierungen selbst nach. Der Gewinn: Niemand außer dir entscheidet, wann sich deine Oberfläche ändert. Was die Bibliothek liefert, wie sie gebaut ist und wo die Grenzen dieses Ansatzes liegen, klärt der Rest des Textes.
Was die Bibliothek konkret ausliefert: über 200 Bauteile in 30 Kategorien
Die Komponentenübersicht der Projektseite zählt derzeit 207 Komponenten in 30 Kategorien; die Zahl 154 in 26 Kategorien, die auf der Startseite zitiert wird, stammt aus einem Nutzerkommentar und ist ein älterer Stand. Darunter Buttons, Formulare, Widgets, Social Cards, Loader und Tabellen. Dazu Bauteile, die in einer reinen UI-Bibliothek selten auftauchen: Uhrenvarianten mit analoger Anzeige, eine Notizbuch-Oberfläche mit Live-Wortzähler, Speicherindikator und Schreibfokus sowie ein Annotationswerkzeug für Pfeile, Labels und Callouts. Wer Produkte dokumentiert oder Features erklärt, muss Overlays für Screenshots nicht selbst bauen.
Jede Komponente liegt als Vorschau oben und als Quelltext darunter, dazwischen nichts weiter. Kopieren, einfügen, Importe korrigieren – laut Beschreibung der gesamte Integrationsaufwand. Ein npm-Paket namens Opensource UI gibt es bewusst nicht. Das ist keine Nachlässigkeit, sondern die Produktentscheidung.
Der Unterbau: React, Next.js, TypeScript und Tailwind CSS v4
Die Komponenten sind für React und Next.js geschrieben, in TypeScript typisiert und mit Tailwind CSS v4 gestylt. Icons kommen aus Lucide. Die Gestaltung sitzt damit nicht in einer externen Konfiguration, sondern in denselben Utility-Klassen, die du ohnehin im Projekt schreibst. Wer mit Tailwind arbeitet, findet sich sofort zurecht. Wer CSS-Module oder Styled Components nutzt, muss die Klassen beim Einfügen übersetzen oder die Datei anpassen – das ist der eigentliche Aufwand bei diesem Modell.
Die Komponenten arbeiten mit Basisstilen und md:-Varianten, nicht mit sm:. Das ist eine bewusste Entscheidung: erst der mobile Grundzustand, dann ein Sprung für größere Bildschirme, statt vieler kleiner Zwischenstufen, die nach zwei Jahren niemand mehr pflegt. Beim Fokus ist es ähnlich: Der Zustand wird über eine Rahmenänderung sichtbar, nicht über farbige Ringe. Solche Entscheidungen fallen erst auf, wenn man vierzig Bildschirme gebaut hat und merkt, dass nichts gegeneinander arbeitet.
Apple Watch, iPod und Browser-Frames: Mockups für Präsentationen
Auffälligster Teil der Sammlung sind die Gerätemockups. Die Apple-Watch-Rahmen kommen mit Sportband, abgerundetem Display und sieben Metalloberflächen, gedacht für Komplikationen, Fitnessringe oder Now-Playing-Ansichten. Der iPod Classic bringt Screen-Slot und Click Wheel mit, in Silber, Schwarz, Pink und Blau. Dazu iPhone, MacBook, iPad und ein Browserfenster in heller, dunkler oder transparenter Ausführung.
Der Sinn dieser Rahmen ist konkret: Wrist-UI soll nativ wirken und nicht aufgeklebt, ein Retro-Menü sofort wiedererkennbar, und ein Web-Screenshot soll fertig aussehen, bevor er überhaupt veröffentlicht ist. Für Pitches, Portfolios und Dokumentationen spart das Zeit. Du platzierst deinen Screenshot im vorgegebenen Slot, statt Perspektive, Schatten und Materialstärke selbst nachzubauen. An dieser Stelle scheitern selbstgebaute Mockupserien erfahrungsgemäß am schnellsten.
MIT-Lizenz, kommerzielle Nutzung und was Sponsoring nicht ist
Die FAQ des Projekts beantwortet die Lizenzfrage direkt. Alle Komponenten stehen unter der MIT-Lizenz, für private und kommerzielle Nutzung, dauerhaft. Es gebe kein „kostenlos, aber“ mit einer Bedingung, die später greift. Sponsoring ist freiwillig, schaltet keine Bauteile frei und macht aus der Bibliothek kein Abonnement. Nach dem Einfügen gehört dir die Datei: Du darfst denselben Button, dasselbe Widget oder Mockup in mehreren React- und Next.js-Anwendungen verwenden, Props umbenennen und das Styling anpassen.
Das Modell hat eine Kehrseite. Ohne Paket gibt es keine zentrale Fehlerbehebung, die bei dir ankommt. Wenn du zwanzig Projekte mit derselben kopierten Tabelle betreibst und eine Barrierefreiheitslücke gefunden wird, korrigierst du sie zwanzig Mal – oder du baust dir eine eigene interne Kopie. Für Einzelentwickler und kleine Teams ist das ein guter Tausch. Für Organisationen mit vielen Repositories und einer Designabteilung, die zentral steuern will, ist es ein bewusster Verzicht auf Bequemlichkeit.
Die Designsprache: warum die Bühne hell und leise bleibt
Die visuelle Linie nennen die Macher eine neutrale Bühne: Papierweiß, Tintentext, feine Rahmen. Akzentfarben erscheinen nur dort, wo ein Zustand oder eine Demo sie braucht. Keine Verlaufs-Dashboards, kein Leuchten um des Leuchtens willen, Bewegung respektiert reduzierte Animationen. Laut Projekt sollen die Oberflächen aussehen wie ausgeliefert, nicht wie eine Demo.
Einen Dunkelmodus liefert die Bibliothek nicht mit. Begründung: Die Vorschauen sollen untereinander konsistent bleiben, dunkle Varianten entstehen im eigenen Projekt. Das kann man als Einschränkung lesen – oder als klare Arbeitsteilung: Die Bibliothek kümmert sich um Struktur und Abstände, das Farbsystem bleibt deine Sache. Plane diese Arbeit ein, wenn dein Produkt beide Modi unterstützt.
Was Nutzer auf Product Hunt und Twitter anmerken
Die zitierten Rückmeldungen loben vor allem die Kohärenz. Niyazi Gözkenç schreibt auf Product Hunt, es sei beeindruckend, wie die Komponenten zusammengehörig wirken, ohne uniform zu sein, und führt das auf Abstände, Typografie und Interaktionsdetails zurück. Boran beschreibt die Sammlung als kuratiertes Set statt als Dateihalde. Auffällig: eine Zahlenabweichung in den Zitaten. In einem Zitat ist von 33 Kategorien die Rede, in einem anderen von 26, die Komponentenübersicht zählt derzeit 30. Das sind Momentaufnahmen aus einem wachsenden Katalog, keine unabhängigen Tests.
Weitere Stimmen kommen vom CEO von Seam, der den Gerätespielplatz als Aufhänger nennt, von Saïd Aitmbarek (Microlaunch) mit einem knappen Lob und von Patrick Chen (runs.space), der die 154 Komponenten als Substanz bewertet. Brauchbar als Stimmungsbild, nicht als Prüfsiegel. Wer die Bibliothek einsetzen will, sollte zwei oder drei Komponenten kopieren, in ein bestehendes Projekt legen und den Importpfad korrigieren. Erst dabei zeigt sich, ob der Stil zu deinem System passt.
Was das für dein Projekt bedeutet
Am Ende der FAQ steht ein Hinweis: Opensource UI ist ein eigenständiges Projekt mit eigenem Designsystem, offizielle Adresse ist ausschließlich opensourceui.in. Verwechslungen mit gleichnamigen oder ähnlich klingenden Bibliotheken anderer Anbieter sind möglich und nicht beabsichtigt. Wer den Quelltext verwenden will, sollte die Domain prüfen, bevor er Code in ein produktives Repository übernimmt.
Sinnvoll ist der Ansatz, wenn du schnell zu einer fertigen Oberfläche kommen willst und den kopierten Code wie eigenen behandelst. Weniger sinnvoll, wenn du zentrale Updates über viele Teams hinweg brauchst. Der Preis für null Euro ist nicht versteckt: Er heißt Wartung und liegt vollständig bei dir.
Quelle: opensourceui.in
