5 ms·

I do write like that. Heck, even a mix of both: <SidebarItem marginRight={2} />, using Chakra-UI [1] (not too dissimilar to Tailwind in spirit). Even the best

I do write like that. Heck, even a mix of both: <SidebarItem marginRight={2} />, using Chakra-UI [1] (not too dissimilar to Tailwind in spirit). Even the best design system needs local overrides to satisfy a product owner's incomprehensible requests, like "can we push that button a few pixels to the left?". [1] https://chakra-ui.com/ https://chakra-ui.com/

adamscybot 4y ago
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.
- franky47 4y ago
  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/ https://styled-system.com/
_nhh 4y ago
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.
- sieabahlpark 4y ago
  [dead]
- wry_discontent 4y ago
  > The whole point of a design system is not to have local overrides. Are you unfamiliar with having-a-boss?
  - marcosdumay 4y ago
    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.
- franky47 4y ago
  `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.

adamscybot 4y ago

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.

franky47 4y ago
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/ https://styled-system.com/

_nhh 4y ago

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.

sieabahlpark 4y ago
[dead]
wry_discontent 4y ago
> The whole point of a design system is not to have local overrides. Are you unfamiliar with having-a-boss?
- marcosdumay 4y ago
  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.
franky47 4y ago
`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.