Whether Tailwind is functionally and pragmatically better than inline styles isn't even important. It looks like inline styles, so the first reaction of almost any experienced designer/developer that looks at it is to make that association and squirm in discomfort at its mere appearance.
.i-dont__find-bem--very-readable.
If you're into knowing where your class came from, it seems tailwind would be even better for you because now you have access directly to your styles right there in your markup. Skip the class step altogether!
I treat my name spacing the way I do in most source code. All the code for a unit is in the same file or in files called out from that file.
If you’re not nesting in Sass you’re missing out on some of the better parts.
https://medium.com/@davnicwil/how-i-learned-to-stop-worrying...
Tldr: for me, classes make more sense for reuse in simpler content-heavy scenarios. For anything remotely complex or webapp-like, I think they are the wrong abstraction.
I suspect people who immediately dislike this maybe are not using some type of component-based UI. CSS classes are all about code-reuse. If you have the concept of say a "button" in your UI, and you are copying your button markup every where you use that "button" then it certainly makes sense to have a class for your button markup that encapsulates the styles for that button in a style sheet somewhere.
If using a button component however, you've already created a place for the concept of your button to exist. At that point if you go on making a class in some style sheet that also represents the concept of your button, now your button concept exists in multiple places, linked together by one or several class names. That seems a lot messier to me than using utility first styles, but I don't think it really makes a huge difference one way or another.