Dense UI
A component library built on the belief that whitespace is a budget, and dense tools have less of it to spend.
Most component libraries are designed for marketing sites. Dense UI is designed for the screen the user is still looking at two hours into a shift.
The default padding inside a button in most React libraries is generous — usually 12 to 16 pixels of vertical room, because the components were drawn in Figma at the scale of a hero section. That's fine for a pricing page. It's wrong for a triage queue. Dense UI starts from the opposite end: components are sized for tools, not landing pages, and density tokens make the same component compress further when the surface demands it.
The library ships three density modes — comfortable, compact, and dense — and the right one isn't a global theme. It's a property you set on a region of the page, because the same dashboard often needs comfortable forms next to compact tables next to a dense audit log. Components inherit density from the nearest DensityProvider, so the rules travel with the layout, not with the user's preference.
Underneath the density work is the unglamorous half of the project: Radix primitives for accessibility, Storybook for visual regressions, a bundle budget that fails CI if the core export grows past 18kb gzipped, and a release pipeline that treats the README as a first-class artifact.
Density is a region, not a theme
You set density on a DensityProvider around a panel, not on the body. The same page hosts comfortable forms and dense tables without either compromising.
The bundle has a budget that fails CI
Core exports stay under 18kb gzipped. Every new component justifies its weight before it merges. Treegrowth is a release blocker, not a footnote.
Accessibility is borrowed, not invented
Focus management, keyboard semantics, and ARIA wiring sit on Radix where possible. The library's job is density and visual rhythm, not re-litigating solved problems.