Live data from Hacker News

I don't recommend Tailwind CSS

en.andros.dev

171–179 of 179 posts

Re: I don't recommend Tailwind CSS

#171

Earlier quoted context omitted.

Absolutely not. Semantic classes are the wrong way to go. Your components (and their props API) are what encode the semantics. With Tailwind you never need to try to come up with a name for anything relating to style, you just use utility classes. It reduces cognitive load significantly.

And so we’re essentially back to ?

have that wrapped in a component named ErrorText and it makes perfectly sense. Why would you need a component ErrorText which restates its own name in the classname again when that classname is only ever used in that exact component. If anything you only need it because your atomic styles sit in another file and you somehow need to reference them. If you have both in the same file with a name ErrorText there is nothing more to give any semantic meaning.

Semantic class names make no sense in a component context and that's why tailwind feels like a liberation in the context of component-based web applications. A component and its interface is the semantic meaning, the markup and styles it contains are scoped to that component and should not be / need not be semantic at all. This greatly reduces cognitive load.

Re: I don't recommend Tailwind CSS

#172
post #99

Earlier quoted context omitted.

> If you end up programmatically layering class names, you're looking at a code smell. Why wouldn't you? Suppose you have Button class with `btn btn-primary`. The Button accepts className override so you can do . In this case you use tailwind-merge or clsx. Your Button implementation would be clsx('btn btn-primary', className), in which case right most class name prevails. Other than that, I agree tailwind is great.…

There is this implicit debate in web application development of cascading+overriding vs non-cascading-no-overriding. A lot of people don't even realize this is where the line is drawn and mix both together. I call them "component-based", "document-based" and "mixed". Component-based applications are usually better of with no styling cascading and no styling overriding. It makes things significantly easier because com…

that is a very good observation. I think in a component-based application "semantic css" entirely looses its purpose because the semantical meaning is encoded in the component name and interface and all the markup and styles it contains are scoped to only that component and never leak. In this world having re-usable atomic styles makes suddenly becomes the correct thing. If you don't have any components of course you are forced to apply .button everywhere to convey the message that. this is and that div styled like a button. But if you have a button component this is pointless.

Re: I don't recommend Tailwind CSS

#173

Earlier quoted context omitted.

Right so it is easier to write code quickly, but not to maintain a system. Tailwind is the right tool if you want to generate a prototype with LLM agents. It can be quickly deleted or can be used as visual prototype to create reusable components. And once the component is built for long term maintenance as priority, the collective knowledge has been built up so naming becomes simpler, important and elucidating.

The component itself is the semantics, adding naming over CSS classes adds no value whatsoever, only adds cognitive load and requirement of context switching to understand "what does this named class actually do?"

this! a semantic class name that is scoped to only that component and only ever used in that component is pointless indirection only needed to be able the reference the actual css properties in that other file sitting next to your component by using some name.

Re: I don't recommend Tailwind CSS

#175

I was very much in the Tailwind camp, and simultaneously loved it for its local reasoning and disliked it for how its long class names messed up my components. It has always felt like a bolted-on hack to me but I couldn't argue with the benefits. Turns out, CSS Modules comes with the same benefits while feeling much more like a natural extension to the web platform. The only thing I thoroughly miss is functions and d…

[flagged]

Re: I don't recommend Tailwind CSS

#176

Earlier quoted context omitted.

The component itself is the semantics, adding naming over CSS classes adds no value whatsoever, only adds cognitive load and requirement of context switching to understand "what does this named class actually do?"

Css classes are not big issue with css nesting and if component boundaries are settled and the design is well defined before implementation. Tailwind is a shorthand notation which is harder to parse than a structured css file (at least I strongly believe this we can agree on) and thus has only editing speed gains which is largely not an issue if prior work is done on exploration. Another way to frame it: tailwind is…

[dead]

Re: I don't recommend Tailwind CSS

#177

I registered my first domain 1997 and before that already coded websites: members.aol.com/…/ I saw the inception of CSS, the infamous ACID test, IE6, web standards movement - anything and everything. To this day, CSS is something that is not separating design from markup (try logic, you will get it), and as all things technology is now a mix of technical constraints, backwards compatibility, totally conflicting decis…

[flagged]

Re: I don't recommend Tailwind CSS

#179
post #148

Earlier quoted context omitted.

If BEM is regular CSS, why would I use BEM instead of the actual thing? It's a layer of indirection for no reason if it's the same. You use Tailwind in the same way you use BEM: becuase it makes it easier for frontend developers to write correct CSS.

You're right which is why I don't use BEM, it has no advantages over regular CSS, same with Tailwind.

You do you, but thankfully the rest of the industry disagrees with you.
Post reply on HN