5 ms·

There is only two kinds of people. The ones that don't like Tailwind and the ones that have used it. I know it is conceptually "wrong" and a bunch of well craf

There is only two kinds of people. The ones that don't like Tailwind and the ones that have used it. I know it is conceptually "wrong" and a bunch of well crafted CSS classes would be more elegant. In the end it works, works really well and makes collaboration dead simple. Commonly used groups of classes can either be aliased by @apply or used in a (react) component. I used CSS way before Tailwind was a thing and in hindsight I created a lot of utility classes that resembled a weakly-structured, somewhat incomplete version of Tailwind. It might be a bit verbose, it might be easy to abuse but it works damn well. On top of that there are some design guardrails built in that really help with the consistency of e.g spacing, colors and fonts. Easy to achieve good looking results without risking stuff always looking the same like with Bootstrap or Material. It is a bit like Github Copilot. The only way to "get" it is to try it.

kanonieer 4y ago
> There is only two kinds of people. The ones that don't like Tailwind and the ones that have used it. I know a lot of people who have tried but didn't like Tailwind. I think most people like it on a greenfield project, but that number drops off when they go back to a Tailwind project after some time.
- andiareso 4y ago
  Meh everyone ultimately has a personal preference so it's a bit hyperbole to say that everyone that hasn't used it would like it. Just like everything, it would depend on the project, team, and individual. I personally was against it until I used it.
- hbn 4y ago
  Tailwind projects are the only ones I've hopped into for my first time (i.e. never seen the codebase before) and I can immediately be productive cause I don't have to wrap my head around one specific person's ideas of how classes should work and what all the names mean. Same applies for my own code that I come back to after a year or 2 of not having touched it. It's way easier to parse a template that declares its own styling than a template with references to style classes that may be across multiple CSS/SCSS files and are probably badly named
dimgl 4y ago
Naw, I don't feel this way. I'm not a huge fan of Tailwind. I've used it and I get the appeal, but I think it's the next flavor of the year. Next year we'll have something that supersedes it.
- monkey_monkey 4y ago
  I've been using Tailwind since 2018, so maybe it's the flavour of the decade?
zach_garwood 4y ago
I'm apparently one of the few that tried it and didn't like it. I think it didn't click with me because we're already using Vue components to scope our styles, and honestly we don't use utility classes that much.
nazka 4y ago
No at the end you end up having to learn all their classes, for almost no gain in speed of dev, and then you forget how to do stuff in CSS. For me Tailwind barely make it anything faster but I have to learn all their classes and then I am stuck to have to relearn CSS when their is custom stuff. Maybe for greenfield or MVP sure. But if you are on a big project you have one or more designers and 99% of the time you have things that needs to be customized.
- dawnerd 4y ago
  Re working with designers: that's why the tailwind config exists.
- deergomoo 4y ago
  > then you forget how to do stuff in CSS This is completely nonsensical because Tailwind classes are almost all just shorthand aliases for single CSS properties. You cannot use Tailwind without understanding CSS; it is CSS.
