[PUSH_AX]

My personal opinion is that styled components creates an unnecessary and fuzzy extra abstraction on top of components.

[dbbk]

Not really? It's just an element with some attached styles.

styled.div`color:red` is a red-colored div. Hardly fuzzy.

[onion2k]

The equivalent styled component of the default Tailwind button of "bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded" is "styled.div`background-color:#8888ff;color:white;font-weight:bold;padding-y:2px;padding-x:4px;border-radius:4px;&hover{background-color:#aaaaff}`".

Obviously you wouldn't actually write it like that because it's inline in your code so you can format it better, but the Tailwind version is less verbose and easier to read if you did.

[dbbk]

"Less verbose" I guess by a few characters... at the expense that you're not writing real CSS rules. So you're having to translate every rule into whatever Tailwind's syntax is for the same thing.

[9dev]

It's not the same thing, though. Tailwind applies rules from your design system, not plain CSS values. Assuming you're updating your corporate design to use border-radius 2 vs 4 everywhere, with Tailwind it's a matter of reconfiguring your design system configuration; with styled components (and other approaches) you're going on a string hunt.

[onion2k]

Styled components are code. You could easily have a value from a central config rather than a string, like ${company.padding.px}.

[9dev]

Sure. But now you need to maintain both places, you must think of units, and all the edge cases the Tailwind code base already handles.

[bernawil]

hey no need to make this an hypothetical! styled components come with ThemeProvider that does just that.

  const StyledButton = styled.button`
    background-color: ${props => props.theme.primaryColor};
  `