Most CSS libraries give you either: 1. A set of patterns for keeping things organized (E.g. Tailwind), or 2. A set of UI elements (E.g. Shadcn). We wanted something that gave us both.

We no longer need a compile step to build CSS libraries. CSS variables brought the ability to define and reuse design tokens, and CSS Nesting made building systems in a single file much easier to organize.

If you use Tailwind without a component library or a design team, your UI will start to accumulate minor visual inconsistencies over time. Tailwind’s recommended strategy is to first add CSS classes, then bundle your HTML into components. Ours removes the second step - you just add the classes and you’re done. This is one less thing for your team to worry about, and leaves you with a more consistent UI.

We agree with Caleb - “If you bake spacing utilities into your components, you end up constantly wrestling with and overriding them…which begets all sorts of badness.” We recommend including Tailwind Lite and using it for utility classes like flex flex-col gap-4.

Most “components” can be implemented with “add this class to this element on click/hover”, which means that for most component libraries, 95% of the work is in the styling and only 5% is in the interactivity. And yet, authors building UI libraries for a specific framework write all of their styling from scratch every time, rather than reusing and sharing a set of styles for, for example, their modal component.