- Ability to use pseudo-selectors, etc. in "inline-styles"
- Limited set of predefined values to use for padding, margin, and such that make it a bit easier to stay consistent
- Some helpful utilities like good looking shadows and animations
Sure, I could achieve all of that in a different way. Nothing about it is ground-breaking or even unique, but it's a nice package that works well for me.
With the ability to predefine css constants I guess it's now possible to use the style prop directly and not have to use raw hex colors and pixel values (eg. there are css libraries with these https://open-props.style).
It has pros and cons like anything though. Trying to style a fundamental component is pretty painful. Like imagine your company’s main “button” element. It’s got 8 different sizes, optional icons on both sides, animations, styles, each needing to support different color combos. Tailwind is miserable for that. You get giant huge balls of spaghetti classes all over your button, and it’s pretty incomprehensible.
But for “glue” styles, it’s freakin amazing. Putting those components together, giving them spacing, even making simple components that don’t have lots of conditional properties? It’s really nice. You can style stuff quickly and consistently right from the markdown, you don’t have to think of classnames for every teeny little thing, and you can somewhat imagine what stuff looks like just by looking at the jsx.
I remember the crazy hype around it when it got popular, and it really put me off. Didn’t even try it for a long time. Now I’m in a codebase that doesn’t have it, and I miss it! I don’t miss it terribly, but it was a nice little QOL upgrade
I guess I didn’t explain fully, but for things like the button example, I use regular ol css modules. Tailwind is for all the glue. And in my experience, most of the css you write when working on a feature is glue.
I still don’t understand what it brings over putting style= whatever on the element.
You can't put a style for dark mode and one for light mode. Lifting these properties from styles to classes allows you to combine them with media queries and states.
They said
> Like imagine your company’s main “button” element. It’s got 8 different sizes, optional icons on both sides, animations, styles, each needing to support different color combos. Tailwind is miserable for that. You get giant huge balls of spaghetti classes all over your button, and it’s pretty incomprehensible.
Which to me sounds like they would not use Tailwind for dark mode / light mode things either. But I might be misunderstanding
Try to maintain that horrent webapp.
PD: That webapp it's what a ex co-worker called "technical bankrupt"
.brand-btn {}
.brand-btn--inverted {}
.brand-btn--icon-right {}
.brand-btn--smaln {}
.brand-btn--smaller {}
.brand-btn--big {}
<button class="brand-btn brand-btn--icon-right brand-btn--small brand-btn--inverted" />
However, very rarely need too many combinations of the same button with a brand logo.
You can have a nice component with all the cases, type-safe, and apply few utility classes to produce more maintainable code.
What does "it" relate to in the last sentence? Tailwind or Next.JS?
Anyway, making sure that background color still works, is that an argument for Tailwind? Wouldn't that be a great argument for simply using standard CSS properly?
They're not arguing for Tailwind. They have used Tailwind.
Its biggest problem is that it's a leaky abstraction. The classes translate _almost_ 1:1 to the equivalent CSS, but not quite and not always. In the best case scenario, you use a utility class and don't think about the CSS. In the worst, you must understand both how to implement the feature in CSS and how Tailwind does the translation. Then you need to think how to make Tailwind do what you want to do in CSS.
All of this adds a considerable amount of mental overhead while developing. And in the best case scenario developers don't even bother learning CSS, which eventually leads to a stagnation of knowledge. It wouldn't surprise me if some junior frontend developers don't even understand CSS, and just call themselves "Tailwind developers".
Yes, all abstractions move the focus to a higher layer up the stack, but the troubling thing with Tailwind is that on one hand it pretends that it's a lightweight abstraction (or not an abstraction at all[1]!), while at the same time causing confusion and degradation of knowledge of what it's supposed to be abstracting.
And then there's the insanity of seeing dozens of utility classes on elements, where if you're not careful, each one could look and behave slightly differently. The number of times I've been tempted to just change the margin value on a single element to fix something is too high. It reminds me of the ` ` and single-pixel GIF spacer hacks we used decades ago. The claimed solution to this are components, which sometimes are not a good fit, or grouping utility classes into a single class, but then why am I using Tailwind at all? There are also libraries like DaisyUI built on top of Tailwind to resolve this problem, but the thought of piling more abstractions on this Jenga tower makes me shudder.
I can understand why developers who are not great designers would find it appealing, and how it could be useful while prototyping, but in both cases using plain CSS (with some pre-processor, if you must) would be more maintainable and beneficial for the developer in the long run, while only slightly more inconvenient in the short-term.
Not in my experience.
You might think that is too long but that amount of time to migrate IMO is short.
What I am dealing now is a mix of styled components, SCSS and global styles. 4 hours is not even close enough to deal with half of it.
I will take TailwindCSS any day over this mess.
TIL that I have just been manipulated and that my joy of using it is really just ignorance. Good to know.
Tailwind is a prime example on how good marketing can help you win a market, even if the alternative is free, even if it's already crowded, even if your product is trash. Marketing wins.