you're unfairly conflating things and putting the blame for a lack of care or understanding on tailwind vs on the dev themselves. nothing about tailwind forces you to build inaccessible or "div soup" apps
can tailwind be used poorly? absolutely. but that's true of any tool
i've been writing CSS for ~20 years and am quite capable with it, having used CSS, Less, SASS/SCSS, Stylus, PostCSS etc. the reason i have settled on Tailwind for the last few years is precisely because it enables me to build more robust application styling.
tailwind frees you from having to spend excessive time building abstractions of styles/classes that will invariably change. placing the styles directly into the markup that is affected by it reduces cognitive load, prevents excessively loose selectors affecting styles unintentionally and really aids in debugging. jumping into codebases with bespoke css frameworks is always more complex and fragile than a tailwind codebase for anything but the most simple sites/apps
add to that the ability to have consistent type, color and sizing scales, reduced bundle sizes, consistency for any developer who knows tailwind and a very robust ecosystem (and thus llms are very familiar with it) and tailwind is a really excellent choice for a lot of teams
tailwind is like most tools; it can be used well or poorly depending on who is using it
If a tool’s design makes it easy to cut myself, the response is not “people have been cutting themselves for years”.
There is such a thing as the ergonomics of the tool. Yes div soup has been around a long time. But also yes, Tailwind makes the wrong approach the easy one.
It’s ergonomics encourage adding div elements to support styles. It’s the core design loop.
You’re conflating “forces to” and “ergonomically encouraged”.
I’ve also been writing CSS professionally for nearly 20 years and am a big fan of tailwind.
The ergonomics in my day to day work are quite nice. To me, the better boundary of abstraction shifted to components, rather than the html/css/js “separation of concerns” that some of the older folks still like to parrot.
However, take a look at the markup and styling for the https://maps.apple.com/ web property.
I can’t deny that it’s quite beautiful and easy to holistically understand. Especially when it comes to the responsive styling—which is when I tend to find tailwind most awkward.
It’s my favorite example of “traditional” CSS structure in recent memory that has given me some pause when it comes to Tailwind.
> can tailwind be used poorly? absolutely. but that's true of any tool
Can tailwind be a useful CSS framework? Absolutely, but that can be said of any of them.
Which is precisely why it makes sense to point out it's unique flaws, so that people can make an informed decision as to what works best for them.
If you have some unique feature to tailwind that you think makes it better than the rest, you should share that.
Everything you have listed is also accomplished by all the other CSS frameworks, so it almost sounds like tailwind is simply the main one you have experience with.
I’ve mentioned this before here, but originally I was against Tailwind because it breaks the Cascading part of CSS, however I think a lot of websites lately work better with “locally scoped” styles as there are just so many different components that many things just dont need to follow a global style sheet. So now I usually reach for tailwind first, unless is a relatively simple vanilla html site
> nothing about tailwind forces you to build inaccessible or "div soup" apps
https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha...
So what if it does not "force" you?
> i've been writing CSS for ~20 years and am quite capable with it, having used CSS, Less, SASS/SCSS, Stylus, PostCSS etc. the reason i have settled on Tailwind for the last few years is precisely because it enables me to build more robust application styling.
I think herein lies at least part of the problem of the web these days: Most websites don't need to be applications, and are needlessly made to be applications, often even SPAs instead of simply being mostly informational pages, in turn putting different requirements for styling onto the project.
> [...] jumping into codebases with bespoke css frameworks is always more complex and fragile than a tailwind codebase for anything but the most simple sites/apps
There is no need for frameworks. Well structured and scoped CSS can handle it all.
> add to that the ability to have consistent type, color and sizing scales, reduced bundle sizes, consistency for any developer who knows tailwind
What if not that does CSS already offer? I don't see how normal CSS does not already do that. No additional thingamabob needed.
> very robust ecosystem (and thus llms are very familiar with it) and tailwind is a really excellent choice for a lot of teams
Tons of ready-made stylesheets out there to use for teams. What more of an "ecosystem" do I need to style a web page? Why do I need an ecosystem? Is it not rather a tailwind self-induced need?
Can you provide an example of well written components that use Tailwind? Genuinely curious to see what that looks like.
> nothing about tailwind forces you to build inaccessible or "div soup" apps
Totally agree. I feel like this was more a by product of React. Not that React forced this either, but it felt like the rise in both went hand in hand for some reason.
While I think it's true that none of the current top FE technologies force the div soup, they don't discourage it either. It would be nice if what ever FE technologies catch on next did try to encourage better practices around things like accessibility. Make the path of least semantic HTML the path of least resistance and allow people to fall into the pit of success, ya know?
> you're unfairly conflating things and putting the blame for a lack of care or understanding on tailwind vs on the dev themselves. nothing about tailwind forces you to build inaccessible or "div soup" apps
+1
Proclaiming professional advice on the internet should compel you to bother using proper caps and punctuation. To your point - you are addressing the symptoms of bad understanding of CSS and it's relationship to the DOM. While tailwinds is a useful tool, it's not particularly special.
> tailwind frees you from having to spend excessive time building abstractions of styles/classes that will invariably change.
Abstractions like a hero image, a menu, a headline? Sure, it's easy to overthink things but most of the time, it's not that complex.
> placing the styles directly into the markup that is affected by it reduces cognitive load, prevents excessively loose selectors
In my opinion, it's the opposite. Besides the obvious violation of DRY and the separation of concerns, inline CSS can't be cached and it creates a lot of noise when using dev tools for debugging. It actually increases cognitive load because you have to account for CSS in two different locations.
Lots of people use Tailwind because they don't want to deal with the cascade, usually because they never learned it properly. Sure, back in the day, the web platform didn't provide much built-in support for addressing side effects of the cascade, but now we have @layer and @scope to control the cascade.
Tailwind uses a remnant of '90s web development (inline CSS) and built an entire framework around it. I get why it appeals to some people: it lets you use CSS while not requiring an understanding of how CSS works, beyond its most basic concepts.