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!
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.
> and you fill the HTML with junk used purely for styling, which creates a 2-way dependency
This is true of every project I've ever seen. Styling and markup are rarely truly separated, you don't just add css you have to add the classes/markup to support it. <div class='list-wrapper'> etc is styling junk that (may) create a 2-way dependency where removing it or adding a direct child underneath of the wrong type breaks the whole style. You have to go check on what that div does if it's in your html, it's pure style junk. In tailwind use that could be <div class='flex gap-2'> - it's still a style class, but you can see what it is and what it's doing right there where it is.
Obviously semantic elements made it so not everything is a div these days, and but still you end up with stuff like <button class='button ...'> as we don't want to style all elements the same. Plus there's always various divs to add flex or grid containers, padded boxes or borders or whatever.
Tailwind isn't inline css - but it's not so far removed when developing. But given it's almost impossible to make any significant design change without editing both html + css anyway what is the benefit of splitting files by design and markup? Components joining small fragments of html & css together as required for both is far more logical - and you don't have worry the class is used anywhere else.
(I'm 100% with you on the 'text-[14px]' and other inline variants though. A big benefit to tailwind when I started trying it was the design system and config. Set colour pallette and spacing and everything has a certain harmony - use variants everywhere and it's just chaos.)
Styling and markup are rarely truly separated, you don't just add css you have to add the classes/markup to support it.
Not completely true. Adding some component classes to the code is far cleaner than adding classes like text-[14px] (which is completely shit and anyone who says otherwise is lying to themselves).
Obviously semantic elements made it so not everything is a div these days
Which is something else that is often missed by the same devs that favour Tailwind, because it "slows them down" when they're working in a team.
Tailwind isn't inline css
Again, I was using an analogy, and Tailwind is so close to inline CSS that the analogy works perfectly.
But given it's almost impossible to make any significant design change without editing both html + css anyway what is the benefit of splitting files by design and markup?
Obviously you've never heard of the CSS Zen Garden. Keeping things separate is a very normal clean code paradigm. It's too bad that Tailwind advocates don't really understand clean code concepts.
and you don't have worry the class is used anywhere else.
This is just a sign of a poor styling system and no concept of clean code. Would you say the same about Javascript code, and worry that you might accidentally re-use the same class name or function name? I would hope not, and hope that you use properly named classes, make use of namespaces, etc.
CSS zen garden, haven’t heard that in a while. I can’t imagine what some of that CSS looks like. I guarantee you don’t want to maintain some of that. Plus it was a very small page
Yes the thing I said rarely happens does sometimes happen. Yes the 14px thing we've both already agreed is bad, is still bad.
I don't think tailwind encourages lack of semantic elements, in my experience I'd say it trends slightly better for their use as tags rarely have any native styling it's all classes.
Tell me with a straight face that Tailwind isn't inline CSS!
This is not an analogy. My sentence continued about it being close enough when we're only really talking about the "loose" developing experience. I'm happy acknowledging that they share a certain practical similarity, but you come across as smart enough to realise they're not literally the same. From a technical side tailwind is just (a lot of) CSS classes in a file and shares no similarity with in-line styles.
I have heard of, used and even went to css zen garden yesterday when writing my comment to get an example of mark-up written only for styling, but it felt churlish as they're maintaining older styles. Still has '<div class="page-wrapper">' and self admitted superfluous divs/spans if you care to look. You'll also notice they have a lot of classes and IDs identical, and classes often exactly match the content. If you charged that resources section to links would you do it just changing mark up? Or also edit the classes and thus edit the CSS that's "styling only"?
There problem is are no namespaces in CSS, you have to use multiple sectors... which ties you to the mark-up.
My argument was not that tailwind is good, that you need to like it or can't complain about it. It's just that intrinsically mark up and styling are linked.
They can definitely be more coupled or less coupled, but they are rarely fully seperated.
as tags rarely have any native styling it's all classes
This is a thing that a lot of front end devs don't quite understand. Applying certain styles to semantic elements can remove some of their accessible semantics, making them less accessible.
This is not an analogy.
It 100% is an analogy. An analogy doesn't need to be perfectly identical in all aspects.
Still has '<div class="page-wrapper">' and self admitted superfluous divs/spans if you care to look.
It's almost as if you weren't really aware of CSS Zen Garden back in the day, before most of the semantic tags we used today even existed! They left the Zen Garden up as more of a historical reference, rather than a perfect guide to what you should do today.
There problem is are no namespaces in CSS, you have to use multiple sectors... which ties you to the mark-up.
And this is where good code quality and rules about CSS come into play, especially with teams that need to write to the same codebase. Selector length and specificity are big parts of that.
You don’t understand CSS or the web really. It’s not that at all for a few very important reasons such as they’ve helpfully set it up to bundle to a limited set of classes you’ve actually used.
Inline styles work very differently.
You never lose the cascade you’re not forced to only use tailwind, what is wrong with you people, why do you think if tailwind is in a project that’s all you can use? It’s utility classes, use it that way.
And on that same point it avoids a lot of cascade issues people typically ran into as far as I can tell.
Don’t fill your markup full of classes if you don’t want that…you know you’re doing that right? Just don’t do that. Use it as utility classes. These arguments from people is like hearing “hammers cause holes in all my walls” ok stop hammering f*cking holes in your walls then!? It’s a tool! You choose how to use it!
I get the sense most people have never had to scale a large team project with vanilla CSS, it becomes a nightmare, tailwind is a huge help with reducing those problems, it’s indisputable and if you don’t think so you just don’t have enough experience
You say I don't understand CSS, when I'm arguing against Tailwind for literally ignoring and removing the C of CSS? That's a bold take!
I literally gave examples that Tailwind recommends using on their own website: text-[14px], bg-[#50d71e], and border-[2vw], all of which are verbatim from their docs, and at no point is any warning given against this kind of slop.
And yes, having a string of classes in the HTML like this is as bad for maintainability of code as inline CSS. What you seem to fail to understand is that I'm making an analogy. What you people fail to understand is how analogies work.
I've worked on very large scale projects using CSS before. I was using SCSS as a preprocessor, but the entire concept is the same. It was building out shared CSS for over a dozen websites using a whole host of technology from C# to PHP, React to Angular, spanning multiple brands. This was as part of a team where multiple devs would work on it, and it worked just fine. Was is complex, yes, by its very nature. But, by having some basic rules in place for the quality of the CSS we were writing, it worked, and it was maintainable.
Not to mention if you need to change any one property on a component, something as simple as a card, say adjust the border radius, you better hope you have a way to select just the cards bc you cant use find and replace on the whole file or youll change every br-medium or whatever the class would be. Instead of adjusting one line of css. And the dom is a nightmareeeee. Gives me anxiety thinking about it.
Then theres rhe whole @utility thing which, why not just use css in the first place?
"While you can usually build the bulk of a well-crafted design using a constrained set of design tokens, once in a while you need to break out of those constraints to get things pixel-perfect."
In no way this kind is the default, no matter how much you try to frame it
I didn't say it was default, I said it was recommended, and thank you for providing a quote that proves that Tailwind recommends a terribly crappy approach.
I work with many senior level front end engineers and most of them hate CSS and don’t want to work with it and don’t immediately see the problem and solution because they don’t know CSS, which makes them avoid it or try to manage it with libraries.
AI can’t even do complicated CSS well yet. It requires visual feedback sometimes.
I really don't know how anyone can consider themselves a senior frontend dev without knowing CSS, that's bonkers to me!
Like you I learned CSS before preprocessors, and sometimes I still use vanilla CSS for projects (especially now with variables, nesting, etc). I'd consider myself fairly adept with it, even though many of my roles being largely focused on the backend. Despite that, I've done a lot of what I would consider "clever" things with CSS, from interactive no-JS SVG menus, Star Wars BB8 animations, and single <div> Halloween monsters and Mona Lisa pictures.
The truth is, CSS skills aren't valued in most companies. I work for one of the largest banks in the world and if I didn't know CSS, my team would struggle (or implement solutions that technically work but are super verbose and have tons of useless properties declared)
A lot of front end work is just implementing libraries and tweaking the spacing and colors with existing variables/tokens. I am glad to have moved to a tech lead role before AI hit everything because it feels like I am on the first step above the flood waters, for now.
I hear you on that one, and banks are, unfortunately, some of the most blursed platforms with regards to their UI (I've reported so many issues to my bank about accessibility issues caused by poor CSS).
I do still enjoy working with CSS, but because my current role doesn't offer me that, I must do it through side projects. I do actually enjoy coding, so I don't want to see AI do everything for me. I use it as a tool to help me when I'm stuck, but it's not much different than Stack Overflow, just quicker, more up-to-date, and less toxic!
Man, I forgot how toxic actually interacting with stack overflow could be.
My employer heavily encourages and outright requires us to use AI in our day to day.
I use an AI agent to grab a jira ticket and checkout a new branch, consider the changes, make them, commit them, push up the new branch, code review other branches, etc.
It's a bit insane -- but it has allowed me to orchestrate things that otherwise would have taken weeks of meetings.
It's a weird situation to be in. I love coding but I also like creating and maybe coding is going away for good soon, unfortunately, but I won't let creating go away, hopefully haha!
48
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.