4 ms·

> Tailwind's orientation on concrete details everywhere is the "just give up" solution Yes, and that is why I am genuinely curious whether going the nuclear ap

> Tailwind's orientation on concrete details everywhere is the "just give up" solution Yes, and that is why I am genuinely curious whether going the nuclear approach is still needed, or that css variables, @scope and what-not of today solves the problems of the past. Because it seems that Tailwind introduces problems that CSS sought to resolve, and now DaisyUI seeks to resolve the problems of Tailwind. Are we now at a point that devs do not know enough about the basics and are mentally stuck on tools they do know? Or is it that the old problems still have not been solved?

wwweston 2y ago
Yes & yes. It seems to me really learning CSS has been something most devs who started doing anything else have long wanted to avoid. I suspect it just scratches different itches and feels more like configuration than programming. And of course once an abstraction layer becomes key in established development culture, the opportunities for reward are probably broader with the abstraction than with the layers underneath it. Not sure styling has coalesced around Tailwind or DaisyUI enough to lock that in, though. I'd guess css vars, @scope, etc do solve some problems. I'd also guess something equivalent to full native mixins would be needed to solve most technical expressive/organizational problems and I'm not sure css vars get there. Plus there's the various factors in org culture that tend to undervalue all kinds of areas of front-end design and engineering (which I'd guess largely boil down to a combination of the incentives towards conversion-oriented tinkering and bikeshedding pride among recognized product stakeholders).
- exceptione 2y ago
  > I'd also guess something equivalent to full native mixins would be needed to solve most technical expressive/organizational problems and I'm not sure css vars get there You said native, but could a CSS preprocessor in the meantime fill that gap? If @layer and @scope would fix the problems pre-BEM, I think we are done then. > Plus there's the various factors in org culture that tend to undervalue all kinds of areas of front-end design and engineering Yes, if it is people just don't want to reuse, but want to have a quick hack for something like <button class="class_6447823468"> then it is more a tool for an organization/skill problem I guess. I just don't see how you can reach and enforce a consistent, maintainable styling across a medium to large website with something like Tailwind. Do people trade quality, consistency and freedom for a limited set of design tokens that might be applied inconsistently? I have to admit I have not done much in css since a long time, and given the enthusiasm for Tailwind I wonder if my understanding is lacking.
  - kristiandupont 2y ago
    In my experience, after now something like 5 years of using Tailwind in projects large and small, it scales reasonably well. You just do what the authors suggest: encapsulate styling in components instead of CSS classes. Now, that isn't quite the panacea it can sound like. The standard components like buttons and dropdowns are solved quickly and then you have the unusual components that always show up here and there, which are more likely to stand out. But, that was my experience with BEM/Bootstrap/whatever before that as well.
  - agos 2y ago
    that css preprocessor would be CSS modules and yes it solves the scoping problem today
  - paradox460 2y ago
    Preprocessors have solved things fairly well for a while now https://pdx.su/blog/2023-07-26-tailwind-and-the-death-of-craftsmanship/ https://pdx.su/blog/2023-07-26-tailwind-and-the-death-of-cra... This article is coming up on two years old, and still holds true. You can just now do a lot of the things that required external tooling in plain css
    - wwweston 2y ago
      Just want to say thanks for this -- I hadn't seen it before, and it touches effectively on a number of practical criticisms I have of Tailwind plus some I hadn't articulated yet. And I'm really glad it brings the context of web craftsmanship into this, I think it's related. As I've argued elsewhere in-discussion, a fair portion of Tailwind's appeal probably comes from the way it fits with the "grain" of business web dev culture, which itself is driven by product management culture oriented around conversion metrics (often wielding iffy A/B testing) and rewards for bikeshedding. The benefits of craftsmanship or systematic design are less legible and so design direction and front-end tasks tend to be one-off screen-by-screen and pretty churn-y. Semantics are an afterthought and invisible to most stakeholders, attempts to systematize are often seen as irrelevant if not obstacles to business goals. Tailwind just gives up. Give the business and its agents what they want, get through your task list, and find somewhere else to care about the subtleties of quality.
seanwilson 2y ago
> Because it seems that Tailwind introduces problems that CSS sought to resolve > Are we now at a point that devs do not know enough about the basics and are mentally stuck on tools they do know? Or is it that the old problems still have not been solved? You should read all of https://tailwindcss.com/docs/styling-with-utility-classes https://tailwindcss.com/docs/styling-with-utility-classes. Experienced developers use Tailwind because it solves real problems with CSS that are hard to understand until you've worked on complex sites, with complex designs, and/or with large teams. People will often tar Tailwind users as people that don't understand CSS well when this isn't the case. Plain CSS is fine for simple designs and document based sites, but e.g. cascading styles, specificity, and the way styles are spread between files becomes a nightmare to grow and maintain later. CSS wasn't invented with the kinds of complex responsive UIs and designs we need to write now, so it's not a surprise the traditional way doesn't scale well. Ever worked on Java/OOP code with huge complex fragile inheritance trees spread across files where you can't figure out which piece of code is overriding something, or how to make your change without breaking something else? It's not unlike that, yet people will blindly defend the traditional CSS approach because the flaws aren't widely accepted yet.
- exceptione 2y ago
  I don't dismiss Tailwind, CSS had trouble with scoping styles. From there we got to BEM. Now CSS has grown to tackle that issue. So the question is whether Tailwind is now becoming an obsolete approach. Especially as DaisyUI tries to put yet another block on the Jenga tower.
  - seanwilson 2y ago
    > From there we got to BEM Problems/friction here is still: now I'm forced to give verbose names to all my divs, CSS is verbose, responsive CSS is very verbose, you can't easily compose the styles from different classes (like adding a shadow or text styling from elsewhere, where each was multiple lines of CSS), styling is split between the HTML and CSS files which slows down editing and debugging, it's hard to keep styling/spacing/sizing consistent unless you (verbosely) use variables everywhere. All of these add up to make writing and maintaining CSS a draining and frustrating experience, especially if you want to quickly iterate on a design where you're not quite sure yet how it should look. I'm not a user of DaisyUI but Tailwind still has a lot of pros over standard CSS and BEM. > to put yet another block on the Jenga tower. In a similar thought, why not write the styles directly on the HTML? Heavily restyling a site always requires modifying the HTML along with the CSS and adding divs that are only there for styling, so let's admit they're not separate and remove a layer of indirection and remove the extra verbosity BEM brings? BEM is mostly admitting that cascading and specificity are CSS features to avoid, so why stop there?

wwweston 2y ago

Yes & yes. It seems to me really learning CSS has been something most devs who started doing anything else have long wanted to avoid. I suspect it just scratches different itches and feels more like configuration than programming. And of course once an abstraction layer becomes key in established development culture, the opportunities for reward are probably broader with the abstraction than with the layers underneath it. Not sure styling has coalesced around Tailwind or DaisyUI enough to lock that in, though. I'd guess css vars, @scope, etc do solve some problems. I'd also guess something equivalent to full native mixins would be needed to solve most technical expressive/organizational problems and I'm not sure css vars get there. Plus there's the various factors in org culture that tend to undervalue all kinds of areas of front-end design and engineering (which I'd guess largely boil down to a combination of the incentives towards conversion-oriented tinkering and bikeshedding pride among recognized product stakeholders).

exceptione 2y ago
> I'd also guess something equivalent to full native mixins would be needed to solve most technical expressive/organizational problems and I'm not sure css vars get there You said native, but could a CSS preprocessor in the meantime fill that gap? If @layer and @scope would fix the problems pre-BEM, I think we are done then. > Plus there's the various factors in org culture that tend to undervalue all kinds of areas of front-end design and engineering Yes, if it is people just don't want to reuse, but want to have a quick hack for something like <button class="class_6447823468"> then it is more a tool for an organization/skill problem I guess. I just don't see how you can reach and enforce a consistent, maintainable styling across a medium to large website with something like Tailwind. Do people trade quality, consistency and freedom for a limited set of design tokens that might be applied inconsistently? I have to admit I have not done much in css since a long time, and given the enthusiasm for Tailwind I wonder if my understanding is lacking.
- kristiandupont 2y ago
  In my experience, after now something like 5 years of using Tailwind in projects large and small, it scales reasonably well. You just do what the authors suggest: encapsulate styling in components instead of CSS classes. Now, that isn't quite the panacea it can sound like. The standard components like buttons and dropdowns are solved quickly and then you have the unusual components that always show up here and there, which are more likely to stand out. But, that was my experience with BEM/Bootstrap/whatever before that as well.
- agos 2y ago
  that css preprocessor would be CSS modules and yes it solves the scoping problem today
- paradox460 2y ago
  Preprocessors have solved things fairly well for a while now https://pdx.su/blog/2023-07-26-tailwind-and-the-death-of-craftsmanship/ https://pdx.su/blog/2023-07-26-tailwind-and-the-death-of-cra... This article is coming up on two years old, and still holds true. You can just now do a lot of the things that required external tooling in plain css
  - wwweston 2y ago
    Just want to say thanks for this -- I hadn't seen it before, and it touches effectively on a number of practical criticisms I have of Tailwind plus some I hadn't articulated yet. And I'm really glad it brings the context of web craftsmanship into this, I think it's related. As I've argued elsewhere in-discussion, a fair portion of Tailwind's appeal probably comes from the way it fits with the "grain" of business web dev culture, which itself is driven by product management culture oriented around conversion metrics (often wielding iffy A/B testing) and rewards for bikeshedding. The benefits of craftsmanship or systematic design are less legible and so design direction and front-end tasks tend to be one-off screen-by-screen and pretty churn-y. Semantics are an afterthought and invisible to most stakeholders, attempts to systematize are often seen as irrelevant if not obstacles to business goals. Tailwind just gives up. Give the business and its agents what they want, get through your task list, and find somewhere else to care about the subtleties of quality.

seanwilson 2y ago

> Because it seems that Tailwind introduces problems that CSS sought to resolve > Are we now at a point that devs do not know enough about the basics and are mentally stuck on tools they do know? Or is it that the old problems still have not been solved? You should read all of https://tailwindcss.com/docs/styling-with-utility-classes https://tailwindcss.com/docs/styling-with-utility-classes. Experienced developers use Tailwind because it solves real problems with CSS that are hard to understand until you've worked on complex sites, with complex designs, and/or with large teams. People will often tar Tailwind users as people that don't understand CSS well when this isn't the case. Plain CSS is fine for simple designs and document based sites, but e.g. cascading styles, specificity, and the way styles are spread between files becomes a nightmare to grow and maintain later. CSS wasn't invented with the kinds of complex responsive UIs and designs we need to write now, so it's not a surprise the traditional way doesn't scale well. Ever worked on Java/OOP code with huge complex fragile inheritance trees spread across files where you can't figure out which piece of code is overriding something, or how to make your change without breaking something else? It's not unlike that, yet people will blindly defend the traditional CSS approach because the flaws aren't widely accepted yet.

exceptione 2y ago
I don't dismiss Tailwind, CSS had trouble with scoping styles. From there we got to BEM. Now CSS has grown to tackle that issue. So the question is whether Tailwind is now becoming an obsolete approach. Especially as DaisyUI tries to put yet another block on the Jenga tower.
- seanwilson 2y ago
  > From there we got to BEM Problems/friction here is still: now I'm forced to give verbose names to all my divs, CSS is verbose, responsive CSS is very verbose, you can't easily compose the styles from different classes (like adding a shadow or text styling from elsewhere, where each was multiple lines of CSS), styling is split between the HTML and CSS files which slows down editing and debugging, it's hard to keep styling/spacing/sizing consistent unless you (verbosely) use variables everywhere. All of these add up to make writing and maintaining CSS a draining and frustrating experience, especially if you want to quickly iterate on a design where you're not quite sure yet how it should look. I'm not a user of DaisyUI but Tailwind still has a lot of pros over standard CSS and BEM. > to put yet another block on the Jenga tower. In a similar thought, why not write the styles directly on the HTML? Heavily restyling a site always requires modifying the HTML along with the CSS and adding divs that are only there for styling, so let's admit they're not separate and remove a layer of indirection and remove the extra verbosity BEM brings? BEM is mostly admitting that cascading and specificity are CSS features to avoid, so why stop there?