It's worse than that; the common arguments for Tailwind literally derive from total ignorance of how CSS is made to work, and a disposal of guidelines that developers would worship in any other context (i.e. Don't Repeat Yourself).

It's really frustrating to be talking with someone about Tailwind and CSS, and realize that not only do they not know what "cascading" means, they never even considered the concept might be useful in the context of a stylesheet.

▲

pverheggen an hour ago | parent | next [-]

Tailwind, JS-in-CSS, and the like have become popular because they work well with the modern corporate UX workflow. A Figma component has a certain set of styles, you apply those same styles to the corresponding React component.

And none of this really violates DRY, your unit of reuse has shifted from a CSS class to a framework component. There's nothing precluding you from using an approach like DaisyUI if stock Tailwind has too much repetition for your taste.

▲

timr an hour ago | parent [-]

> A Figma component has a certain set of styles, you apply those same styles to the corresponding React component.

This is what CSS classes were made for. Of all of the arguments in favor of Tailwind, this is the one that drives me battiest. Say what you will about CSS, but "give a name to a re-usable set of styles for a component" is pretty much as fundamental as you can get.

> And none of this really violates DRY, your unit of reuse has shifted from a CSS class to a framework component.

Sure, sure. except for the inline styles everywhere. And the fact that everything is literally being repeated all over the place. But other than that, no repetition!

> There's nothing precluding you from using an approach like DaisyUI if stock Tailwind has too much repetition for your taste.

...and now you have three problems.

	▲	pverheggen 19 minutes ago \| parent \| next [-]
		There are a bunch of differences between Figma styles and CSS styles that prevent you from creating a 1:1 mapping: typography inheritance, spacing rules, and variant specificity to name a few. Like yes, CSS by itself is extremely powerful, but I see no reason why you should feel beholden to use all of its features simply because they're there. > Sure, sure. except for the inline styles everywhere. And the fact that everything is literally being repeated all over the place. But other than that, no repetition! Well, instead of repeating inline class names everywhere, you end up with CSS properties repeated everywhere. Not really seeing the difference.
	▲	9dev 44 minutes ago \| parent \| prev [-]
		> This is what CSS classes were made for. That brings with it the problem of naming a thousand things in a consistent way that everyone on your team needs to understand and remember, otherwise you end up with tons of duplicated classes, parallel systems, and bike shedding. Have we, as an industry, not felt this pain often enough yet? Do we really need to keep banging our head against the wall to figure out it does hurt? > Sure, sure. except for the inline styles everywhere. There are no inline styles when using Tailwind. There are references to variables from the design system. > And the fact that everything is literally being repeated all over the place. If you find yourself repeating the same sequence of classes, it's time to create a component in your frontend framework if you use one, or a Tailwind utility class. And even if you just copy-paste the same class strings all over the codebase, transport compression will eliminate that pretty much entirely.

▲

u_fucking_dork 2 hours ago | parent | prev | next [-]

The common arguments against Tailwind usually derive from total ignorance of working with CSS on large scale projects with many team members.

And when this is pointed out you’ll usually get replies that just hand wave it away as not a problem, as if things like BEM were invented for no reason.

▲

timr 2 hours ago | parent [-]

Yeah, that's a straw-man. I've worked on large-scale projects with many team members, and it's perfectly possible to use CSS as it was designed.

But sure, like most tools, it starts with understanding how it works.

▲

9dev 42 minutes ago | parent | next [-]

Sure it's possible, but is it possible for everyone on your team? Including the new hire, the interns, or the now-vibecoding managers?

Sooner or later it deteriorates.

▲

pverheggen an hour ago | parent | prev [-]

Sure, but "total ignorance of how CSS is made to work" is also a straw man.

	▲	an hour ago \| parent [-]
		[deleted]

▲

coolThingsFirst 2 hours ago | parent | prev [-]

And the cascading thing is a nightmare even after years.

Whenever i have written CSS/TailwindCSS which was unproblematic to extend it was when i literally switch thinking to use least amount of properties and let the page flow.

Whenever i see tons of css i know it’s brittle and will cause hours of wasted time down the line to fix something which already should have been fixed.

	▲	2 hours ago \| parent [-]
		[deleted]