Design Goals
UI Elements Plus Code Organization
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.
No Build Steps
There was a time when managing CSS in a decent-sized codebase required features that Vanilla CSS didn't support - so as an industry we used tools like Sass, Less, and Stylus. But that's no longer the case. 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. Codebases that don't require a build step are much more future friendly than those that do.
Effortless Consistency
If you use Tailwind without a comprehensive component library or a full time 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 generally results in a more consistent UI.
We Style, You Space
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
.
Interoperability
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.
We would love to see authors build libraries for their specific framework on top of Base Styles. If you are interested in this, please go right ahead!