coss ui is the least fashionable kind of registry and one of the more useful ones: primitives, done plainly, with no effects. 29 components here, and the list reads like a product's component inventory rather than a landing page's.
What is in it
Calendar, Table, Combobox, Drawer, Menu, Tabs, Switch and Breadcrumb.
That is the boring half of an application, which is exactly the half that decides whether a product is usable. A combobox with correct typeahead, a table with real th elements, a drawer that traps focus: each of those is a small pile of behaviour, and the guides on dropdowns, data tables and dialogs go through what each one owes its reader.
Where a plain set fits
Next to shadcn/ui rather than instead of it. The compatibility test is the thing to run: a plain primitive is valuable only if it reads your tokens, because a plain component with hardcoded colours is worse than a decorated one you were always going to restyle.
The practical use is filling gaps. shadcn/ui does not ship every primitive, and a second plain source that shares the visual language is a better answer than a decorated component you have to strip down.
Why unfashionable sets are worth checking
Two reasons the long-tail guide generalises.
Registries converge on what gets attention, which is heroes, backgrounds and text effects. The result is that the animated shelves are crowded and the primitive shelves are not, so a set of plain components is competing with fewer alternatives for the thing you actually need on a settings page.
And a plain component is easier to judge. There is no effect to be impressed by, so the questions are the ones that matter: does it read tokens, is the keyboard path there, are the states beyond the happy path present. The review checklist is the same pass either way.
Where else to look
The honest list, because the answer is not always us:
| Source | Best for | Trade-off |
|---|---|---|
| shadcn/ui | The primitive set most projects start from | Does not cover every primitive |
| Origin UI | The same primitives with more variants | No sections or effects |
| Radix / Base UI | Behaviour with no styling at all | You write every pixel |
| 21st | Plain primitives alongside everything else, with previews | Quality varies by author, so preview before you take it |
Taking one
Every component page has a live preview and the code. Installing goes through the shadcn CLI against our registry:
That key comes from your 21st account, and installs require a membership. Set API_KEY_21ST once in your shell and the command works for anything in the catalogue.
Frequently asked
- Why use a plain component set?
- Because the boring half of an application decides whether it is usable, and registries converge on heroes and effects rather than comboboxes and tables. A plain set competes with fewer alternatives for exactly the components a settings page needs.
- Does a plain component still need checking?
- Yes, and it is easier to check, because there is no effect to be impressed by. The questions are whether it reads your tokens, whether the keyboard path is there, and whether the states beyond the happy path exist.
- Where does it fit next to shadcn/ui?
- Beside it rather than instead of it. shadcn does not ship every primitive, and a second plain source that shares the visual language is a better gap-filler than a decorated component you would have to strip down.
- What makes a plain primitive valuable?
- Reading your CSS variables. A plain component with hardcoded colours is worse than a decorated one, because you were always going to restyle the decorated one and you expected the plain one to fit.