[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.

[zarzavat]

> 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.

CSS gives you multiple tools to solve this problem, if you don't use any of them then it's not really CSS's fault.

> Styling code near your semantic HTML tags doesn't get in the way

It does. When I'm working on functionality I don't want to see styles and vice versa. It adds a layer of noise that is not relevant.

If I'm making e.g. a search dropdown, I don't need to see any information about its cosmetic appearance. I do want to see information about how it functions.

Especially the other way around: if I'm styling the search dropdown I don't want to have to track down every JSX element in every sub-component. That's super tedious. All I need to know when I'm styling is the overall structure of the final element tree not of the vdom tree which could be considerably more complex.

> I've never seen a complex website redesign that didn't involve almost gutting the HTML either

Perhaps for a landing page. For a content-based website or web app you often want to adjust the design without touching your components.

[mstipetic]

So hide the class list if you don’t want to see it

[vaylian]

> I've never seen a complex website redesign that didn't involve almost gutting the HTML either. CSS isn't powerful enough alone

I recognize your experience. But I would also like to argue that good semantic CSS class names require active development effort. If you inherit a code base where no one has done the work of properly assigning semantic CSS names to tags, then you can't update the external stylesheet without touching the HTML.

https://csszengarden.com/ shows how a clean separation between HTML and CSS can be achieved. This is obviously a simple web site and there is not much cruft that accumulated over the years. But the principles behind it are scalable when people take the separation of content and representation seriously.

[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.

[jasonkester]

That’s the heart of the matter.

Front end development got taken over by the Enterprise Java camp at some point, so now there is no html and css. There’s 10,000 components, and thus nothing that can be styled in a cascading way.

All these arguments are just disconnects between that camp and the oldskool that still writes at least some html by hand.

When I get sucked into react land for a gig, it starts making sense to just tell this particular div tag to have 2px of padding because the piece of code I’m typing is the only thing that’s ever going to emit it.

Then I go back to my own stuff and lean on css to style my handful of reusable pieces.

[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.

[zarzavat]

In the webdev world being late is the same as being early. Just wait for the pendulum to swing back.

Tailwind is like GenZ has discovered the bgcolor="" attribute.

> Markup and styling are intrinsically linked, making any change to the markup most likely will require changes to the styling, and vice versa.

No, not vice versa. It's only in one direction. Changing the component requires changing styles, but changing styles doesn't require changing the component if it's merely cosmetic. If I have a button and I want to make it red the button doesn't have to know what color it is.

[amrocha]

There’s nothing “gen z” about Tailwind, and there’s no pendulum effect either, and dismissing the very real benefit thousands of people report from Tailwind based on that is very small minded.

That kind of lack of intellectual curiosity is not a great trait for an engineer.

[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.

[DangitBobby]

Not only does no one care, but it's not even true. There are effects you simply cannot achieve without including additional elements. So separation of styling and sementics is dead on arrival.