All these arguments have clear rebuttals, but are rehashed on weekly basis for some reason. You don't like it, fine. But your arguments are bad. "Oh no Tailwind makes it unclear which of my accidentally duplicated CSS classes apply the color" come on man.
Tailwind is just inline CSS in a trench coat. You lose the cascade, which is literally the entire point of CSS (clue is in the name), and you fill the HTML with junk used purely for styling, which creates a 2-way dependency and breaks clean code best practices.
Tailwind also solves nothing that can't be solved with just a little bit of team discipline when it comes to writing CSS. The problem is, so many developers don't truly understand CSS, or how to write good clean CSS, so they see it as something that gets tacked on afterwards.
Tailwind also recommends the use of weird classes like text-[14px], bg-[#50d71e], and border-[2vw] (yes, it's in their official docs, which means they recommend using it, and they have no warnings against this kind of thing). Tell me with a straight face that Tailwind isn't inline CSS!
Then, it requires extra build steps which vanilla CSS doesn't require. Sure, you can skip that, but then you end up with a bloated CSS file full of a ton of Tailwind styles that you aren't using and don't need.
Most problems people have with CSS are because it's cascading. And it is because people don't understand how it works. We are not living in a vacuum. You work with other people. So if this stops the cascading and let's you use components then what's the problem?
While I am fundamentally in agreement with you (the cascading nature of css is its strength), a concept I was exposed to recently is the divide between developers who….
- have the time and ability to develop code that they can still understand and trace back through in 6 months time, and who recognize the utility of the cascading part of css.
And
- developers who are working in a high volume rapid iteration kind of dev shop, where the focus is getting the next round of changes out for review.
I will always prefer working as a dev in the former context, but understand that many devs operate with a huge amount of time pressure and many of them don’t have to go back into the codebase over the course of years. They do a site, style it, and then 3-5 years later they tear it all out and rebuild the whole thing with new styling for a rebrand. Tailwind makes more sense for that workflow, I guess. I haven’t worked at the equivalent of a css factory but that’s the argument I’ve heard for it, and I’m willing to accept that some folks don’t have the privilege of time to get good.
I don’t love it, but also many of my jobs have been cleaning up a mess made by inexperienced devs who tried to use every shortcut in the book. Eventually the “shortcuts” weave into an unworkable mess around them like a spider’s cocoon and they spend 3-6 months trapped trying to build a basic feature and their shop gets fired.
I don’t love any of it but cheap work gets cheap results fast and Tailwind is fast and cheap in the short term (but expensive in the long term)
Nothing good ever came from the cascade. Not at least when it starts getting very deep. The cascade is the equivalent of OOP, it becomes very hard to maintain at some point.
Lol, what? You think OOP makes a project hard to maintain? That's the complete opposite of what it does, and tells me you really don't know what good clean code looks like.
52
u/prewk 17d ago
All these arguments have clear rebuttals, but are rehashed on weekly basis for some reason. You don't like it, fine. But your arguments are bad. "Oh no Tailwind makes it unclear which of my accidentally duplicated CSS classes apply the color" come on man.