[ahussain]

People like tailwind because it feels like the correct abstraction. It helps you colocate layout and styling, thereby reducing cognitive load.

With CSS you have to add meaningless class names to your html (+remember them), learn complicated (+fragile) selectors, and memorise low level CSS styles.

With tailwind you just specify the styling you want. And if using React, the “cascading” piece is already taken care of.

[zarzavat]

The point of CSS is specifically to separate styling and semantics, so that they are not tightly coupled.

If you were writing a blog post you would want to be able to change the theme without going through every blog post you ever wrote, no?

If I'm writing a React component I don't want it tightly coupled to its cosmetic appearance for the same reason. Styling is imposed on elements, intrinsic styles are bad and work against reusability, that's why we all use resets is it not?

I do agree that the class name system doesn't scale but the solution is not to double down on coupling, but rather to double down on abstraction and find better ways to identify and select elements.

[seanwilson]

Content should come from your database, Markdown, JSON, models etc.

Presentation is determined by the HTML and CSS together.

So your content and presentation is already separate enough to get the benefits. Breaking up the presentation layer further with premature abstractions spread over multiple files comes at a cost for little payback. I'm sure everyone has worked on sites where you're scared to make CSS file edits because the unpredictable ripple of changes might break unrelated pages.

Styling code near your semantic HTML tags doesn't get in the way, and they're highly related too so you want to iterate and review on them together.

I've never seen a complex website redesign that didn't involve almost gutting the HTML either. CSS isn't powerful enough alone and it's not worth the cost of jumping through hoops trying because it's rare sites need theme switchers. Even blog post themes for the same platform come with their own HTML instead of being CSS-only.

> If you were writing a blog post you would want to be able to change the theme without going through every blog post you ever wrote, no?

Tailwind sites often have a `prose` class specifically for styling post content in the traditional CSS way (especially if you're not in control of how the HTML was generated) and this is some of the simplest styling work. For complex UIs and branded elements though, the utility class approach scales much better.

[code_biologist]

I'll add to my sibling commenters and say that there is a long history of critiquing the value of separation of concerns. One of my favorite early talks that sold me on React was "Pete Hunt: React: Rethinking best practices -- JSConf EU" from Oct 2013 [1] that critiqued the separation of concerns of HTML templates + JS popular in the 2000s and early 2010s and instead advocated for componentization as higher return on investment. I think people already saw styling separation of concerns as not particularly valuable at that point as well, just it wasn't clear what component-friendly styling abstraction was going to win.

[1] https://www.youtube.com/watch?v=x7cQ3mrcKaY

[Jaygles]

I do want styles tightly coupled to my React components. The product I work on has tens of thousands of React components.

I don't want to have to update some random CSS file to change one component's appearance. I've had to do this before and every time its a huge pain to not affect dozens of random other components. Other engineers encounter the same challenge and write poor CSS to deal with it. This compounds over time and becomes a huge mess.

Having a robust design system that enables the composition of complicated UIs without the need for much customization is the way.

[amrocha]

You’re kinda late to the party. 15 years ago that was the way to build UIs, but componentization changed that. Now we reason about UIs as blocks, not as pages, so collocation of logic, markup, and style makes the most sense.

Not to say that every component should be unique, generic components can be built in an extensible way, and users can extend those components while applying unique styling.

Theming is also a solved issue through contexts.

Reducing coupling was never a good idea. Markup and styling are intrinsically linked, making any change to the markup most likely will require changes to the styling, and vice versa. Instead of pretending we can separate the two, modern UI tools embrace the coupling and make building as efficient as possible.

[halfcat]

You're talking about separation of concerns (SOC), as opposed to locality of behavior (LOB).

This is the insight that Tailwind and others like HTMX made clear: Separation of concerns is not a universal virtue. It comes with a cognitive cost. Most notably when you have a growing inheritance hierarchy, and you either need 12 files open or tooling that helps you understand which of the 482 classes are in play for the specific case you’re troubleshooting. Vanilla CSS can be like that, especially when it’s not one’s primary skillset. With Tailwind you say ”this button needs to be blue”, and consolidate stuff into CSS later once the right patterns of abstraction become clear. Tailwind makes exploratory building way faster when we’re not CSS experts.

SOC is usually a virtue when teams are split (frontend/bavkend, etc), but LOB is a virtue when teams are small, full stack, or working on monoliths (this is basically Conway’s law, the shape of the codebase mirrors the shape of the team).

[maple3142]

I think the problem is simply that css is too restricted that you can style a fixed piece of html in any way you want. In practice, achieving some desired layout require changing the html structure. The missing layer would be something that can change the structure of html like js or xslt. In modern frontend development you already have data defined in some json, and html + css combined together is the presentation layer that can't really be separated.

[solumunus]

People who have tried both throughout their careers are generally sticking with Tailwind. I didn’t get it at first either, but after using it extensively I would never go back to the old way.

[csallen]

> The point of CSS is specifically to separate styling and semantics, so that they are not tightly coupled.

That was the original point, and it turned out that nobody cares about that 99% of the time. It's premature optimization and it violates "YAGNI". And in addition to not being something most people need, it's just a pain to set and remember and organize class names and organize files.

Remember CSS Zen Garden from the late 90s? How many sites actually do anything like that? Almost none.

And the beauty of Tailwind is, when you actually do need themes, that's the only stuff you have to name and organize in separate CSS files. Instead of having to do that with literally all of your CSS.

[krsdcbl]

disagree. Colocation seems great when authoring, but it comes at a big cost of downstream tech debt

there could be better ways to ease the burdon of naming things, while preserving cascade and the actual full features of CSS

Tailwind is a mirage, a shortcut to not having to do the important stuff by stacking wrappers on top of wrappers and redundancy

And the "fragile" part is exactly the same thing with tailwind, it all remains low specificity class names

[DangitBobby]

Every line of CSS you write creates tech debt, it has nothing to do with tailwind.

[hdjrudni]

Those are the same selling points as CSS-in-JSS libs like Styled Components. Or CSS Components.

Except your last point about "low-level CSS styles" which I'd argue is a weak point. You really should learn the underlying CSS to gain mastery of it.

Not arguing for one thing over another, just saying Tailwind really never had anything to offer me personally, but maybe if I wasn't already proficient in CSS and the other 2 options didn't exist it might hold some appeal for me.

[ahussain]

It’s more about cognitive load, and abstraction level. If you’re trying to make an object spin, it’s much easier to use the tailwind class than it is to remember css keyframes.

Sure, when debugging a complex issue, it’s worth knowing the low-level, but CSS is not a great abstraction for day-to-day work.

[amrocha]

You’re right that it’s not much more than a css in js library, but I’ve found myself pleasantly surprised at how efficient I am using it, despite also having years of css experience.

Things like remembering what the flex syntax is, or coming up with a padding system or a colour scheme become very very easy.

I think the editor tooling for tailwind is where most of the benefit comes from.

I also prefer the syntax over direct css in js systems. It’s less characters, which means it’s easier to parse.

Give it a try, you might be surprised!

[never_inline]

Can you suggest a best place to learn CSS in-depth, from first principles? (as opposed to, say, simple tutorials)