3 ms·

Why not Styled Components? I've been using them for years now and I'm extremely productive. Tailwind on the other hand looks like a hellish nightmare, horizont

by dbbk 3y ago

Why not Styled Components? I've been using them for years now and I'm extremely productive. Tailwind on the other hand looks like a hellish nightmare, horizontal reading, proprietary syntax, no selector targeting of other components.

PUSH_AX 3y ago
My personal opinion is that styled components creates an unnecessary and fuzzy extra abstraction on top of components.
- dbbk 3y ago
  Not really? It's just an element with some attached styles. styled.div`color:red` is a red-colored div. Hardly fuzzy.
  - onion2k 3y ago
    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 3y ago
      "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 3y ago
        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 3y ago
        Styled components are code. You could easily have a value from a central config rather than a string, like ${company.padding.px}.
        9dev 3y ago
        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.
        dbbk 3y ago
        What you're talking about is really a theming design system, which yes Tailwind does have out of the box and Styled Components does not. But the companies I work in always have their own in-house design system, which means you have to maintain it yourself no matter what.
        bernawil 3y ago
        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}; `
9dev 3y ago
If horizontal reading bothers you so much it resembles a hellish nightmare (Dante would like to have a word with you), nobody stops you from going like this: <button class=" flex bg-blue-400 p-4 ">Submit</button> And you actually can target other components. There are lots of sibling selectors, including named groups: <label class="group/field"> <input type="text" /> <span class="order-1 text-black group-focus-within/field:text-blue-500">Name</span> </label>
- ricardobeat 3y ago
  > removes the thinking around CSS, naming, preprocessors etc
  - 9dev 3y ago
    It's a fairly limited set of rules that are mostly consistent, extensively documented, and easy to remember. But yeah, a little bit of effort is required when dealing with a styling language with over 300 properties. Without Tailwind, you'll have to come up with a unique, declarative, distinctive name for each and every element you're piling styles upon. At first it's a button, then there's buttons that should look like links, and then clickable icons. They share some properties, but not others, and before you know it, you've invented an ad-hoc description language in CSS classes that nobody except you can understand right away. With Tailwind, you may have sequences of tokens that seem confusing at first, but at least it's the same -- few -- sequences in every single Tailwind project under the sun. No side effects, no blurry concerns, no more specificity issues. If you don't appreciate that, you haven't seen large enough projects yet.
    - dbbk 3y ago
      > Without Tailwind, you'll have to come up with a unique, declarative, distinctive name for each and every element you're piling styles upon I can honestly say I've never spent more than 5 seconds thinking about what to name a styled component, do you really get decision paralysis with this?
onion2k 3y ago
Tailwind on the other hand looks like a hellish nightmare, horizontal reading, proprietary syntax, no selector targeting of other components. Is "horizontal reading" worse than reading two files? What if the other file is actually 30 files compiled with SASS? What if they're 30 files, compiled with SASS, and written by a bunch of devs who don't know CSS well, didn't use BEM or anything to name things well, and didn't organise them at all? Tailwind isn't better than great CSS, but it's significantly better than bad CSS.
- dbbk 3y ago
  > Is "horizontal reading" worse than reading two files? I see this complaint a lot but I don't really get it. You can have a styled component in the same file or a separate file. In VSCode, you just command click on the component and you go straight to the style definition. Not an issue. > What if the other file is actually 30 files compiled with SASS? I only work in Styled Components-exclusive codebases so can't comment > What if they're 30 files, compiled with SASS, and written by a bunch of devs who don't know CSS well, didn't use BEM or anything to name things well, and didn't organise them at all? You got bigger problems
  - onion2k 3y ago
    You got bigger problems Yes, you have. And this is really, really common in large scale web apps, especially where they've been mostly written by people who are 'backend' or 'full stack' developers. Tailwind didn't just spring forth as a tool to screw with web developers. It was developed as a solution to a problem. That problem being bad, unmanaged CSS at scale. If you don't have that problem obviously Tailwind isn't going to look useful to you.
- lawn 3y ago
  > Is "horizontal reading" worse than reading two files? Yes, very. I'm amazed that this is even in question.

by dbbk 3y ago

PUSH_AX 3y ago

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

dbbk 3y ago
Not really? It's just an element with some attached styles. styled.div`color:red` is a red-colored div. Hardly fuzzy.
- onion2k 3y ago
  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 3y ago
    "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 3y ago
      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 3y ago
        Styled components are code. You could easily have a value from a central config rather than a string, like ${company.padding.px}.
        9dev 3y ago
        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.
        dbbk 3y ago
        What you're talking about is really a theming design system, which yes Tailwind does have out of the box and Styled Components does not. But the companies I work in always have their own in-house design system, which means you have to maintain it yourself no matter what.
        bernawil 3y ago
        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}; `

