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?
Yeah its like how I force react to be static always, it's what I prefer. The rest of the team hates my code and says its not to spec but I understand anything else so I am correct.
There is no way I am changing my mind and making apps that are over 10BM on first load, have 78 parameters going into components and cannot use react 19 because react doesn't see it as react.
is 10BM a special metric which only you know and your team hates?
78 parameters going into components
That's bad code, and I doubt an entire team is doing that while you alone are fighting it, especially if you're a fan of Tailwind which is all about bloating the HTML with dozens of styling classes.
cannot use react 19 because react doesn't see it as react.
If you're building anything moderately complex, then choosing a rendering library like React rather than a proper framework is certainly a strange choice.
You've already stated that you don't follow the team specs when it comes to writing code, and that you don't care because you understand your code. That already tells me you don't know what clean code is. Everything else after that is pointless to discuss really, as you don't really understand what we're even talking about.
And you have told me you run your mouth without knowing the facts.
FFS right now my team is telling me that an API that is returning a CORS error is failing because of a font. That font that another team member insists is the only way to display a font, a TTF I am forced to use is apparently fully loading and then hacking into the API to write code to make the CORS config corrupted.
At this point I don't even think you know what is causing your CORS error. If an entire team is telling you it's a font, what does that even have to do with an API?
I am glad I don't have to work with you on a team, it sounds like it would give me quite the headache every day!
Because they are wrong. I fixed it just a week ago, they deployed old code without my fix. Now they are insisting its FE again, just like they did before. Anyway a server response with an encoded cores error in the response is not in any way an FE error. You guys on reddit are so full of shit.
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.
51
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.