3 ms·

> and BEM because it was difficult to scope css. I suspect this reflects the cultural problem that in many organizations no one really wants to create or stick

> and BEM because it was difficult to scope css. I suspect this reflects the cultural problem that in many organizations no one really wants to create or stick to a systematic design. Scoping CSS isn't trivial as a site grows large, but it's far from intractable. Tailwind's orientation on concrete details everywhere is the "just give up" solution -- stop trying to get the organization and culture to do work they don't want to do. EDIT: I'd also guess there's an element of poor feedback loops for most development tools. When people people talk about things like "I don't want to have to look up what every class means", they're speaking to one reality of code componentization across the multiple dimensions of styling/semantics/markup/logic in development environments that often can't support interactive, legible, and interconnective feedback as development is done. There are probably solutions to this but they're more involved and less well known or fungible than just collapsing styling/semantics/markup into a single dimension around a consistent constrained UI domain language you can add to your resume in a week tops. This is friendlier to the predominant "culture" for building front ends right now.

exceptione 2y ago
> 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
- 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?
crooked-v 2y ago
For me, it's always been much less of a technical thing, and much more that the material coming out of the product design part of the business is never actually consistent enough that you can have a single consistent CSS file drive the whole site.
- wwweston 2y ago
  Yeah -- that's a big part of what I mean with "stop trying to get the organization and culture to do work they don't want to do" or "just give up." I do think there are tooling shortcomings that could change required investments and therefore organizational outlooks, and that the Tailwind approach comes with some technical debts that could an alternative like that worth it. But it'd take a team with a good amount of free time, experience, and unusual levels of insight to produce such a thing. Probably some clout to get it off the ground. In the meanwhile, Tailwind represents a plausibly acceptable local maxima that coincides with a lot of other things about larger web dev practices and culture. And to be clear, mine is a descriptive assessment, not a normative one. Tailwind is functionally adaptive to the dysfunctions as well as the functions of the predominate business web dev culture, not an expression of worthy ideals.
meerita 2y ago
It's a bias to think the problem is people not knowing how to architect a good CSS solution. The reality is projects are maintained by multiple people over the course of its life. OOCSS only brings technical debt and constraints, and not to mention bloated CSS files. A good explanation why OCSS is bad https://www.fcss.club/manifesto https://www.fcss.club/manifesto and why functional CSS or atomic css is better in the short and long-term https://www.fcss.club/why https://www.fcss.club/why. Tailwind just brings more complexity.

exceptione 2y ago

> 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
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?

crooked-v 2y ago

For me, it's always been much less of a technical thing, and much more that the material coming out of the product design part of the business is never actually consistent enough that you can have a single consistent CSS file drive the whole site.

wwweston 2y ago
Yeah -- that's a big part of what I mean with "stop trying to get the organization and culture to do work they don't want to do" or "just give up." I do think there are tooling shortcomings that could change required investments and therefore organizational outlooks, and that the Tailwind approach comes with some technical debts that could an alternative like that worth it. But it'd take a team with a good amount of free time, experience, and unusual levels of insight to produce such a thing. Probably some clout to get it off the ground. In the meanwhile, Tailwind represents a plausibly acceptable local maxima that coincides with a lot of other things about larger web dev practices and culture. And to be clear, mine is a descriptive assessment, not a normative one. Tailwind is functionally adaptive to the dysfunctions as well as the functions of the predominate business web dev culture, not an expression of worthy ideals.

meerita 2y ago

It's a bias to think the problem is people not knowing how to architect a good CSS solution. The reality is projects are maintained by multiple people over the course of its life. OOCSS only brings technical debt and constraints, and not to mention bloated CSS files. A good explanation why OCSS is bad https://www.fcss.club/manifesto https://www.fcss.club/manifesto and why functional CSS or atomic css is better in the short and long-term https://www.fcss.club/why https://www.fcss.club/why. Tailwind just brings more complexity.