[graydsl]

Yeah but that is the easiest example imaginable. The problem is not a button class its the card-left-wrapper-container class that you have to use to style something the right way.

It basically boils down to naming things for me. The author says it's a good thing. I don't think so. Most of the time in plain CSS we have to come up with arbitrary names, that introduce confusion and bugs later on.

Utility classes, while sometimes cumbersome to read, always state their intent.

[wvenable]

What's the tailwind equivalent of `card-left-wrapper-container`? I imagine it's 200 characters wide.

Based on the name I'm going to assume that the class is used on container for a layout with cards on the left.

Utility classes don't state their intent they state their literal contents. If the intent is to be a button or be a wrapper-container then that's in a well conceived class name.

> Most of the time in plain CSS we have to come up with arbitrary names, that introduce confusion and bugs later on.

If the names are arbitrary then of course have problems! If you code and made up arbitrary names for functions you'd also have problems. The point of the name is to add clarity and abstract out details I don't need to know. I don't need to know that buttons have a certain padding, margin, etc when I'm placing them on a form. And I don't need to know everywhere they are placed when I style them.

[graydsl]

> Based on the name I'm going to assume that the class is used on container for a layout with cards on the left.

That's funny my intention was to name a wrapper around a container inside of card that is usually used on the left side. But of course we had different contexts in mind and a lot of these issues can be sorted out by coding conventions.

The thing is I was never able to wrap my head around the whole separation of concerns thing, when it comes to HTML, CSS and JS. I think that is because I come from a mobile dev background where we always had some kind of markup (or just plain code) which described the elements and how they looked. The structure of the UI and the styling were always co-located.

Coming to the web I was very confused of why you would want to separate both of them. And in my opinion we can see that change not only in TailwindCSS, Tachyon or ChakraUI but also in component based JS frameworks as well. Everything is about colocation these days, which makes it much easier to reason about what is going on in this small, little, pocket of code in my application.

I like that change. :)

[Zancarius]

You can create components by aggregating the utility classes in tailwind. In fact, the documentation recommends this approach for production[1]. So if you want your "button" class, you can have your "button" class.

The reason tailwindcss has so many proponents is arguably because of its compositional design, but it's paradoxically not one of the first things people seem to talk about when they're discussing tailwind. They fixate on its utility-first design. I think this does it a significant disservice.

No, I don't know why. I'm not a designer.

[1] https://tailwindcss.com/docs/extracting-components

[fragile_frogs]

At this point you might as well use normal CSS.

[fragile_frogs]

> Utility classes, while sometimes cumbersome to read, always state their intent.

CSS properties always state their intent as well and IMO are even more explicit in what they are doing.