This is an okay stance to take & on the other end I can agree that CSS isn’t hard & don’t want to memorize a billion classname conventions, but what grinds my gears is when a tech lead or back-end team has mandated it on a front-end team that would prefer to not have that decision made for them—as can be said about most tools put on teams by folks not on those teams.
To me, if I want something that follows a system, the variables in Open Props covers what I need to have a consistent layer that a team can use—which is just CSS variables with a standardlized naming scheme other Open Prop modules can use. It is lighter weight, doesn’t need a compile step to be lean, & lets you structure your CSS or your HTML as you want without classname soup.
May not hard to write, but certainly it is hard to maintain. CSS makes it SO EASY to make a mess. In no time you’ll be facing selector specificity hell. If you have a team with juniors or just some backend folks trying to do some UI, that’s very common.
“But what about BEM?”. I like BEM! But, again it’s an extra step and another thing to learn (and you’re choosing not to deal with CSS specificiy to avoid its pitfalls).
IME, the BEM components I wrote were more effective and portable the smaller they were. I ended up with things like text text--small text--italic, which were basically in-house versions of Tailwind (before I knew what it was).
You can use utility classes & Open Prop names & still not use exclusively utility classes. No one has said Tailwind can’t be used for utility when needed, but in practice I see almost all name go away. There is nothing to select on that works for testing, or scraping, or filter lists.
Having a system is difficult since you have to make it stringly-typed one way or another, but that doesn’t discount the semantics or considering the balance needed. Often the UI & its architecture are low-priority or an afterthought since matching the design as quickly as possible tends to trump anything resembling maintainability & the same can happen in any code base if no standards are put in place & spaghetti is allowed to pass review.
It really is just the same old tired arguments on both sides tho really here. This isn’t the first time I have seen them & that post doesn’t really convince me given it has an agenda & some of the design choices seem intentionally obtuse without use of “modern” CSS from like the last 4–5 years.
but what grinds my gears is when a tech lead or back-end team has mandated it on a front-end team that would prefer to not have that decision made for them
Is this something that happened to you? Why would the back-end team decide on what technology the front-end team should use?
On multiple occasions have I seen a CTO, tech lead, or back-end team choose the stack for the front-end either before it was even started or purely based on a some proof-of-concept the back-end devs built & did not want the stack to change… just that it was entirely rewritten/refactored.
It raises the question that maybe the abstractions that were adopted by CSS are not the right ones in the long term, as other solutions are more team-friendly, easier to reason about.
Separation of presentation and content makes a lot of sense for a document format, and has been widely successful in that segment (think LaTex).
But for how the web is used today (think landing websites or webapps), the presentation is often part of the content. So the classic “Zen garden” model of CSS falls apart.
I’m in the same boat. I was appalled by it the first time I saw it.
But it fits my backend brain and makes building things so much easier. I like it in spite of myself. I’ve just never been able to bend my brain to automatically think in terms of the cascade, and reducing that to utilities makes it so much more workable for me, and lets me try things out faster. I’m excited about this release.
I am happy that you got a decent website up with Tailwind. I’m sad that you had a hard time with CSS and the conclusion you reached was that you were the one that sucked.
I forced myself to have a pet project using tailwind a few years ago. I hated Tailwind’s concept, but so many people appreciated so I had to try. I suggest to give a try even if it’s against your believes. It has pros and cons.
I’m also not convinced anymore about having a purely semantic HTML tree and only using CSS stylesheets for presentation, it takes time and no one cares. It makes cool demos like CSS Zen Garden, but most of the time the HTML and the CSS are tightly coupled anyway.
The irony of the CSS Zen Garden is that it used the name of a non-dualistic religion to propound a dualism of semantic content and its presentation. A lot of people, myself included, tried to build real-world websites this way. It did not work very well.
I share a similar experience. Initially skeptical (and dubious about the concept of property more or less equal to class), I’m now convinced by their approach.
I still enjoy pure CSS for minimal web pages / web apps, but Tailwind is my tool for more complex one.
It’s interesting that CSS has always been sorta bad for most people and the Tailwind approach of utility classes has always been possible but it took this long for it to come about.
To me Tailwind is just a product of how web apps are being built today. Back in the day (mid 2000s) frontend devs were required to be good at CSS, know some JS and a bit about design. Most of their tools were visual apps, lots of them came from design backgrounds. Now many frontend devs are “pure” programmers and have to learn about CLI tooling, type systems, design patterns, APIs, networking, etc. They have no time or interest to write CSS by hand.
Tailwind is a tool for this era. Not that CSS has ever been a very maintainable proposition but it’s gotten better to a point where one could probably hand-write styles in a composable way (with layers, inherit, etc). But Tailwind throws the baby out with the bathwater and makes learning CSS a non-priority. There’s less of an audience for modern CSS as well with most frontend programmers using mainly JS.
It creates an interesting diglossia, the Koine Greek of the Web. I don’t remember the last time I spoke with a web programmer about some new feature in CSS they were eager to try, it has almost become a low-level compilation target.
Tailwind is the only way I have been able to learn CSS. They are not hiding the CSS. They merely provide a way to compose it that works.
The fundamental problem of CSS is that the only efficient composition mechanism are selectors, which have spooky at-a-distance effects or… The class name array in the html.
Should we be able to do the composition in CSS (ancient @apply or hopefully at some point functions and mixins if the WG can get their way to it), then we would be able to get there differently.
I really need to write a “what I want from CSS from a static/backend pov” blog post.
I find your overall comment interesting, but this stood out to me:
I don’t remember the last time I spoke with a web programmer about some new feature in CSS they were eager to try, it has almost become a low-level compilation target.
because I do remember a recent conversation of that nature, for the first time in quite a while. It was about container queries:
There’s a curious virtuous cycle going on too where Tailwind drives innovation in CSS that is eventually generalized and implemented in browsers, at which point Tailwind rewrites their compilation code to use the new feature underneath. But it does not cause people to ditch Tailwind, as it’s probably on to the next innovation.
I think that happened with layers, though I could be mistaken.
Is it possible to use Tailwind without a build system of any kind? I see some utility in using it to make simple websites, but to keep them simple, I would prefer just to have html/css.
IMO the killer feature of Tailwind is how it effectively removes the cascading nature of CSS. For developers that actually understand CSS, this is frustrating. For the average full-stack developer that bounces between front-end, back-end, and infrastructure on a daily basis, it is a godsend.
This is especially true when you have multiple siloed teams all contributing to a shared monolith. Tailwind acts as a layer of insulation preventing global style regressions from impacting users.
People are rightly hard on tailwind.
And yet… for someone who sucks at front end responsive design I can’t deny it didn’t take me long to get a decent website up and running.
IME, the critics of Tailwind CSS are often CSS experts. So to them, “CSS isn’t hard”. The Tailwind abstractions just seem an extra step to them.
To me, though, they’re very useful and portable.
This is an okay stance to take & on the other end I can agree that CSS isn’t hard & don’t want to memorize a billion classname conventions, but what grinds my gears is when a tech lead or back-end team has mandated it on a front-end team that would prefer to not have that decision made for them—as can be said about most tools put on teams by folks not on those teams.
To me, if I want something that follows a system, the variables in Open Props covers what I need to have a consistent layer that a team can use—which is just CSS variables with a standardlized naming scheme other Open Prop modules can use. It is lighter weight, doesn’t need a compile step to be lean, & lets you structure your CSS or your HTML as you want without classname soup.
May not hard to write, but certainly it is hard to maintain. CSS makes it SO EASY to make a mess. In no time you’ll be facing selector specificity hell. If you have a team with juniors or just some backend folks trying to do some UI, that’s very common.
“But what about BEM?”. I like BEM! But, again it’s an extra step and another thing to learn (and you’re choosing not to deal with CSS specificiy to avoid its pitfalls).
IME, the BEM components I wrote were more effective and portable the smaller they were. I ended up with things like
text text--small text--italic, which were basically in-house versions of Tailwind (before I knew what it was).So, to paraphrase Adam, I rather have static CSS and change HTML than the reverse.
You can use utility classes & Open Prop names & still not use exclusively utility classes. No one has said Tailwind can’t be used for utility when needed, but in practice I see almost all name go away. There is nothing to select on that works for testing, or scraping, or filter lists.
Having a system is difficult since you have to make it stringly-typed one way or another, but that doesn’t discount the semantics or considering the balance needed. Often the UI & its architecture are low-priority or an afterthought since matching the design as quickly as possible tends to trump anything resembling maintainability & the same can happen in any code base if no standards are put in place & spaghetti is allowed to pass review.
It really is just the same old tired arguments on both sides tho really here. This isn’t the first time I have seen them & that post doesn’t really convince me given it has an agenda & some of the design choices seem intentionally obtuse without use of “modern” CSS from like the last 4–5 years.
Is this something that happened to you? Why would the back-end team decide on what technology the front-end team should use?
On multiple occasions have I seen a CTO, tech lead, or back-end team choose the stack for the front-end either before it was even started or purely based on a some proof-of-concept the back-end devs built & did not want the stack to change… just that it was entirely rewritten/refactored.
It raises the question that maybe the abstractions that were adopted by CSS are not the right ones in the long term, as other solutions are more team-friendly, easier to reason about.
I find the original tailwind blog post really enlightening: https://adamwathan.me/css-utility-classes-and-separation-of-concerns/
Separation of presentation and content makes a lot of sense for a document format, and has been widely successful in that segment (think LaTex). But for how the web is used today (think landing websites or webapps), the presentation is often part of the content. So the classic “Zen garden” model of CSS falls apart.
I’m in the same boat. I was appalled by it the first time I saw it.
But it fits my backend brain and makes building things so much easier. I like it in spite of myself. I’ve just never been able to bend my brain to automatically think in terms of the cascade, and reducing that to utilities makes it so much more workable for me, and lets me try things out faster. I’m excited about this release.
I am happy that you got a decent website up with Tailwind. I’m sad that you had a hard time with CSS and the conclusion you reached was that you were the one that sucked.
I really can’t be bothered to learn CSS or deal with “web standards”.
I forced myself to have a pet project using tailwind a few years ago. I hated Tailwind’s concept, but so many people appreciated so I had to try. I suggest to give a try even if it’s against your believes. It has pros and cons.
I’m also not convinced anymore about having a purely semantic HTML tree and only using CSS stylesheets for presentation, it takes time and no one cares. It makes cool demos like CSS Zen Garden, but most of the time the HTML and the CSS are tightly coupled anyway.
The irony of the CSS Zen Garden is that it used the name of a non-dualistic religion to propound a dualism of semantic content and its presentation. A lot of people, myself included, tried to build real-world websites this way. It did not work very well.
I share a similar experience. Initially skeptical (and dubious about the concept of property more or less equal to class), I’m now convinced by their approach.
I still enjoy pure CSS for minimal web pages / web apps, but Tailwind is my tool for more complex one.
It’s interesting that CSS has always been sorta bad for most people and the Tailwind approach of utility classes has always been possible but it took this long for it to come about.
To me Tailwind is just a product of how web apps are being built today. Back in the day (mid 2000s) frontend devs were required to be good at CSS, know some JS and a bit about design. Most of their tools were visual apps, lots of them came from design backgrounds. Now many frontend devs are “pure” programmers and have to learn about CLI tooling, type systems, design patterns, APIs, networking, etc. They have no time or interest to write CSS by hand.
Tailwind is a tool for this era. Not that CSS has ever been a very maintainable proposition but it’s gotten better to a point where one could probably hand-write styles in a composable way (with layers, inherit, etc). But Tailwind throws the baby out with the bathwater and makes learning CSS a non-priority. There’s less of an audience for modern CSS as well with most frontend programmers using mainly JS.
It creates an interesting diglossia, the Koine Greek of the Web. I don’t remember the last time I spoke with a web programmer about some new feature in CSS they were eager to try, it has almost become a low-level compilation target.
Something i would add.
Tailwind is the only way I have been able to learn CSS. They are not hiding the CSS. They merely provide a way to compose it that works.
The fundamental problem of CSS is that the only efficient composition mechanism are selectors, which have spooky at-a-distance effects or… The class name array in the html.
Should we be able to do the composition in CSS (ancient
@applyor hopefully at some point functions and mixins if the WG can get their way to it), then we would be able to get there differently.I really need to write a “what I want from CSS from a static/backend pov” blog post.
I find your overall comment interesting, but this stood out to me:
because I do remember a recent conversation of that nature, for the first time in quite a while. It was about container queries:
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_containment/Container_queries
and the first thing I did at the end of that conversation was go see if it was coming to tailwind. (There was a plugin… https://github.com/tailwindlabs/tailwindcss-container-queries and IIRC it was on its way upstream for v4.)
There’s a curious virtuous cycle going on too where Tailwind drives innovation in CSS that is eventually generalized and implemented in browsers, at which point Tailwind rewrites their compilation code to use the new feature underneath. But it does not cause people to ditch Tailwind, as it’s probably on to the next innovation.
I think that happened with layers, though I could be mistaken.
Is it possible to use Tailwind without a build system of any kind? I see some utility in using it to make simple websites, but to keep them simple, I would prefer just to have html/css.
I’ve not used tailwind, but https://tachyons.io/ this way (I guess tachyons is like a lightweight tailwind)
IMO the killer feature of Tailwind is how it effectively removes the cascading nature of CSS. For developers that actually understand CSS, this is frustrating. For the average full-stack developer that bounces between front-end, back-end, and infrastructure on a daily basis, it is a godsend.
This is especially true when you have multiple siloed teams all contributing to a shared monolith. Tailwind acts as a layer of insulation preventing global style regressions from impacting users.