except we generally use higher level abstractions now, like component based frameworks. If you’re writing raw html with tailwind and no library you’re doing it wrong and css is a better fit.
well written straight css ends up building it’s own tree of components. if you’re using react too you’re either only selecting a single component (inline styles but have to open two files) or writing good css (duplicating the component hierarchy in css).
tailwind is just the former but better since it encourages using a projectwide set of specific sizes/colors/breakpoints and small scope, the two actual problems with inline styles after organization and resuse, which react etc solves.
I cannot tell if you’re saying tailwind is taking away from useful abstractions or adding to them. I think it’s taking away from them. A whole bunch of class names in the page is opposite to what we were taught and there was a good reason for the lesson: content and presentation should be defined separately. This lends flexibility, readability and accessibility. Tailwind doesn’t help with anything but preventing a breakage in another component/page. To me the reason to value this trade off is that you don’t want devs to “have to care about css” which is a bad sign to begin with. It says “we think the way the web is built is bullshit, so let’s just try to work around that with the latest attempt to make it better”. The web is not bullshit. CSS is beautiful. Embrace the challenge. (Sorry I’m only halfway directing this rant at you)
I’m saying we weren’t taught when react was the way people wrote sites. if I was writing a site with pure html, css is great, especially modern css.
but if I’m already using react and their abstractions, opinions on that part aside, I’d personally rather lean on the react component as the unit of reuse. tailwind removes the abstraction that you don’t need, since many people in react tend towards one scoped css file per component with classes for each element anyway
at this point I’d be more inclined to say for many sites the api and data fetching things are the content and html+css is presentation. csszengarden is cool but I haven’t seen the html/css split help an end user, or really even me as a developer.
tailwind removes the abstraction that you don’t need, since many people in react tend towards one scoped css file per component with classes for each element anyway
What abstraction does it remove? In my view, it just adds slightly different abstractions. Instead of knowing an element has a clean block of rules with set meanings, you get a long (potentially grossly formatted/ordered) string of class names that mean the same thing as the CSS properties for the most part, but you’ve gotta learn a new set of aliases for them. If I am working on someone else’s component, one of these scenarios is way easier for me than the other. Even when I worked with TW for a while, I never could really remember a lot of those class names.
csszengarden is cool but I haven’t seen the html/css split help an end user, or really even me as a developer.
You may have never refactored or reskinned a site. I have several times. The hardest projects like that were when content and presentation were tightly coupled. Those felt like pulling teeth to get done. important! every time a dev buried a style tag somewhere deep in some (for all intents and purposes) unchangeable Java code… shudder When they were loosely coupled, it was fun and went much easier.
edit: respect for knowing csszengarden. That site honestly was the first time I learned this principal and saw it applied. I’ve themed several websites over the years so I’ve used the concept myself.
Realistically, there’s a bit of a nuance. Many modern web apps have different components that aren’t HTML. You don’t need HTML for a component. And those non-HTML components can provide the consistency they need. Sometimes, that’s consistency for how to get the data. Sometimes, that’s consistency for how to display the data. For displaying, each component basically has its own CSS, but it doesn’t need to. A CSS class isn’t required.
Tailwind isn’t meant to be a component system, It’s meant to supplement one. If you’re writing CSS’s components, it looks horrible. If you’re writing components at CSS that needs a foundation of best practices, it works pretty decent. They’re still consistency. They’re still components. They’re just not centered around HTML/CSS anymore. It doesn’t have to be.
Sematically, it is still worse HTML. Realistically, it’s often faster to iterate on, easier to avoid breakage: especially as the project becomes larger. Combine that with the code being more easily copied and pasted. It can be a tough combo to beat. It’s probably just a stepping stone to whatever’s next.
Many modern web apps have different components that aren’t HTML
What do you mean by this? Web Components?
I am not sure I understand the second paragraph either. I get that if you’re doing things well, TW class names can be applied in a non-insane way. Still rubs me the wrong way as a concept though.
![[ComiCSS] Benefits of Tailwind](https://files.catbox.moe/36lx9g.webp){kind=link}
Tailwind is like going back to in-line styles. If you add font tags you are back in the 2000’s
except we generally use higher level abstractions now, like component based frameworks. If you’re writing raw html with tailwind and no library you’re doing it wrong and css is a better fit.
well written straight css ends up building it’s own tree of components. if you’re using react too you’re either only selecting a single component (inline styles but have to open two files) or writing good css (duplicating the component hierarchy in css).
tailwind is just the former but better since it encourages using a projectwide set of specific sizes/colors/breakpoints and small scope, the two actual problems with inline styles after organization and resuse, which react etc solves.
I cannot tell if you’re saying tailwind is taking away from useful abstractions or adding to them. I think it’s taking away from them. A whole bunch of class names in the page is opposite to what we were taught and there was a good reason for the lesson: content and presentation should be defined separately. This lends flexibility, readability and accessibility. Tailwind doesn’t help with anything but preventing a breakage in another component/page. To me the reason to value this trade off is that you don’t want devs to “have to care about css” which is a bad sign to begin with. It says “we think the way the web is built is bullshit, so let’s just try to work around that with the latest attempt to make it better”. The web is not bullshit. CSS is beautiful. Embrace the challenge. (Sorry I’m only halfway directing this rant at you)
I’m saying we weren’t taught when react was the way people wrote sites. if I was writing a site with pure html, css is great, especially modern css.
but if I’m already using react and their abstractions, opinions on that part aside, I’d personally rather lean on the react component as the unit of reuse. tailwind removes the abstraction that you don’t need, since many people in react tend towards one scoped css file per component with classes for each element anyway
at this point I’d be more inclined to say for many sites the api and data fetching things are the content and html+css is presentation. csszengarden is cool but I haven’t seen the html/css split help an end user, or really even me as a developer.
What abstraction does it remove? In my view, it just adds slightly different abstractions. Instead of knowing an element has a clean block of rules with set meanings, you get a long (potentially grossly formatted/ordered) string of class names that mean the same thing as the CSS properties for the most part, but you’ve gotta learn a new set of aliases for them. If I am working on someone else’s component, one of these scenarios is way easier for me than the other. Even when I worked with TW for a while, I never could really remember a lot of those class names.
You may have never refactored or reskinned a site. I have several times. The hardest projects like that were when content and presentation were tightly coupled. Those felt like pulling teeth to get done.
important!every time a dev buried a style tag somewhere deep in some (for all intents and purposes) unchangeable Java code… shudder When they were loosely coupled, it was fun and went much easier.edit: respect for knowing csszengarden. That site honestly was the first time I learned this principal and saw it applied. I’ve themed several websites over the years so I’ve used the concept myself.
You’re not wrong.
Realistically, there’s a bit of a nuance. Many modern web apps have different components that aren’t HTML. You don’t need HTML for a component. And those non-HTML components can provide the consistency they need. Sometimes, that’s consistency for how to get the data. Sometimes, that’s consistency for how to display the data. For displaying, each component basically has its own CSS, but it doesn’t need to. A CSS class isn’t required.
Tailwind isn’t meant to be a component system, It’s meant to supplement one. If you’re writing CSS’s components, it looks horrible. If you’re writing components at CSS that needs a foundation of best practices, it works pretty decent. They’re still consistency. They’re still components. They’re just not centered around HTML/CSS anymore. It doesn’t have to be.
Sematically, it is still worse HTML. Realistically, it’s often faster to iterate on, easier to avoid breakage: especially as the project becomes larger. Combine that with the code being more easily copied and pasted. It can be a tough combo to beat. It’s probably just a stepping stone to whatever’s next.
What do you mean by this? Web Components?
I am not sure I understand the second paragraph either. I get that if you’re doing things well, TW class names can be applied in a non-insane way. Still rubs me the wrong way as a concept though.
imo there’s VERY little difference to a lot of tailwind and style=“…”. you gain a few minor abstractions, but you lose so much
Yep. The syntax is slightly cleaner to read probably, but that’s about it.