4 ms·

I love tailwind, used in 3 projects in the past 4 years, it’s intuitive, well documented, simple. I don’t miss the days of emotion and styled components where I

I love tailwind, used in 3 projects in the past 4 years, it’s intuitive, well documented, simple. I don’t miss the days of emotion and styled components where I would have to think of a name for every styled div in the project, with tailwind a container is just a div and a few classes nothing else. Less bike shedding discussion, less brain cycles spent naming things, less time wasted in reviews.

notjoemama 2y ago
> a few classes You must be working with very good product owners then. The ones I've worked with love to specify the hell out of every possible detail. Like a web form is their personal HGTV renovation. I tried tailwind once and the classes ended up being an order of magnitude more than the markup. It got hard to read, quickly.
- lowercased 2y ago
  you can use @apply to merge the various utility classes together in to something resembling a name, like .btn-primary { @apply py-2 px-5 bg-violet-500 text-white font-semibold rounded-full shadow-md hover:bg-violet-700 focus:outline-none focus:ring focus:ring-violet-400 focus:ring-opacity-75; } But their v3 docs seem to be very against this. "Whatever you do, don’t use @apply just to make things look “cleaner”. Yes, HTML templates littered with Tailwind classes are kind of ugly. Making changes in a project that has tons of custom CSS is worse." Reasons: * You have to think up class names all the time — nothing will slow you down or drain your energy like coming up with a class name for something that doesn’t deserve to be named. * You have to jump between multiple files to make changes — which is a way bigger workflow killer than you’d think before co-locating everything together. * Changing styles is scarier — CSS is global, are you sure you can change the min-width value in that class without breaking something in another part of the site? Yet... my experience using projects that use tailwind is that every button everywhere is styled the same way, but it's repeated in multiple areas. The 'kinda ugly' part, but also... it's repeated in multiple places. Trying to change the universal focus behaviour of buttons in a project like this is hard, because... I can't search focus:outline-none without finding everything that has 'focus:outline-none' on it. I can't just search/replace, because it'll impact other stuff. So I end up spending way too much time trawling through way too many scattered specific styles all over a codebase, vs having a defined 'btn' style someplace. "well, that's just the project's fault"... possibly, but it seems to be the promoted/preferred/evangelized way of using tailwind, judging by the projects I've had to get involved with the past few years. IME, this approach may have good short term benefits, but poorer longer term maintenance, doubly so when the original people are no longer involved in the project, and outsiders have to come in to deal with it.
  - deleted 2y ago
    [deleted]
  - msoad 2y ago
    I agree with Tailwind's stance on this. You really don't need @apply if you're breaking things down to smaller components. I often see people have things like <ul><li className="long_list_of_classes">text1</li><li className="long_list_of_classes">text2</li>...</ul>. This is where I think we need a linter to warn against things like that. Make those <li>'s a component!
    - omnimus 2y ago
      I have bern heavy Tailwind user from before v1. It actually doesnt matter where you make the class grouping. You can make it in your templating language or you can make it in @apply. I prefer @apply because the same grouping can be reused if done correctly. @apply is great. The reason they are discouraging @appply is because its hard feature to implement and many people dont understand how it works so they get to problems and create issues. It bothers Authors so much they have always been considering taking @apply out but i think they know big chunk of the userbase would leave to different similar project.
    - tuzemec 2y ago
      Wait, what? You want to make every li/dt/etc. component? That's insane.
    - xigoi 2y ago
      Why not just do <ul class="my-class">…</ul> and then apply the styles to ul.my-class > li ?
  - davedx 2y ago
    For buttons, I think the 'blessed' way to do it is to use (react) components and have the tailwind classes encapsulated there. It makes sense; you have a layer of abstraction where the implementation of your theme is in the "lower level building blocks" of your components. (Call it a component library if you want) I generally only use @apply when there are some heavier external interactive libraries that are hard to style. Like for example if you're embedding markup in your application, and you need to apply a set of styles to the markup it generates, and you can't do that directly in react because you don't control that part.
- Aeolun 2y ago
  I generally use tailwind in combination with daisyui, and I don’t think about styling a lot any more beyond choosing the proper theme.
dbbk 2y ago
> I don’t miss the days of emotion and styled components where I would have to think of a name for every styled div in the project I see people mention this issue fairly frequently, and it puzzles me a little. I have never once spent probably more than 1 second thinking about what to name something. Is it actually a blocker for some people? Are you really paralysed by this?
- agos 2y ago
  especially since with any decent CSS solution (any css in js, or CSS modules) you can reuse names
  - dbbk 2y ago
    Like really, I use Styled Components, just call it a Wrapper or InnerWrapper or Row or whatever and move on
- gausswho 2y ago
  There was a time when BEM ruled (and scarred) the world. But names aren't a problem if you abandon the C in CSS and scope all styles to component.
  - werdnapk 2y ago
    I'd say BEM was a passing fad, but didn't rule the world. I also think tailwind will suffer the same fate, but we'll see how it plays out.
  - Kerrick 2y ago
    What I don't understand is why BEM is scarring. If you're talking about the reason or timing something looks different, you must have named it in that conversation. Just use that name. "When the menu is wide, the items' icons and text should be visible. When it's skinny, only the icons should be visible. This button toggles between them." .menu {} .menu--skinny {} .menu--wide {} .menu__icon {} .menu__text {}
fintechie 2y ago
Gave it a go for several projects, but didn't like it... for big projects it gets messy, fast. It also feels like it has become the new bootstrap. I'm very happy with my current CSS-in-JS workflow. Crafting good old css with LLM help. You just show the LLM a pic, ask for the components.... boom, done (with proper naming, etc)
_heimdall 2y ago
This is actually one of the main reasons I avoid react when I have the option. Styling in react is terrible, I'll use tailwind with it but only as the least bad option. If I am using a frontend framework and a build step, svelte and astro are nice depending on the use case. I can style with plain old CSS and rarely have to reach for class names, if you keep components small you can get away with element selectors and let the framework scope styles at build time.

