Seems like a step backwards at worst and identical to Bootstrap/Foundation at best. Everyone provides class primitives like that
What you're describing offends separation-of-concerns
One of the biggest benefits in my opinion is, to communicate the different utility classes to your UI/UX person. By restricting him/her to discrete values for margin, padding, colors, etc. they will not go overboard with there designs and also make the handoff way easier. If you use zeplin for example you can for example define color names in the sketch file and zeplin will show them in their UI. You just click on a text and see "ahh she used text-gray-500".
Much less friction in the workflow.
As for the concerns about messy markup mentioned in some other reply. True that can happen sometimes, but if you use React or Vue, you can encapsulate a lot in components. The markup in the components high up in the tree will look basically the same. And the leaf components should be quite small anyways.
Another really nice benefit to the old way is that you don't have to worry about breaking stuff. When you change bg-gray-200 to bg-gray-300 you can be sure that it only affects the element you have in front of you.
But in the end I think people have to try it out to be able to judge Tailwind.
Regarding style attribute. You can’t do responsive-ness, hover- or focus-states in style attributes.
It’s hard to compare to bootstrap and the like because they give you components, while Tailwind is just a different way of writing CSS. You can of course extract components, btw, and define stuff like text-primary (that you can change in a central variable).
You update it in the one place (template/render function/component/helper/view/partial) that you wrote it.
> What you're describing offends separation-of-concerns
The entire HTML/HTTP/CSS/Javascript web schmozzle offends separation of concerns and is shot through with layering violations and dependence on the specific rather than on abstractions.
Tailwind responds to that particular shitshow by refactoring style at the point of HTML generation, which (particularly in a template-driven world) makes a crapload more sense than trying to build higher-order style abstractions in a language that was explicitly intended to not be Turing complete.
If the HTML ERB had chosen DSSSL instead of CSS, we wouldn't need this.
When it comes to developer productivity and happiness, composition beats inheritance, even in declarative paradigms.
If it turns out that later down the line I realize that "every card should have that size and color for the card title", then I'll pull it out to a separate class or part of a partial or something like that.
The idea being at that point then I have more context around when and how that particular section of a component should be displayed, so I have more context about what I should name the class (i.e. "card-subtitle").
I feel like the documentation explains it fairly well if you're interested in reading more about it:
https://tailwindcss.com/docs/extracting-components#extractin...
This removes the need to name at all. It can just be .card > h2 or whatever and there you would do your font-weight and color.
I don't even need to move over to my css file at all - I stay within my template and stay within my flow.
It seems crazy and counter-intuitive at first, but I find that it makes me a lot more productive.
I have been paralyzed by trying to do things the semantic way before too though. And now no one cares according the markup I venture to look at now and then.
Some editors like Brackets allows you to edit other files online and handles css specially so you can edit it just by hovering over class names, etc.
In fact, I think this scheme is a whole lot closer to what most developers actually want, which is to have composable classes that actually represent something semantic. "text-sm" is your small text. That should be consistent around your application. If you change what some of that looks like, you probably ought to be changing all of it. If you want a few elements to use a different text size, then go change the classes on those.
I really encourage you to try this out. I was somewhat skeptical, but it truly feels like a huge step forward. Going back to something like Bootstrap/Foundation or- God forbid- BEM feels incredibly painful to me now.
I also don't think separation-of-concerns is a reasonable goal. I read this article [1] after using tailwind for a while, and I agree with almost the entirety of it.
[1] https://adamwathan.me/css-utility-classes-and-separation-of-...
But you could also define a color called text-primary, if you are concerned that something like this would happen.
I don't think Tailwind is perfect, but find the benefits of consistent naming, easy modifications, and the "instant" design system, more than outweighs the negatives of utility classes. The framework also feels very light since there's no need to preprocess potentially hundreds of Sass files and I can just modify the view template or component directly. PurgeCSS also works amazingly well with Tailwind.
Adam, Jonathan, and Steve are also generous contributors to the opensource community!
Using Tailwind (or other atomic css frameworks) makes it easy to reason about styling while staying completely inside HTML during editing. Within a few days, you quickly memorize all the names and can build complex visuals while also benefiting from the well-designed default sizes and options.
My approach is to use class names, and in a custom stylesheet use tailwind's @apply function, so
.page-section { @apply bg-white rounded shadow overflow-hidden max-w-lg; }