How is that any different from setting CSS in the style attribute of your tag? What happens when you need to update all the "text-sm text-gray-700" to something else?
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.
Concerns are not separated in the first place. Your CSS is heavily tied to the structure of your HTML and you even need to artificially think up structures to be able to write and apply the CSS. I recommend reading Adams blog post on the topic.
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).
> What happens when you need to update all the "text-sm text-gray-700" to something else
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.
Typically the "text-sm text-gray-700" would be a one-off styling while I'm developing a page or a component, not necessarily something that will be repeated a hundred times.
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:
Because I don't want that cognitive overhead of even thinking about what the selector should be. Then what if I have another sub-sub text? Do I make that an h3? An h4? I don't want to have to think about that. I just make it "text-xs" and move on.
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.
Have to agree. Having to think about the selector makes you think about the structure and make things more semantic.
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.
I understand but then why not .card > *:nth-child(1) and then so on down the child list? You could get away with those two selectors to match anything with at least an initial name. No decisions except for the first name.
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.
It's different because it's not actually setting a specific style, it's still a semantic description. You would never need to update all the "text-sm text-gray-700" in your project to something else, that just wouldn't make any sense. You might change what "text-sm" and "text-gray-700" (I'd probably go with a more meaningful name for colors, "text-gray-primary" or whatever, but hey) actually do, but you wouldn't want to actually modify all of those to be new classes at once.
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.
Classic question is what happens if you decide to change all gray text with the blue one? Do you end up having the class named text-gray that is setting text to blue, or you search & replace class names...
I was turned off to Tailwind at first, but after watching the screencasts[1] the workflow started to make sense. I personally find writing good CSS/Sass from scratch very tedious. For something as "simple" as styling, there are many decisions to make regarding naming conventions, modularization/file structure, specificity, design systems, etc. I almost always opt for pre-built frameworks like Bootstrap or Bulma, but as my projects grew in size, I find myself battling with the framework to customize the components.
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!
Reality is more important than technical purity. CSS styles and HTML structure are not separate concerns but tightly integrated in most projects.
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.
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