notjoemama 2y ago

> a few classes You must be working with very good product owners then. The ones I've worked with love to specify the hell out of every possible detail. Like a web form is their personal HGTV renovation. I tried tailwind once and the classes ended up being an order of magnitude more than the markup. It got hard to read, quickly.

lowercased 2y ago
you can use @apply to merge the various utility classes together in to something resembling a name, like .btn-primary { @apply py-2 px-5 bg-violet-500 text-white font-semibold rounded-full shadow-md hover:bg-violet-700 focus:outline-none focus:ring focus:ring-violet-400 focus:ring-opacity-75; } But their v3 docs seem to be very against this. "Whatever you do, don’t use @apply just to make things look “cleaner”. Yes, HTML templates littered with Tailwind classes are kind of ugly. Making changes in a project that has tons of custom CSS is worse." Reasons: * You have to think up class names all the time — nothing will slow you down or drain your energy like coming up with a class name for something that doesn’t deserve to be named. * You have to jump between multiple files to make changes — which is a way bigger workflow killer than you’d think before co-locating everything together. * Changing styles is scarier — CSS is global, are you sure you can change the min-width value in that class without breaking something in another part of the site? Yet... my experience using projects that use tailwind is that every button everywhere is styled the same way, but it's repeated in multiple areas. The 'kinda ugly' part, but also... it's repeated in multiple places. Trying to change the universal focus behaviour of buttons in a project like this is hard, because... I can't search focus:outline-none without finding everything that has 'focus:outline-none' on it. I can't just search/replace, because it'll impact other stuff. So I end up spending way too much time trawling through way too many scattered specific styles all over a codebase, vs having a defined 'btn' style someplace. "well, that's just the project's fault"... possibly, but it seems to be the promoted/preferred/evangelized way of using tailwind, judging by the projects I've had to get involved with the past few years. IME, this approach may have good short term benefits, but poorer longer term maintenance, doubly so when the original people are no longer involved in the project, and outsiders have to come in to deal with it.
- deleted 2y ago
  [deleted]
- msoad 2y ago
  I agree with Tailwind's stance on this. You really don't need @apply if you're breaking things down to smaller components. I often see people have things like <ul><li className="long_list_of_classes">text1</li><li className="long_list_of_classes">text2</li>...</ul>. This is where I think we need a linter to warn against things like that. Make those <li>'s a component!
  - omnimus 2y ago
    I have bern heavy Tailwind user from before v1. It actually doesnt matter where you make the class grouping. You can make it in your templating language or you can make it in @apply. I prefer @apply because the same grouping can be reused if done correctly. @apply is great. The reason they are discouraging @appply is because its hard feature to implement and many people dont understand how it works so they get to problems and create issues. It bothers Authors so much they have always been considering taking @apply out but i think they know big chunk of the userbase would leave to different similar project.
  - tuzemec 2y ago
    Wait, what? You want to make every li/dt/etc. component? That's insane.
  - xigoi 2y ago
    Why not just do <ul class="my-class">…</ul> and then apply the styles to ul.my-class > li ?
- davedx 2y ago
  For buttons, I think the 'blessed' way to do it is to use (react) components and have the tailwind classes encapsulated there. It makes sense; you have a layer of abstraction where the implementation of your theme is in the "lower level building blocks" of your components. (Call it a component library if you want) I generally only use @apply when there are some heavier external interactive libraries that are hard to style. Like for example if you're embedding markup in your application, and you need to apply a set of styles to the markup it generates, and you can't do that directly in react because you don't control that part.
Aeolun 2y ago
I generally use tailwind in combination with daisyui, and I don’t think about styling a lot any more beyond choosing the proper theme.

dbbk 2y ago

> I don’t miss the days of emotion and styled components where I would have to think of a name for every styled div in the project I see people mention this issue fairly frequently, and it puzzles me a little. I have never once spent probably more than 1 second thinking about what to name something. Is it actually a blocker for some people? Are you really paralysed by this?

agos 2y ago
especially since with any decent CSS solution (any css in js, or CSS modules) you can reuse names
- dbbk 2y ago
  Like really, I use Styled Components, just call it a Wrapper or InnerWrapper or Row or whatever and move on
gausswho 2y ago
There was a time when BEM ruled (and scarred) the world. But names aren't a problem if you abandon the C in CSS and scope all styles to component.
- werdnapk 2y ago
  I'd say BEM was a passing fad, but didn't rule the world. I also think tailwind will suffer the same fate, but we'll see how it plays out.
- Kerrick 2y ago
  What I don't understand is why BEM is scarring. If you're talking about the reason or timing something looks different, you must have named it in that conversation. Just use that name. "When the menu is wide, the items' icons and text should be visible. When it's skinny, only the icons should be visible. This button toggles between them." .menu {} .menu--skinny {} .menu--wide {} .menu__icon {} .menu__text {}

fintechie 2y ago

Gave it a go for several projects, but didn't like it... for big projects it gets messy, fast. It also feels like it has become the new bootstrap. I'm very happy with my current CSS-in-JS workflow. Crafting good old css with LLM help. You just show the LLM a pic, ask for the components.... boom, done (with proper naming, etc)

_heimdall 2y ago

This is actually one of the main reasons I avoid react when I have the option. Styling in react is terrible, I'll use tailwind with it but only as the least bad option. If I am using a frontend framework and a build step, svelte and astro are nice depending on the use case. I can style with plain old CSS and rarely have to reach for class names, if you keep components small you can get away with element selectors and let the framework scope styles at build time.