9dev 3y ago

If horizontal reading bothers you so much it resembles a hellish nightmare (Dante would like to have a word with you), nobody stops you from going like this: <button class=" flex bg-blue-400 p-4 ">Submit</button> And you actually can target other components. There are lots of sibling selectors, including named groups: <label class="group/field"> <input type="text" /> <span class="order-1 text-black group-focus-within/field:text-blue-500">Name</span> </label>

ricardobeat 3y ago
> removes the thinking around CSS, naming, preprocessors etc
- 9dev 3y ago
  It's a fairly limited set of rules that are mostly consistent, extensively documented, and easy to remember. But yeah, a little bit of effort is required when dealing with a styling language with over 300 properties. Without Tailwind, you'll have to come up with a unique, declarative, distinctive name for each and every element you're piling styles upon. At first it's a button, then there's buttons that should look like links, and then clickable icons. They share some properties, but not others, and before you know it, you've invented an ad-hoc description language in CSS classes that nobody except you can understand right away. With Tailwind, you may have sequences of tokens that seem confusing at first, but at least it's the same -- few -- sequences in every single Tailwind project under the sun. No side effects, no blurry concerns, no more specificity issues. If you don't appreciate that, you haven't seen large enough projects yet.
  - dbbk 3y ago
    > Without Tailwind, you'll have to come up with a unique, declarative, distinctive name for each and every element you're piling styles upon I can honestly say I've never spent more than 5 seconds thinking about what to name a styled component, do you really get decision paralysis with this?

onion2k 3y ago

Tailwind on the other hand looks like a hellish nightmare, horizontal reading, proprietary syntax, no selector targeting of other components. Is "horizontal reading" worse than reading two files? What if the other file is actually 30 files compiled with SASS? What if they're 30 files, compiled with SASS, and written by a bunch of devs who don't know CSS well, didn't use BEM or anything to name things well, and didn't organise them at all? Tailwind isn't better than great CSS, but it's significantly better than bad CSS.

dbbk 3y ago
> Is "horizontal reading" worse than reading two files? I see this complaint a lot but I don't really get it. You can have a styled component in the same file or a separate file. In VSCode, you just command click on the component and you go straight to the style definition. Not an issue. > What if the other file is actually 30 files compiled with SASS? I only work in Styled Components-exclusive codebases so can't comment > What if they're 30 files, compiled with SASS, and written by a bunch of devs who don't know CSS well, didn't use BEM or anything to name things well, and didn't organise them at all? You got bigger problems
- onion2k 3y ago
  You got bigger problems Yes, you have. And this is really, really common in large scale web apps, especially where they've been mostly written by people who are 'backend' or 'full stack' developers. Tailwind didn't just spring forth as a tool to screw with web developers. It was developed as a solution to a problem. That problem being bad, unmanaged CSS at scale. If you don't have that problem obviously Tailwind isn't going to look useful to you.
lawn 3y ago
> Is "horizontal reading" worse than reading two files? Yes, very. I'm amazed that this is even in question.