erokar 4y ago
I've used Tailwind on many projects at work for about a year now. I do not like it. Tailwind seemingly affords an easy way of writing inline styles, but it 1) clutters the HTML, 2) leads to repetition and makes people break the DRY principle (yes, you should extract to components, but people don't always do that), 3) uses names that can be similar but are not identical to CSS properties and feels like a bad abstraction. If you use something like Svelte, where you can write local CSS within a component I fail the see the benefit of Tailwind. For me Tailwind is the most ill-conceived frontend tech I've had to use in later years.
- ramesh31 4y ago
  > 1) clutters the HTML, Or, it makes your HTML far more representative of the state of your application, rather than having to open up a CSS file and match to the class name + whatever madness you have going on in your SASS with mixins and conditional style logic. > 2) leads to repetition and makes people break the DRY principle (yes, you should extract to components, but people don't always do that) Blindly following DRY is dogma. Not everything can (or should) be a component. The number one mistake I see with new React developers is "over componentization", where everything is a sub component, and now I'm digging through 5 different files to work on a feature. Use the "rule of three" here. The first time you write something, don't even think about making it a component. The second time you write it, start planning how to generalize. The third time you need it, make it a component. Copy/pasting is OK. Declaratively laying out your UI rather than generating it through configuration is OK. Having no abstractions is better than a bad or even mediocre abstraction.
  - deleted 4y ago
    [deleted]
- tomtheelder 4y ago
  Component local CSS is fine too, as long as you use a theme system to constrain CSS choices. I think in practice they are pretty similar, but I personally way prefer the ergonomics of Tailwind.
- pcthrowaway 4y ago
alx__ 4y ago
Yeah it freaks people out not used to the benefits of utility classes. We're converting our app components to using Tailwind. But there was some initial resistance as the current setup of css-in-js was fine. Fine but not great, and we had ended up with a lot of weird custom css blobs over time. One side benefit is you can just install Tailwind and use it in isolated way. Which is what I did. Converted a couple components to using Tailwind and demoed them. Got positive feedback. Most element only need a handful of classes. And the elements themselves are just normal HTML with a class. Components feel quicker to scan now. Initially skeptical devs have noted the ease at which they can build out a new component. Without having to get bogged down in writing css. Which to me is the real goal of Tailwind, improving DX by abstracting the boring and error prone way of writing CSS for applications.
squidbeak 4y ago
Two kinds of people -- and me, apparently. Because I'm obliged to use it occasionally and it's as if 90s html never went away.
Starlevel001 4y ago
> There is only two kinds of people. The ones that don't like Tailwind and the ones that have used it. I exclusively write server-side templates with minimal to no javascript. I don't like Tailwind because it doesn't work for that.
- heartbreak 4y ago
  Why does it not work for server-side templates?
  - aniforprez 4y ago
    If anything it feels like Tailwind would work great specifically for this use case
easrng 4y ago
I've tried it. It's hard to get used to. I'm very used to writing CSS using the browser devtools and there doesn't seem to be a tailwind equivalent. It's OK when I use a framework but most sites I make don't need one.

kanonieer 4y ago

> There is only two kinds of people. The ones that don't like Tailwind and the ones that have used it. I know a lot of people who have tried but didn't like Tailwind. I think most people like it on a greenfield project, but that number drops off when they go back to a Tailwind project after some time.

andiareso 4y ago
Meh everyone ultimately has a personal preference so it's a bit hyperbole to say that everyone that hasn't used it would like it. Just like everything, it would depend on the project, team, and individual. I personally was against it until I used it.
hbn 4y ago
Tailwind projects are the only ones I've hopped into for my first time (i.e. never seen the codebase before) and I can immediately be productive cause I don't have to wrap my head around one specific person's ideas of how classes should work and what all the names mean. Same applies for my own code that I come back to after a year or 2 of not having touched it. It's way easier to parse a template that declares its own styling than a template with references to style classes that may be across multiple CSS/SCSS files and are probably badly named

dimgl 4y ago

Naw, I don't feel this way. I'm not a huge fan of Tailwind. I've used it and I get the appeal, but I think it's the next flavor of the year. Next year we'll have something that supersedes it.

monkey_monkey 4y ago
I've been using Tailwind since 2018, so maybe it's the flavour of the decade?

zach_garwood 4y ago

I'm apparently one of the few that tried it and didn't like it. I think it didn't click with me because we're already using Vue components to scope our styles, and honestly we don't use utility classes that much.

nazka 4y ago

No at the end you end up having to learn all their classes, for almost no gain in speed of dev, and then you forget how to do stuff in CSS. For me Tailwind barely make it anything faster but I have to learn all their classes and then I am stuck to have to relearn CSS when their is custom stuff. Maybe for greenfield or MVP sure. But if you are on a big project you have one or more designers and 99% of the time you have things that needs to be customized.

dawnerd 4y ago
Re working with designers: that's why the tailwind config exists.
deergomoo 4y ago
> then you forget how to do stuff in CSS This is completely nonsensical because Tailwind classes are almost all just shorthand aliases for single CSS properties. You cannot use Tailwind without understanding CSS; it is CSS.

erokar 4y ago

I've used Tailwind on many projects at work for about a year now. I do not like it. Tailwind seemingly affords an easy way of writing inline styles, but it 1) clutters the HTML, 2) leads to repetition and makes people break the DRY principle (yes, you should extract to components, but people don't always do that), 3) uses names that can be similar but are not identical to CSS properties and feels like a bad abstraction. If you use something like Svelte, where you can write local CSS within a component I fail the see the benefit of Tailwind. For me Tailwind is the most ill-conceived frontend tech I've had to use in later years.

ramesh31 4y ago
> 1) clutters the HTML, Or, it makes your HTML far more representative of the state of your application, rather than having to open up a CSS file and match to the class name + whatever madness you have going on in your SASS with mixins and conditional style logic. > 2) leads to repetition and makes people break the DRY principle (yes, you should extract to components, but people don't always do that) Blindly following DRY is dogma. Not everything can (or should) be a component. The number one mistake I see with new React developers is "over componentization", where everything is a sub component, and now I'm digging through 5 different files to work on a feature. Use the "rule of three" here. The first time you write something, don't even think about making it a component. The second time you write it, start planning how to generalize. The third time you need it, make it a component. Copy/pasting is OK. Declaratively laying out your UI rather than generating it through configuration is OK. Having no abstractions is better than a bad or even mediocre abstraction.
- deleted 4y ago
  [deleted]
tomtheelder 4y ago
Component local CSS is fine too, as long as you use a theme system to constrain CSS choices. I think in practice they are pretty similar, but I personally way prefer the ergonomics of Tailwind.
pcthrowaway 4y ago

alx__ 4y ago

Yeah it freaks people out not used to the benefits of utility classes. We're converting our app components to using Tailwind. But there was some initial resistance as the current setup of css-in-js was fine. Fine but not great, and we had ended up with a lot of weird custom css blobs over time. One side benefit is you can just install Tailwind and use it in isolated way. Which is what I did. Converted a couple components to using Tailwind and demoed them. Got positive feedback. Most element only need a handful of classes. And the elements themselves are just normal HTML with a class. Components feel quicker to scan now. Initially skeptical devs have noted the ease at which they can build out a new component. Without having to get bogged down in writing css. Which to me is the real goal of Tailwind, improving DX by abstracting the boring and error prone way of writing CSS for applications.

squidbeak 4y ago

Two kinds of people -- and me, apparently. Because I'm obliged to use it occasionally and it's as if 90s html never went away.

Starlevel001 4y ago

> There is only two kinds of people. The ones that don't like Tailwind and the ones that have used it. I exclusively write server-side templates with minimal to no javascript. I don't like Tailwind because it doesn't work for that.

heartbreak 4y ago
Why does it not work for server-side templates?
- aniforprez 4y ago
  If anything it feels like Tailwind would work great specifically for this use case

easrng 4y ago

I've tried it. It's hard to get used to. I'm very used to writing CSS using the browser devtools and there doesn't seem to be a tailwind equivalent. It's OK when I use a framework but most sites I make don't need one.