4 ms·

I feel like these are two very, very different tools. Pico (or something similar) is great for a Just-Works framework where things look simply and nice. For a l

I feel like these are two very, very different tools. Pico (or something similar) is great for a Just-Works framework where things look simply and nice. For a lot of things, this is good enough. But Tailwind is for building... anything. It's better to think of it as inline styles with syntactical sugar. Yes, this has historically been something to avoid. But as components become more common, it moves the DRY to the HTML level (rather than CSS classes). It's not for everyone or everything, but I've loved it. There's a joke that the hardest part of CS is naming things, and this removes having to map classes and IDs across two different files.

danielvaughn 2y ago
That's exactly how I feel. I didn't realize how much of a productivity-stopper class naming was until I stopped doing it. It's amazing how much faster you move.
- ergocoder 2y ago
  Naming is easy. It is container, then container-container, then container-container-container
abhgh 2y ago
I entirely agree. They get compared a lot but to me they seem to solving different problems. Pico if you want something asap, and you are ok with sticking with it's opinionated styles. Tailwind if you want control - now, or if not now then later, i.e., you see your application evolving. Personally for me, the opinionated pico styles don't work because I'm usually building high density interfaces and pico has stuff that I'd consider good for marketing kind of sites, e.g., buttons with large text (I think you can override/add styles but if it comes to that you should reconsider this choice anyway). Another advantage for tailwind is that I can use to style components from other frameworks to my liking, e.g., skeletonUI or bits-UI. A common complaint with tailwind is the long class names. While true I think it's unavoidable due to the flexibility it provides. But that's not why it doesn't bother me: the names make sense (like you say) and they're composable, i.e., you can put together or parse these class names piecewise. PS: I should add that this article is fair in the sense that it doesn't prescribe over another, just shows which is best for what.
- wredcoll 2y ago
  Can someone explain the advantage of class="color-red" over style="color:red", that's the part that always confuses me.
  - stocknoob 2y ago
    It’s an artfully constrained design system that reduces mental burden. The main benefit is what you aren’t doing: jumping between css files and html, naming class’s, trying to debug layers of cascading, wondering what other unrelated components will be impacted by a css rule change… Colors aren’t a great example because those should be set as css variables (dark mode right?). Think about padding: how many layers of margin/padding on parent wrappers is making things look strange? The best argument is just to try it though.
    - gedy 2y ago
      > It’s an artfully constrained design system Have to disagree it's a design system - it's basically a theme. Consistent colors, fonts, borders, spacing is handy for sure - but Tailwind is not a great option if you expect to drop it in and have building block components, etc without a lot of work.
    - spiffytech 2y ago
      And even for colors, the benefit is the consistent color scale. You've only got 10 shades of red, which are all visually distinct. You won't find slightly different RGB values all over your code base each time someone wanted red.
    - andrei_says_ 2y ago
      The drawback is that you end up with an incomprehensible soup of classes on too many html elements, often redefining and redefining rules. If you work in a highly componentized scenario that’s probably convenient. You don’t have to name things as you would if you were to keep a separate css ruleset and then tie it to the html elements via naming. Very noisy compared to a disciplined, structured css though. But who has time for that.
PUSH_AX 2y ago
I think people should still think of TW as classes, because they are, and it doesn't need to be more complex than that. Thinking of TW as inline styles is harmful imo, the specificity works differently and there are a number of things that TW offers that isn't possible inline. Plus inline just carries a stigma which helps people dunk unfairly on TW.
- wvenable 2y ago
  The selling point of TW is that it is, effectively, styles. That's what distinguishes it from what I could call just normal CSS. It has value over inline styles -- otherwise it wouldn't exist -- but it's still the same principle.
CreepGin 2y ago
I maintain OneJS which provides tailwind support for Unity (the game engine). Whenever I need to show people some code examples in Discord, I always use TW instead of, say, raw css, emotion, etc. This is because TW makes it possible to have everything in one file. And the utility classes are so short, it just make more sense to use them to save screen estate.

danielvaughn 2y ago

That's exactly how I feel. I didn't realize how much of a productivity-stopper class naming was until I stopped doing it. It's amazing how much faster you move.

ergocoder 2y ago
Naming is easy. It is container, then container-container, then container-container-container

abhgh 2y ago

I entirely agree. They get compared a lot but to me they seem to solving different problems. Pico if you want something asap, and you are ok with sticking with it's opinionated styles. Tailwind if you want control - now, or if not now then later, i.e., you see your application evolving. Personally for me, the opinionated pico styles don't work because I'm usually building high density interfaces and pico has stuff that I'd consider good for marketing kind of sites, e.g., buttons with large text (I think you can override/add styles but if it comes to that you should reconsider this choice anyway). Another advantage for tailwind is that I can use to style components from other frameworks to my liking, e.g., skeletonUI or bits-UI. A common complaint with tailwind is the long class names. While true I think it's unavoidable due to the flexibility it provides. But that's not why it doesn't bother me: the names make sense (like you say) and they're composable, i.e., you can put together or parse these class names piecewise. PS: I should add that this article is fair in the sense that it doesn't prescribe over another, just shows which is best for what.

wredcoll 2y ago
Can someone explain the advantage of class="color-red" over style="color:red", that's the part that always confuses me.
- stocknoob 2y ago
  It’s an artfully constrained design system that reduces mental burden. The main benefit is what you aren’t doing: jumping between css files and html, naming class’s, trying to debug layers of cascading, wondering what other unrelated components will be impacted by a css rule change… Colors aren’t a great example because those should be set as css variables (dark mode right?). Think about padding: how many layers of margin/padding on parent wrappers is making things look strange? The best argument is just to try it though.
  - gedy 2y ago
    > It’s an artfully constrained design system Have to disagree it's a design system - it's basically a theme. Consistent colors, fonts, borders, spacing is handy for sure - but Tailwind is not a great option if you expect to drop it in and have building block components, etc without a lot of work.
  - spiffytech 2y ago
    And even for colors, the benefit is the consistent color scale. You've only got 10 shades of red, which are all visually distinct. You won't find slightly different RGB values all over your code base each time someone wanted red.
  - andrei_says_ 2y ago
    The drawback is that you end up with an incomprehensible soup of classes on too many html elements, often redefining and redefining rules. If you work in a highly componentized scenario that’s probably convenient. You don’t have to name things as you would if you were to keep a separate css ruleset and then tie it to the html elements via naming. Very noisy compared to a disciplined, structured css though. But who has time for that.

PUSH_AX 2y ago

I think people should still think of TW as classes, because they are, and it doesn't need to be more complex than that. Thinking of TW as inline styles is harmful imo, the specificity works differently and there are a number of things that TW offers that isn't possible inline. Plus inline just carries a stigma which helps people dunk unfairly on TW.

wvenable 2y ago
The selling point of TW is that it is, effectively, styles. That's what distinguishes it from what I could call just normal CSS. It has value over inline styles -- otherwise it wouldn't exist -- but it's still the same principle.

CreepGin 2y ago

I maintain OneJS which provides tailwind support for Unity (the game engine). Whenever I need to show people some code examples in Discord, I always use TW instead of, say, raw css, emotion, etc. This is because TW makes it possible to have everything in one file. And the utility classes are so short, it just make more sense to use them to save screen estate.