The whole point of a design system is not to have local overrides.

In a design system. You specify variants of a component. Each one has its own combination of style defined by the design system.

You do not set „Gap“ to 2. you would specify smth like „small“, „medium“ or „large“ as props.

This is not a tailwind issue.

`2` in this case is a design token that is defined in a theme, that would resolve to a length defined in a CSS unit (ideally rem).

How would you handle a design change where a size becomes required that fits between "small" and "medium"? These things happen throughout the lifetime of a project.

Opaque numerical design tokens may not be the most explicit to understand, but they allow for expansion.

> The whole point of a design system is not to have local overrides.

Are you unfamiliar with having-a-boss?

He is familiar with the boss being the one mandating the design system, and not the one asking "can we push that button a few pixels to the left?"

On the places where things work, bosses act like the GP's one. Granted, that doesn't happen on the large majority of places.

Right, huge +1 for Chakra. Chakra is basically tailwind but built on react primitives. It feels lot cleaner, and solves most of the issues mentioned.

It's amazing for quick UI building.

Note however that this API is brought by Styled System [1], which Chakra uses (and exposes), and adds the component library and other niceties on top.

My only regret with Chakra is that it's a tad runtime-heavy, and it's not really adapted to static content. I'd love to see some sort of compiler that digests a React tree into rendered HTML + CSS, with minimal JS just for style interactions (is this what Svelte does?)

[1] https://styled-system.com/