Once UI im Praxistest — wie ein Backend-Entwickler endlich Frontends baut, die er sich anschaut
Ich war nie ein Designer. Tabellen, Forms, Service-Layer — kein Problem. Aber sobald es um Spacing, Hierarchie und Farben ging, fing ich an zu raten. Mit Once UI war das schlagartig vorbei.
Ich war nie ein Designer. Sieben Jahre Java, Spring, Datenbanken und Architektur — alles, was hinter einer Oberfläche passiert, konnte ich. Sobald es um die Oberfläche selbst ging, fing das unangenehme Raten an: Sind 16px hier zu viel? Soll der Button eher rund oder eckig? Welcher Grauton sieht nicht billig aus? Frontends, die ich in den ersten sechs Jahren gebaut habe, funktionierten — aber ich habe sie selbst nie gerne angeschaut.
Vor drei Wochen habe ich diese Website von einer Vite-/Tailwind-Kombination auf Next.js 16 mit Once UI portiert. Erst da ist mir klar geworden, was mir die ganze Zeit gefehlt hatte: nicht ein Auge für Design, sondern ein System, das die Entscheidungen, die ich nicht kompetent treffen kann, für mich vorab entschieden hat.
Was Once UI ist — und wofür es nicht da ist
Once UI ist eine React/Next.js-Komponentenbibliothek vom Once-Magazine-Team. Sie liefert geometrische Primitive (<Column>, <Row>, <Grid>), Inhalts-Komponenten (<Heading>, <Text>, <Button>, <Card>) und ein Theme-System auf Basis von CSS-Custom-Properties. Sie wird kontinuierlich weiterentwickelt — ich habe während dieser Migration zwischen 1.6 und 1.7 gewechselt, ohne dass etwas gebrochen wäre.
Wichtig zu verstehen: Once UI ist kein Page-Builder und kein Komplettpaket à la Material UI. Wenn du Tabellen mit Filter-Köpfen, Datepicker-Dialoge oder komplexe Formulare brauchst, baust du sie selbst oder kombinierst eine zweite Bibliothek. Was Once UI dir gibt, ist genau das, was mir die ganze Zeit gefehlt hat: eine Grammatik für die Oberfläche.
Was als Backend-Entwickler den Unterschied macht
Spacing-Tokens. Spacing in Once UI ist eine diskrete Stufe — 0, 1, 2, 4, 8, 12, 16, 20, 24, 32, 40, 48, 56, 64, 80, 104, 128, 160. Wenn ich gap="6" schreibe, bekomme ich einen TypeScript-Fehler: Existiert nicht. Anfangs habe ich gegen diese Strenge gemurrt. Dann habe ich gemerkt, was sie eigentlich macht: Sie nimmt mir die einzige Entscheidung ab, bei der ich beim Frontend-Bauen immer verloren habe — welche Zahl die richtige ist. Die Antwort ist: eine der erlaubten. Punkt.
Theming als Daten-Attribut. Ein einziges data-brand- und data-accent-Attribut auf <html> setzt die ganze Farbpalette um. Die zwei Farben dieser Site (Blau als Brand, Indigo als Accent) sind in der Konfigurationsdatei einmal definiert — und durch die ganze Codebase hindurch über --brand-on-background-strong, --brand-alpha-weak und ähnliche Custom-Properties referenziert. Möchte ich morgen die ganze Site auf Grün umstellen, ist das eine einzeilige Änderung.
Die Layout-Primitive. Once UI verzichtet auf Tailwind-Style-Utility-Klassen. Stattdessen schreibe ich Markup wie diesen:
<Column gap="24" padding="32" maxWidth="m">
<Heading variant="display-strong-l">Headline</Heading>
<Text onBackground="neutral-medium">Beschreibung</Text>
</Column>Das ist kein flex flex-col items-stretch gap-6 p-8 max-w-2xl mehr — es ist gestaltete Inhaltsstruktur. Nach drei Tagen schreibe ich Frontends, die für mich verständlich sind, ohne eine Stylesheet-Datei daneben zu öffnen.
Wo es trotzdem hakte
Ehrlich, weil andere Migration-Reisende denselben Stolperfallen begegnen werden:
- Responsive-Props sind nicht überall reaktiv.
hide- und ähnliche bedingte Props funktionieren — aber an Breakpoints, die nicht immer dem entsprechen, was ich erwartete. Für den Header-Wechsel zwischen Desktop und Mobile habe ich am Ende reine CSS-Media-Queries geschrieben. Schneller als die Library-Internals nachzubauen. - Theme-Init ohne FOUC ist eine Detailarbeit. Damit der dunkle Modus nicht für 200 ms hell aufflackert, muss ein winziges Inline-Script vor der Hydration laufen. Die empfohlene Stelle dafür ist das Root-Layout — nicht das nested Locale-Layout, in dem ich es zuerst hatte. Ein ausführlicher Walkthrough dieses Stolperfalls steht in meinem Migration-Post (siehe unten).
- Spacing-Werte erlernen. Drei Tage lang habe ich bei jedem zweiten
gap-Wert in der TypeScript-Fehlerliste nachgesehen, welche Stufe als nächstes erlaubt ist. Inzwischen habe ich die Skala im Kopf.
Das Wichtigste: Ich vertraue dem Ergebnis
Vor Once UI habe ich Frontends gebaut, von denen ich hoffte, dass sie irgendjemandem gefallen — aber selten überzeugt war. Heute schicke ich Mockups raus und denke nicht mehr „Ist das jetzt zu viel Padding?" oder „Wirken die Farben billig?". Die Geländer sind eingebaut. Wenn ein Layout in Once UI mit der Standard-Token-Skala gebaut ist, sieht es nicht wie eine Hobby-Bastelei aus.
Das ist als Backend-Engineer eine Befreiung. Ich kann mich auf das konzentrieren, was ich kann — Architektur, Daten, Logik — und das Frontend trägt sich selbst, ohne dass ich zwei Tage pro Sektion Designer-Bauchgefühl simuliere.
Für wen ist Once UI?
Genau für Leute wie mich: Backend-/Full-Stack-Entwickler, die eine Marketing-Site, ein Portfolio oder einen Produktauftritt bauen wollen, ohne in die Designer-Rolle zu kippen. Es spart die mechanische Arbeit (Layout, Spacing, Theme), ohne dir eine Identität aufzudrängen, die nicht zu dir passt.
Die Site, die du gerade liest, ist die Referenz. Wenn du beim Scrollen einen Moment innehältst — Hero, Audiences-Spotlight, Pricing-Karten — schaust du auf Once UI plus eine Schicht eigener SCSS-Module. Mehr ist es nicht, und es war für jemanden ohne Design-Hintergrund das ehrlichste Werkzeug, mit dem ich je gearbeitet habe.
Wer mehr über die konkrete Migration wissen will — was beim Wechsel von Vite + Tailwind auf Next.js 16 mit Once UI tatsächlich brach — findet das im Migration-Post . Dort steht das Wie. Hier stand das Warum.