The separation of HTML, CSS, and JS doesn't make sense when you're building applications instead of very basic documents. Style, content, and behavior are all intertwined: say you have a collapsible navbar; does the toggle button (HTML) have any meaning at all separate from its behavior (JS); does a "navbar" mean anything at all without its associated style (CSS)? <nav> might have some semantic meaning, but really it's just a div with a list of anchors until you turn it into a navbar with CSS.
Centralizing these nominally separate things that aren't actually separate in modern web applications makes sense. It doesn't have to be Tailwind, but Tailwind works well and is easy enough to understand in a second.
The biggest downsides are that until you get the hang of it you have to look up class names a lot (although they are fairly consistent), it requires knowledge of CSS already so isn't really beginner-friendly, and it can be easy to get lazy and cause a similarly inconsistent and chaotic style soup--am I using px-2 for these kinds of things or px-4--as you might with inline styles (but Tailwind provides nice facilities to avoid this by configuring your theme and adding your own component classes--the latter might be best used sparingly and avoided through better reuse of HTML).
I think most Tailwind users are using it in JS. It works just as well if you're doing everything in HTML, like with htmx or something similar, which is nice for me.
Tailwind and similar frameworks divorce the concept of a semantic web we as a society have been building towards for decades. It works against the idea that you mark up areas of your code with descriptive labels like "header" and then put the code describing how the header should appear in another easily-editable file, and instead encourages you to use generic style descriptors to describe how the header area of your site should appear in the HTML itself. This is how we built web sites before CSS was widely adopted and, though it was "easier" to do things like `<p color="#999999">` in HTML 3 rather than separate the code from the appearance markup, it was generally considered to be a really bad idea. But Tailwind and the like drag us back in that direction.
> concept of a semantic web we as a society have been building towards for decades
This makes no sense to me. Semantic Web was a mostly failed attempt at making web pages readable to machines. Your actual complaint seems to be Separation of Concerns. Nevertheless, that is something that is only of interest to a subset of developers. Society doesn't care.
The person you're responding to wrote about "a semantic web", not the Semantic Web. Ordinary class names, done properly, add semantics to Web pages, and this is what went on for years without Web developers necessarily trying very hard or even knowing that's what they doing—until people started abusing the medium and writing CSS compilers/automanglers and then, later, stuff like Tailwind.
Did developers adopt the ideas? Mostly no. But were they actually still doing it, despite not having bought in to the philosophy? Yes.
> Ordinary class names, done properly, add semantics to Web pages
CSS classes added semantics, really? Assuming that is true, who exactly was this visible to? Definitely not any reasonable definition of society as the GP claimed.
"No adoption" is certainly superlative. That existing sites rarely go through top-down redesigns is part of the slow adoption, though. Are there really designers who have been exposed to the idea of semantic design and yet are still making designs with <div> soup instead of <main>, <header>, etc? I would certainly hope not.
> Tailwind and similar frameworks divorce the concept of a semantic web we as a society have been building towards for decades.
We definitely haven't been building any sort of "semantic web", ever.
> It works against the idea that you mark up areas of your code with descriptive labels like "header"
You mean `.hero-text__sticky-container--secondary` and such. This neither is semantic nor decouples styles from the document.
> rather than separate the code from the appearance markup, it was generally considered to be a really bad idea.
People pretend that it is a bad idea. In reality "separate code from appearance" was dead on arrival. You'd be hard-pressed to find sites from any era of the web that didn't couple code and presentation (even if the two were in different files).
I guess it depends on what we mean by "arrived." Are the technologies present and can they be used well? I think so. Are they as widely used as they should be? Of course not. Is there room for improvement? Always.
When the semantic web was the new thing, it was similar to the hype cycles around new technologies or very early applications of it (nft, etc).
A contextual, connected knowledge base and digital consciousness never really came according to the semantic web specs in terms of implementation and adoption and use by the masses.
Still, maybe that middleman work is something LLMs could help with.
I've been using it over the last 6 months or so. I don't have a lot of web experience. Web UIs I've worked on before have been very barebones styling-wise. For this latest one I wanted to make it prettier. I hated writing CSS so I thought I'd try tailwind.
I've fallen into what I assume is a common trap with tailwind: I still know very little CSS and I've devoted headspace to remembering tailwind class names. Getting tailwind to do what I want, mainly with layouts, is hard because I don't understand all the underlying CSS and core principles. I wish I had instead knuckled down and learnt good CSS skills.
I think picking tailwind because you don't like CSS or you lack experience with it is a mistake. If you have experience and already have the mental image of what you want things to look like and how to achieve it, the utility classes probably make that quicker and easier to do.
Regarding the ugliness, I thought I was being clever by using `@apply` to make reusable components. And then I was surprised to read https://tailwindcss.com/docs/reusing-styles#avoiding-prematu... and it's preferred to use long lists of class names. Like multi-line editing is actually recommended as an ideal way to deal with duplication. I don't understand what's so bad about having to go find the class name in another file, and maybe make a new one or tack on some additional classes in the HTML. But again, I lack so much experience in this area and I'm working on relatively small projects so I don't have the same requirements and challenges as other users.
Having written production CSS for 15+ years across everything from global e-commerce Magento sites to new age Next.js RSC projects, I like Tailwind (after much conflict). The piece I feel like is missing in most explanations of why it “works” is the flow you can achieve with it. It’s a distinct difference. The idea of essentially hammer utility classes, all provided in one package, provides a novel experience that does stick.
As many will say, it’s biased towards component-based code, which I agree is where it shines the brightest. But even in my legacy Rails projects, I can’t shake the want for more utility/generalized classes.
It's basically in how you interpret "semantic naming". For some, they think in the "large font" or "large margin" as "semantic". Others only accept "header" as semantic.
There is undeniable coupling between CSS and HTML (and JS) for web apps. How willing are you to refactor those "header" CSS styles to maintain more semantic meaning is probably why you'd be on one side of the fence or other.
Tailwind is a well-designed shorthand system for CSS styles so it's reasonably easy to learn and then quick to type out and compact in the HTML file.
Tailwind is a pretty leaky abstraction too (thick border class will have a mention of "px" in it or positional specifiers like "bottom" maybe shortened to "b"), so it will feel really close to writing pure CSS styles to some.
In theory, you could also combine the two: have a class "header" and then define that in terms of Tailscale CSS classes, but once you do that, it really drives the question of "why use Tailwind?" home.
Centralizing these nominally separate things that aren't actually separate in modern web applications makes sense. It doesn't have to be Tailwind, but Tailwind works well and is easy enough to understand in a second.
The biggest downsides are that until you get the hang of it you have to look up class names a lot (although they are fairly consistent), it requires knowledge of CSS already so isn't really beginner-friendly, and it can be easy to get lazy and cause a similarly inconsistent and chaotic style soup--am I using px-2 for these kinds of things or px-4--as you might with inline styles (but Tailwind provides nice facilities to avoid this by configuring your theme and adding your own component classes--the latter might be best used sparingly and avoided through better reuse of HTML).
I think most Tailwind users are using it in JS. It works just as well if you're doing everything in HTML, like with htmx or something similar, which is nice for me.