Comment by azangru

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.

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

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.

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.

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.

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

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

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.

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

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.

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

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!

I first took a css courses to get the basics then didn’t do much with it, then tailwind came out. I had used bootstrap, but always struggled to get stuff to look nice. I’m not doing web dev most of the time. So it was much easier to memorize tailwind utility classes than css. These days with ui frameworks like daisy, shadcn, tailwind is pretty easy for doing something simple for an IT dev tool but still customize it.

For creativity, I wished I had the time to get really good with css. It really seems to have grown a lot. Using sveltekit, its really easy to get component scoped css

It lets you apply styles to a single element without it messing up the whole rest of the page/site/app. i.e. it disabled the primary feature of CSS, the thing most people don't want from it.

Honestly, for me, tailwind was just pleasant to work with and pure css definitely was not.

And I was super skeptical about it at first. I almost said no to it, but I trusted our main ui guy and wanted to allow him autonomy. And I ended up loving tailwind after working with it.

CSS requires discipline, or you end up accidentally styling something completely unrelated because you were overly general, or overly specific, or accidentally reused a class name. CSS disallows local reasoning. If you’re writing markup for a component, you have to jump between two files.

There are plenty of other problems Tailwind solves, but these two alone make me never want to go back.

And nearly every step it's made has been for the better. I used sass on that blog, because a few corner case features weren't widely available when I last did work on the style, but for the last 3 projects I've worked on, I don't use it anymore. Pure css can do basically everything I needed before. Sure, I bundle using bun's bundler, but that's for performance optimization, nothing more

I was too subtle but the issue is less understanding CSS and more collaborating in a team where someone decides to add a specific rule that fixes something applies on every page but makes no sense semantically.

Then do that 100 times to create spaghetti. CSS rule anywhere can affect anything whereas tailwind is more local.

You can also bricklay it along lines of components in React, so you know how X component renders always and it wont look like a pig when tranplanted to the legacy billing screen.

I now recall why I like tailwind! Been backending for a while now (zero regrets lol)