4 ms·

I'm ambivalent about Tailwind, but I've used it a lot. I will say the hypothetical advantages are mostly the following: 1. It's a step function over CSS units.

I'm ambivalent about Tailwind, but I've used it a lot. I will say the hypothetical advantages are mostly the following: 1. It's a step function over CSS units. This is the biggest strength, just standardizing that your design uses padding of 2, 4, 8px, but not 1px, 3px, or 1.23123em :). It provides more steps than you need, but still it's good that the core of Tailwind is a design system with defined unit and color variables. 2. Some of the utility classes are very helpful. Even as someone who likes writing CSS, it's nice to not need to give something a custom classname just because I want to put margin-top on it. class="mt-4", done. I think the problem is Tailwind goes too far and tries to replace EVERYTHING with a stack of utility classes. This works okay in extremely componentized web apps. It's a nightmare if your UI isn't highly componentized. I've seen projects where you make a button by copy pasting this ~80 character string of tailwind classes all over the place, and then changing the color names if you need to. Good luck fixing that when the designer decides that we don't want any buttons to have rounded corners anymore. Personally I think the best parts of Tailwind are captured in Pollen[1], but I do wish it came with a subset of utility classes for colors, font sizes, margin, padding, and text alignment. I think the hard part is defining which subset is the right subset... I doubt you could find strong agreement from a large majority of developers on that. 1. https://www.pollen.style https://www.pollen.style

JasonCannon 5y ago
>This works okay in extremely componentized web apps. It's a nightmare if your UI isn't highly componentized. I've seen projects where you make a button by copy pasting this ~80 character string of tailwind classes all over the place, and then changing the color names if you need to. Good luck fixing that when the designer decides that we don't want any buttons to have rounded corners anymore. That app is done wrong. If you are using the same styles to represent a button you should use postcss and do .myButtonClass { @extend: (80 tailwind classes here) }
- markdown 5y ago
  So now we have to add this new postcss thing. Modern web dev is bandaids all the way down.
  - JasonCannon 5y ago
    postcss is literally how tailwind works. If you are using tailwind, you already have postcss. I get it, you don't like modern frameworks. Don't use it.
- ggregoire 5y ago
  Or make a Button component in your framework of choice. function Button = ({ children }) => <button className={80 tailwind classes here}>{children}</button> <Button>Create</Button> <Button>Edit</Button> // Same style <Button>Delete</Button> // Same style
  - JasonCannon 5y ago
    Even then, I would still recommend using the postcss extend tag. Much easier to read that way. Also, postcss doesn't require any frameworks, you can still do everything with plain ol' html and javascript.
  - montroser 5y ago
    No, we don't want all of the buttons to look identical. Some are big and some are small; some are bold and primary and some are muted and secondary; some have icons; some have shadows; some are disabled, etc, etc. It's easy to make them identical. The challenge is to be as flexible as necessary in a mature application, while minimizing verbosity and complexity. In my experience Tailwind hurts more than it helps here. It forces you to use your component system to abstract things which otherwise wouldn't warrant the extra level of indirection.
    - reactor 5y ago
      How would you have done it without TailWind? You'd still have to create classes for each of them in plain css anyway, except it would probably be in a different .css file. The inherent complexity pertaining to your app is not taken away, it just moved the places.
      - montroser 5y ago
        My point is that plain CSS is already good at this. So then you don't need to make more components with their own interface to learn. <button class="btn large shadow">Edit</button> .btn { ...default button styles } .btn.large { font-size: larger; } .btn.shadow { box-shadow: 0 0 8px #0004; }
- pier25 5y ago
  Doesn't that negate most of the benefits of using Tailwind in the first place?
  - JasonCannon 5y ago
    Not at all. You design and iterate on the button using the individual classes, then you swap them out for a concise class once you are done. It's how tailwind is designed to be used. https://tailwindcss.com/docs/reusing-styles https://tailwindcss.com/docs/reusing-styles Although I realize in looking this up in the documentation to show you, it's actually @apply and not @extend you are supposed to use.
    - Toine 5y ago
      Using @apply is the ultimate last resort though.
