Hacker News Reader

Comment by moralestapia | Hacker News Reader

I never got the appeal of Tailwind, it's almost a 1-to-1 map from style="" to classname="", they just made the terms slightly easier to remember.

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.

Edit: I have used Tailwind, a lot. Recently, upgrading from v3 to v4 in a Next.JS project, which was supposed to be a no brainer, turned out to be a four hour ordeal. I cannot spend that much time just to make sure that "background-color: red" still works, lmao, it is such a travesty. Because of that, I'm in the process of removing it from my projects now.

View on HN

That’s exactly what I thought until I actually tried tailwind. Now I really like it.

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

> 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 still don’t understand what it brings over putting style= whatever on the element.

> 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.

Sounded to me like parent commenter was not advocating for that sort of thing so much.

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

It sounds like you're saying we need to consider the flexibility and articulation that classes enable when they reflect considerations beyond concrete presentation.

I just today, I helped to a junior that asked me how he can move a button on a toolbar. He was fighting against some legacy webapp made with JSPs, that have a f** zillon of style="XXX" stuff on nearly everything. And what is worst ... nearly everything using "position: absolute" to layout nearly everything.

Try to maintain that horrent webapp.

PD: That webapp it's what a ex co-worker called "technical bankrupt"

If you got lots of "custom" styling for elements, why can't one write a CSS class just as easily and give the element that class? Why is Tailwind better? Am I not also writing the definitions in Tailwind then and assigning those classes to my element then? I don't get what the benefit is supposed to be.

That’s exactly what I do for elements with lots of custom styling!

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.

.brand-btn {}

.brand-btn--inverted {}

.brand-btn--icon-right {}

.brand-btn--smaln {}

.brand-btn--smaller {}

.brand-btn--big {}

However, very rarely need too many combinations of the same button with a brand logo.

We don't develop without components anymore.

You can have a nice component with all the cases, type-safe, and apply few utility classes to produce more maintainable code.

Agreed. Tailwind is an abomination.

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.

[1]: https://news.ycombinator.com/item?id=33787346

>All of this adds a considerable amount of mental overhead while developing

Not in my experience.

For the longest time, I didn't get it either. It took me actually trying it out in a project to like it. It's true, much of it is the same as writing inline-styles, but it's also more powerful than that. Here's a few things that I like about it:

- 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.

> Limited set of predefined values to us...

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).

> Recently, upgrading from v3 to v4 in a Next.JS project, which was supposed to be a no brainer, turned out to be a four hour ordeal.

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.

i think theres a divide between people who have worked in good front end repos and ones whove worked in horrible ones. I had to work on an app that was a mix of styled components, scss, inline styling, and globals. It was a wreck and every change took longer because of all the spaghetti styling you had to eat, Id take tailwind in a heartbeat over that.

> Edit: I have used Tailwind, a lot. Recently, upgrading from v3 to v4 in a Next.JS project, which was supposed to be a no brainer, turned out to be a four hour ordeal. I cannot spend that much time just to make sure that "background-color: red" still works, lmao, it is such a travesty. Because of that, I'm in the process of removing it from my projects now.

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?

>> I never got the appeal of Tailwind

They're not arguing for Tailwind. They have used Tailwind.

>Marketing wins

TIL that I have just been manipulated and that my joy of using it is really just ignorance. Good to know.

Reply on news.ycombinator.com