Regardless of how easy devs find it to be now, there's no denying that utility-only CSS is fighting the platform it's built on. jQuery and SASS showed the way for their specs to build toward. Contrast that to utility-only CSS, which I suspect is just going to get left behind as CSS solves the problems Tailwind, et al. try to work around.
On the contrary, utility classes actually drive you to HTML components/composing HTML fragments for HTML reuse, thus eliminating duplicate markup. This is a big problem that CSS, SASS, etc. are not solving and probably can't solve.
Instead of letting our tools lead us by the nose, what if we let design principles lead us? Why would a styling tool lead me to model my markup? That's the complete inverse of how one should be thinking about it. You model the markup first, you create reusable bits if you need them first. Then you style them. If the CSS forces your hand to change the markup, then you must, but that's becoming more and more rare with modern CSS.
I have no doubt that people that don't know the fundamentals at play have an easier time with Tailwind. That's how it goes with hacks. They're usually easier to apply than proper design and implementation. We're throwing in the towel with Tailwind, plain and simple.
> You model the markup first, you create reusable bits if you need them first.
Agreed, and with Tailwind you never have to leave this fragment of markup you're designing. You don't have to switch files to add CSS and invent meaningful names for styles, then ensure you use the same name in the markup file, nor do you ever have to hunt down and change these names and the markup across multiple files to ensure they are applied consistently down the road of you're using HTML components.
In fact, you rarely have to write CSS at all, you just focus on the markup and sprinkle in the predefined styles that you need. Much simpler.
> We're throwing in the towel with Tailwind, plain and simple.
If by throwing in the towel, you mean we're acknowledging that they took a suboptimal design path, I agree. Transclusion of HTML fragments would have been a much better path to take, and some people were arguing for it even back then (Xanadu folks IIRC). Now we've come full circle, and people are still arguing that decomposition for reuse are not good ways of structuring dynamically changing and evolving content.
For what it's worth, I was exactly where you are 3 years ago. I made all of the same arguments. I saw the value in Tailwind. I had come from rebuilding a CSS system for another application multiple times because we never could get it to work for us.
I would have never believed me now either, not until I saw it done first hand and learned how to do it. So, call it uncommon knowledge, or a rare skill, or whatever you want, but do know that not only is it possible, but the skills required are the same skills that enable you to build maintainable applications -- not just CSS.
In large part, this is why we failed in the past. We would often treat CSS as a second-class citizen and put our most junior "front end" developers on it. It should have been no surprise that it ended up as a tangled mess.
> You don't have to switch files to add CSS and invent meaningful names for styles, then ensure you use the same name in the markup file, nor do you ever have to hunt down and change these names and the markup across multiple files to ensure they are applied consistently down the road of you're using HTML components.
This isn't a real problem. The only time we've struggled to come up with a name is when CSS forces us to use some mechanical name that includes the word "container" or something like that. Usually, we just name the thing what it is. Usually, very often this is in the domain of the UI (hint, it is likely the same name as your React component, if you are using React and naming things well).
There's another problem here that complicates things. Most people shouldn't be using React for their forms over data applications. It's unnecessarily complex, but people now tend to think that server rendered HTML is yet another lost art. React plays very well with Tailwind in a sense, because you are already forced to make components for your UI, so what's sprinkling a little class soup in that file? What's sprinkling a few type declarations in the same file? What's sprinkling a few hooks in that file? What it all adds up to, once you can see it, is very difficult to read and reason about code all in one place. You can learn to see through the forest, but I personally would rather work on one tree at a time.
By the way, I'm not advocating for writing HTML in multiple places (and therefore re-using the CSS classes), that often should be abstracted in some way. In Rails, we use helpers and view template partials. Every technology has its options. Technically, web components fit this bill as well, but we don't make heavy use of them as I've found them unnecessarily complex.
I know we're just going to have to agree to disagree, but I find utility class based projects easier to maintain. Coming back to -- or inheriting -- css soup is never fun.
> I think people compare the best possible CSS with Tailwind rather than comparing what actually gets done with actual Tailwind.
Yep. The one Tailwind guy on the team will set everything up perfectly, and then no one else will ever have any desire to ever learn Tailwind, and it descends into a complete mess.
You can say "just learn Tailwind!", and see how far that gets you with a group of backend devs who've inherited some UI and just need to add a button.
I find this criticism interesting. Among the people actually doing it, it seems to be a near universal experience that Tailwind projects are easier to maintain than class based CSS.
What is it about Tailwind that is unmaintainable, in your view?
Utility classes give you the immediacy and power of inline styles in a consistent and controllable way, and they're a natural bridge to class based styling. If you've had a bad experience with utility classes, that's because you've had to deal with bad codebases that use them, rather than due to inherent issues.
Maybe, if the normal "agile" definition was limited to just stories and a sprint structure of some kind - atomic user stories and short, feature centric development cycles are hard to argue against. If your intention is to liken Tailwind to SuperMegaScrumKanbanJujitsuMarketingCoderStyle agile, I can assure that there is no real similarity.
I've worked with Tailwind in 3 separate, huge projects, and it's infinitely easier to upkeep than the monstrosity that large SCSS/CSS codebases turn into.
There's no hunting down random css classes all over the codebase, no dealing with insane cascade issues, no idiotic specificity issues, no unused classes that everyone is afraid to touch because it might break some random div somewhere...
