| I think I don't fit in either of your groups. I’m not against Tailwind, but I didn't used it yet because I struggle to see why it's a better approach compared to other options like Web Components or React Styled Components. The biggest issue I have with Tailwind is how it clutters the HTML with a ton of utility classes making the HTML harder to read and maintain. Of course I see Tailwind being better than using large global CSS files with the classic CSS approach of naming html tags. But we do have ways where the CSS is scoped to a component without polluting the global namespace. Like Web Components and Styled Components. Both keep styles tied directly to the component (or more general, a specific group of html tags), making it easy to see which styles apply where. And yes, with them there’s no need for global class names, without having to worry about unwanted side effects or clashes. If I remove a component, I also remove its associated styles without worrying about unused CSS being left behind since both are tied together. Plus, there’s no risk of one component's styles unintentionally affecting another (thanks to shadow DOMs). I really value keeping HTML very short and readable by not mixing presentational styles directly in the markup. Tailwind’s approach, where the styling is all in the class attributes, makes the HTML feel cluttered, especially when you have long class lists on a single line, and GOD forbid you have actual class names to use there. It’s harder to understand what styles are applied at a glance since you cant even have it well indented, and it clearly reminds many reasons why we moved away from the inline style attribute in HTML in the first place. (Yes, we didn't left it for its limitations like pseudo classes and @media queries, they didn't even exist, we didn't add those new features because no one wanted to get back to those inline styling) So, while I don’t hate Tailwind, I just don’t see the clear advantages over Web Components or Styled Components in terms of readability, maintainability, and separation of concerns, while I do have important unanswered important concerns about using it... Yes, I've read the docs but never tried it out, I don't hate it, but I can't understand why I would choose it over other options. The fact of having a million classes in the middle of plain HTML makes them both unreadable for me. And No, I don't like huge CSS files either, or the classic approach of using them. But it is hard for me to see why tailwind is a better approach than working with Web Components, or React with Styled components. These two approaches allows me to not have to read presentational things in the middle of my html, and allow my html to be more clear and readable. I don't have to use CSS class names, it's easy to identify which CSS applies where, so, if you remove the component, you remove the CSS too, you don't end serving unused CSS rules. Each can have CSS not leaking to the global scope, and there is no risk on changing styles of another element... So, there is no hate for me, but it is very hard for me to see the benefits of tailwind over these two approaches, and I really dislike the idea of having to read html elements with huge styling rules cluttering my html files, and worse, having all of them in a single line makin it hard to understand all the applied styling. We left using style tag from HTML mostly for that reason, and not because of its current limitations (like not being able to use pseudo classes, media, etc) |
> The biggest issue I have with Tailwind is how it clutters the HTML
You're 100% clearly in the first group. Maybe I shouldn't have said "hate" in that group, just people that don't like it or see its benefits.
> Like Web Components
That's a nice solution, but in practice as of today and relatively speaking: nobody is using them.
> and Styled Components
Except the performance is a lot worse. And you still have to come up with names for every single div that needs a minimal one line style.
And both of these solutions end up with huge CSS files. Huge CSS files are worse than having larger HTML markup, because CSS is a blocking resource and HTML is not.
> I really value keeping HTML very short and readable by not mixing presentational styles directly in the markup
People used to say this about React, they preferred their HTML separate from their JavaScript, all nice and clean. I'm now 150% sure you're in the first group.
> Yes, I've read the docs but never tried it out, I don't hate it, but I can't understand why I would choose it over other options. The fact of having a million classes in the middle of plain HTML makes them both unreadable for me.
Alright, now you've recognized it.
> These two approaches allows me to not have to read presentational things in the middle of my html, and allow my html to be more clear and readable.
That's a non issue. There are extensions that will just hide classnames. You're just blending your mind looking for reasosn to justify your "I don't like it".
I promise the day you use it in a real life project where you're working with > 3 other people you will understand it's benefits, and how having "large class lists" is a non-issue and a totally acceptable trade off over the practical benefits it provides. Both on performance of the resulting CSS and maintainability over a large period of time. And think in the insane amount of discussions you'll avoid regarding if we're calling this div "styledDivWrapper" or "WraperContent" or "CardWrapper" or ".card__item--dark". Not an issue if you work alone, but when working with others this becomes a real annoyance that tailwind completely removes.
Tailwind is not for your, don't use it.
Tailwind is not for purists and architecture philosophers.
Tailwind is for pragmatic people, working on real life projects within teams where they have to ship and spend less time philosophizing on the purity and beauty of things.