5 ms·

From daisyui.com: Tailwind CSS provides low-level utility classes, wich usually inlcude only one CSS rule. daisyUI classes are a combination of multiple CS

From daisyui.com: Tailwind CSS provides low-level utility classes, wich usually inlcude only one CSS rule. daisyUI classes are a combination of multiple CSS rule that are named semantically for each part of the UI. So, to put it simple, Tailwind re-implements css property-value pairs as classnames, whereas daisyui re-implements css classnames. It seems like the whole dance is to avoid class="btn" style="font-color: #3e3" So what is different from above is that a style override is now possible via class like class="btn font-color-3e3" (or whatever tailwind provides as builtin class). Are these layers of indirection worth it, and still needed with modern css? I remember we came to css frameworks and BEM because it was difficult to scope css.

wwweston 2y ago
> 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.
- 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.
notjustanymike 2y ago
It's not font-color 3e3, it's font-red-300. That's an important distinction, because the second one respects the design system your art team spent a lot of time establishing. By using their language you normalize the set of styles utilized in an application, instead of individually and repeatedly hard coding the hex values. Second off, tailwinds true power becomes way more obvious if you consider pseudo selectors like lg: and hover:.

wwweston 2y ago

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

notjustanymike 2y ago

It's not font-color 3e3, it's font-red-300. That's an important distinction, because the second one respects the design system your art team spent a lot of time establishing. By using their language you normalize the set of styles utilized in an application, instead of individually and repeatedly hard coding the hex values. Second off, tailwinds true power becomes way more obvious if you consider pseudo selectors like lg: and hover:.