I’d be rather interested in a recommandation that don’t comes with de usuals pits of others solutions and comes with a the actual css code that will apply to the element displayed in autocomplete while editing the html / jsx.
I don't recommend Tailwind CSS
11–20 of 179 posts
Re: I don't recommend Tailwind CSS
#12[flagged]
Re: I don't recommend Tailwind CSS
#13I'm not a frontend guy so take this with a pinch of salt, but for a few personal projects I've done my approach is now "ai pls generate css". I thought it would be inconsistent and broken, but if you tell it to care about accessibility and you're willing to clean up a bit it's not that bad and you end up with very compact transfers after minification.
I tend to like simpler/textual interfaces though, admittedly this won't be everyone's cup of tea.
Re: I don't recommend Tailwind CSS
#14> there is a ceiling of basic classes you have to internalize
I think you mean floor. Floor is a minimum you need. Ceiling would be the maximum you can achieve.
Below this floor you're not useful. There's a ceiling to how much you can do with no code tools.
Re: I don't recommend Tailwind CSS
#15I agree with all points and they are the reason I'm very selective which project uses it and which doesn't.
It did give me some ideas for my own stylesheet writing though. The colorsystem is something even non-tailwind projects will have now.
Re: I don't recommend Tailwind CSS
#16I think tailwind helps. It is same as AI prompting, but in a deterministic and fine-grained way. Bottom line - it reduces the time to build.
Re: I don't recommend Tailwind CSS
#17The problem isn’t tailwind, it’s css. It always has been css. That being said, it’s a hard problem and I don’t have a better idea. Tailwind seems to at least fix or move the problem in the right direction.
Counterpoint: the problem is actually HTML and most of webtech is increasingly elaborate cope mechanisms to deal with the original sin.
Re: I don't recommend Tailwind CSS
#18This 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 fact that “text-red-500 text-green-500” resolves by stylesheet source order rather than anything visible in the markup means the “locality of behavior” promise quietly breaks exactly when you compose components dynamically, which is why tailwind-merge exists at all, and needing a runtime dependency to answer “which of my two classes wins?” is a real design smell, not a bikeshed.
Re: I don't recommend Tailwind CSS
#19As a 26+ year frontender, years ago I was against it on so many levels. Until I tried it. Never looked back. Also, inheriting projects with someone else’s code is fine. Just a quick look at the central config and you’re good to go.
Tailwind looks bad on "paper". It violates a lot of "best practices". It is ugly. Yet in reality it works. It gets the job done. It is fast to work with.
Constraints are known to enhance creativity.
Re: I don't recommend Tailwind CSS
#20Saying "unless you use @apply" invalidates this article for me. Everyone knows that @apply only exists as an escape hatch, it is not supposed to be used, except for when it's necessary like for compatibility with libraries that declare their own classes that you need to override.
The most commonly repeated point in the article is "escape hatches bad" and I think that's completely absurd. Of course you want escape hatches, otherwise when you do hit an edgecase you get stuck with no solution. That's exactly what would force you to throw away that approach and pivot. Tailwind doesn't have that problem because it was designed to include escape hatches.
Users deciding to use those escape hatches instead of sticking to a design, isn't Tailwind's fault.