Live data from Hacker News

I don't recommend Tailwind CSS

en.andros.dev

161–170 of 179 posts

Re: I don't recommend Tailwind CSS

#161

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?"

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 a good prototype syntax but is not the best syntax to for production code (human parsability). I’d skip it altogether to simplify the flow.

Re: I don't recommend Tailwind CSS

#162
post #10

This is such a bikeshedding debate. While you don't recommend it, projects with Tailwind work . Over years. You can onboard new developers to it, able to contribute productively immediately . Likewise, you can pick up work after months or years and don't have to remember or rediscover how your styling layer works. The conventions and class names come really naturally fast, and you can always look it up. It's just not…

The "rounding" was grasping at straws: > How round is rounded-lg? Author: "In my vanilla CSS, I can read it in the CSS file. In Tailwind, who knows?!?" Reality: You read it from location 2, not from location 1. The horror. I don't even have a dog in the race. I'm past my days of handcrafting HTML and CSS. I have a few Claude Coded apps that use Tailwind, but I've not looked at any of the files (yes yes, I know. They'…

I would even say the answer is... however round "large rounded" should be. Tailwind doesn't force arbitrary opinions on these things upon you - it's a set of utilities to enforce your design system. If rounded means 6rem, so be it.

There is, as you said, a single place to configure your design system (a CSS file, fwiw), which is objectively better than "well for these card-like containers we usually use 5px everywhere."

Besides, I'm really wondering what sad jokes some people use to edit code that don't even offer tooltips for the styles getting applied by Tailwind classes.

Re: I don't recommend Tailwind CSS

#163
post #88

Earlier quoted context omitted.

they do work… for any value of work . I have been in the industry for a while, and I've never seen a project which doesn't slowly devolve into fights with the cascade over time - arbitrary abstraction layers, ad-hoc organization patterns, developer-specific conventions, inconsistent naming, and so on. All of this usually creeps in the more a project grows. At some point, someone adds postcss or scss or another prepro…

Tailwind trades cascade complexity for design drift when working across teams. You can’t ignore that it encourages a different kind of undisciplined sloppiness. Would I take it over the 1000 line cascade problems? Probably, but I’d still prefer css modules over tailwind.

What kind of design drift do you mean? You set `--color-surface` in your theme once, then all surfaces in the app use the same color with `bg-surface`, regardless of the theme authoring parts of it. I don't know how you could enforce more consistency to CSS authors than Tailwind does.

Re: I don't recommend Tailwind CSS

#164
post #10

This is such a bikeshedding debate. While you don't recommend it, projects with Tailwind work . Over years. You can onboard new developers to it, able to contribute productively immediately . Likewise, you can pick up work after months or years and don't have to remember or rediscover how your styling layer works. The conventions and class names come really naturally fast, and you can always look it up. It's just not…

I can see this argument both ways. On the one hand, logically you'd expect the last assignment to take precedence, like the style attribute. On the other, conflicting styles don't make sense. The random outcome, entirely dependent on the Tailwind generation internals, is the worst of all worlds though, it's just an unfortunate side-effect of relying on cascading sheets to drive atomic styles.

Note that we're talking about an edge case for an authoring error - applying two conflicting styles to an element does not make sense, it has no defined behaviour, and is correctly flagged by linting tools as such.

Should Tailwind really go out of its way to pay a compile time tax, just to make this case resolve predictably? Or should people rather use code editors that point out invalid duplicated styles, which are always added in error?

Re: I don't recommend Tailwind CSS

#165
post #154

Earlier quoted context omitted.

I've never found tailwind to help someone who isn't already a reasonably skilled web developer. If you don't know CSS tailwind gets your far enough sometimes, but you have to learn many of the same paradigms as you would in CSS and you can still create issues that aren't as simple as missing "text-green-500". Tailwind seems most useful for devs who don't want to be responsible for managing multiple CSS files and all…

Well yeah, people need to learn the tools they’re using. How’s that shocking?

It isn't shocking and that wasn't my point. The OP is pointing to benefits of tailwind related to onboaring new devs, I was just raising that doesn't match my experience.

If a new dev doesn't know CSS well it won't help them. If a new dev does know CSS but doesn't know Tailwind, it still won't help.

The standardization can be claimed as a benefit, though it really amounts to avoiding having to architect how CSS is managed in a project and at the end of the day the solution is to just inline styles one a time (I.e. no cascade or stylesheets).

Though a bit unrelated, I take issue with the core promise of Tailwind - localization of styles on a node. As soon as flexbox and grid enter the picture I can't simply look at one node and know how it will render. Even more egregious is groups, though a useful feature it breaks locality of styling even worse. Throw in less used but valid syntax for attribute selectors, modifiers, sibling selectors, etc and you might as well be in CSS. Last I used TW it also didn't have an answer for using things like :has() though that could have changed.

Re: I don't recommend Tailwind CSS

#166
My problem is I thoroughly learned HTML and CSS twenty years ago and am only incidentally aware of how they have changed and improved since. (I'm mostly a backend programmer with some frontend skills. I work with another programmer who is the other way around. I also learnt during the time when new features to the specs moved into browsers at a glacial pace, making them hardly worth keeping up with.)

For example I was spinning up a new project and added SASS so I could do nesting to make things cleaner. My frontend counterpart pointed out that CSS already has that.

Anyone know of some good resources that would bring my knowledge up to date without trying to take me through first principles?

Re: I don't recommend Tailwind CSS

#168
post #10

This is such a bikeshedding debate. While you don't recommend it, projects with Tailwind work . Over years. You can onboard new developers to it, able to contribute productively immediately . Likewise, you can pick up work after months or years and don't have to remember or rediscover how your styling layer works. The conventions and class names come really naturally fast, and you can always look it up. It's just not…

I've never found tailwind to help someone who isn't already a reasonably skilled web developer. If you don't know CSS tailwind gets your far enough sometimes, but you have to learn many of the same paradigms as you would in CSS and you can still create issues that aren't as simple as missing "text-green-500". Tailwind seems most useful for devs who don't want to be responsible for managing multiple CSS files and all…

> If you don't know CSS tailwind gets your far enough sometimes, but you have to learn many of the same paradigms as you would in CSS.

This is also my experience. But one of my colleagues highlighted this as a strong feature. He had been doing web dev for many years, but always with a CSS framework. He was really glad that Tailwind forced him to learn plain CSS.

Re: I don't recommend Tailwind CSS

#170
post #88

Earlier quoted context omitted.

they do work… for any value of work . I have been in the industry for a while, and I've never seen a project which doesn't slowly devolve into fights with the cascade over time - arbitrary abstraction layers, ad-hoc organization patterns, developer-specific conventions, inconsistent naming, and so on. All of this usually creeps in the more a project grows. At some point, someone adds postcss or scss or another prepro…

Tailwind trades cascade complexity for design drift when working across teams. You can’t ignore that it encourages a different kind of undisciplined sloppiness. Would I take it over the 1000 line cascade problems? Probably, but I’d still prefer css modules over tailwind.

What do you mean it trades cascade complexity? The cascade complexity in CSS itself, tailwind can't turn that off, you always have that.
Post reply on HN