- jeremyjh 5y ago
  Yes, there is a right way to do it. But in the code I've seen in the wild, people are often not doing it right and those 80 char strings of utility classes are on the low side compared to some of what I've seen. I'm skeptical of Tailwind not for its own sake but because a lot of (most?) shops do not have the discipline to use it effectively. And what you are arguing here is basically a no true Scotsman defense.
  - rattray 5y ago
    I wonder if there's an ESLint rule out there to limit how many tailwind classes you throw onto one thing...
sibit 5y ago
I agree. I used Tailwind for roughly six months on a few projects before I noticed that I was only using the basic utility classes. I didn't like all the screen sizes and state "bloat" classes so I decided to take the best parts (margins, padding, background, font, text alignment) and create a simple CSS framework. For anyone interested, you can find it at: https://brixi.dev/ https://brixi.dev/

JasonCannon 5y ago

>This works okay in extremely componentized web apps. It's a nightmare if your UI isn't highly componentized. I've seen projects where you make a button by copy pasting this ~80 character string of tailwind classes all over the place, and then changing the color names if you need to. Good luck fixing that when the designer decides that we don't want any buttons to have rounded corners anymore. That app is done wrong. If you are using the same styles to represent a button you should use postcss and do .myButtonClass { @extend: (80 tailwind classes here) }

markdown 5y ago
So now we have to add this new postcss thing. Modern web dev is bandaids all the way down.
- JasonCannon 5y ago
  postcss is literally how tailwind works. If you are using tailwind, you already have postcss. I get it, you don't like modern frameworks. Don't use it.
ggregoire 5y ago
Or make a Button component in your framework of choice. function Button = ({ children }) => <button className={80 tailwind classes here}>{children}</button> <Button>Create</Button> <Button>Edit</Button> // Same style <Button>Delete</Button> // Same style
- JasonCannon 5y ago
  Even then, I would still recommend using the postcss extend tag. Much easier to read that way. Also, postcss doesn't require any frameworks, you can still do everything with plain ol' html and javascript.
- montroser 5y ago
  No, we don't want all of the buttons to look identical. Some are big and some are small; some are bold and primary and some are muted and secondary; some have icons; some have shadows; some are disabled, etc, etc. It's easy to make them identical. The challenge is to be as flexible as necessary in a mature application, while minimizing verbosity and complexity. In my experience Tailwind hurts more than it helps here. It forces you to use your component system to abstract things which otherwise wouldn't warrant the extra level of indirection.
  - reactor 5y ago
    How would you have done it without TailWind? You'd still have to create classes for each of them in plain css anyway, except it would probably be in a different .css file. The inherent complexity pertaining to your app is not taken away, it just moved the places.
    - montroser 5y ago
      My point is that plain CSS is already good at this. So then you don't need to make more components with their own interface to learn. <button class="btn large shadow">Edit</button> .btn { ...default button styles } .btn.large { font-size: larger; } .btn.shadow { box-shadow: 0 0 8px #0004; }
pier25 5y ago
Doesn't that negate most of the benefits of using Tailwind in the first place?
- JasonCannon 5y ago
  Not at all. You design and iterate on the button using the individual classes, then you swap them out for a concise class once you are done. It's how tailwind is designed to be used. https://tailwindcss.com/docs/reusing-styles https://tailwindcss.com/docs/reusing-styles Although I realize in looking this up in the documentation to show you, it's actually @apply and not @extend you are supposed to use.
  - Toine 5y ago
    Using @apply is the ultimate last resort though.
jeremyjh 5y ago
Yes, there is a right way to do it. But in the code I've seen in the wild, people are often not doing it right and those 80 char strings of utility classes are on the low side compared to some of what I've seen. I'm skeptical of Tailwind not for its own sake but because a lot of (most?) shops do not have the discipline to use it effectively. And what you are arguing here is basically a no true Scotsman defense.
- rattray 5y ago
  I wonder if there's an ESLint rule out there to limit how many tailwind classes you throw onto one thing...

sibit 5y ago

I agree. I used Tailwind for roughly six months on a few projects before I noticed that I was only using the basic utility classes. I didn't like all the screen sizes and state "bloat" classes so I decided to take the best parts (margins, padding, background, font, text alignment) and create a simple CSS framework. For anyone interested, you can find it at: https://brixi.dev/ https://brixi.dev/