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.
> 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'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.
GloomyBoots|2 years ago
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.
Cyberdog|2 years ago
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.
unmole|2 years ago
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.
troupo|2 years ago
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).
You only have to realise that separation of concerns cuts both ways: https://twitter.com/simonswiss/status/1664736786671869952?s=... (accessible to non-logged-in users)
j45|2 years ago
brenainn|2 years ago
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.
joshellington|2 years ago
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.
necovek|2 years ago
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.
timeon|2 years ago