One advantage of Tailwind's removal of a layer of indirection: it obviates the need to come up with names for CSS classes that are neither too specific nor too generic. A serious advantage: the costs of having to name things are often underappreciated.
But how about we turn this around: when an abstraction is particularly hard to name, could that be a sign that it might not actually be a useful one?
@vinnl Well sometimes it's not just an abstraction, working with components you already have an abstraction but you have to style individual parts.
Sure, you could just name those parts "one", "two", "three", etc. and since those are scoped to the component it would be ok. But it doesn't feel right so you start making up names.
Like Feynman said "It's not the same knowing the name of something and knowing something". So it's better to skip the naming altogether :D.
@vinnl Yes, technically you're right but in that scenario I'm abstracting out of necessity (because writing inline styles is too cumbersome). We could say that Tailwind makes it easier to work on concretions and only abstract when necessary :).
I remember Adam (the creator of Tailwind) talking about using this approach to write UI without components, and only create a component when you start repeating yourself. Similar to the rule of 3 for functions/classes but applied to the UI.
@noeldemartin Yes, exactly!
@noeldemartin I'd argue that it *is* an abstraction: when you define a class "part1", you're abstracting over the styles of that element so that you could theoretically apply them to a different element that would reuse them.
But since there aren't actually any other elements that share those styles — you'd just reuse the component to reuse the styling — that abstraction into a separate CSS class doesn't provide any value.