6 ms·

I'm surprised that a lot of the comments seem to be missing the reason that this project exists. In many tailwind projects, you inevitably end up wanting to st

by qq99 1y ago

I'm surprised that a lot of the comments seem to be missing the reason that this project exists. In many tailwind projects, you inevitably end up wanting to standardize how a button looks, how a field looks, etc., rather than copy+paste the same 20+ tailwind classes that you need to implement a nice looking button in tailwind. Can you just apply it to `button { @apply flex items-center blahblahblah; }` in app.css? Of course you can. Or you can use the btn from DaisyUI. I think DaisyUI is just a shortcut for many common UI components that you will inevitably want to build out and that you will necessarily eventually standardize in any app that grows large enough. How does it differ from bootstrap? Well, you can continue to use tailwind for everything else that DaisyUI has not implemented. It's just an additive layer to tailwind. The project is at its core just a shortcut for common UI components. As a user, my criticism is that many of the DaisyUI components seem to be lacking good contrast, so some just don't seem to be usable. The theming situation is really interesting and quite cool to use, but if you look at the example page, it just feels hard to read. I can't really find a light and dark default theme that look good to me (re: contrast and brightness). I think the color hooks might just not be there but I didn't dig far enough in. For me, I've found a lot of value in being able to easily copy+paste parts of DaisyUI source code, e.g., a particular widget and modifying it to fit my design system, rather than use it in its entirety.

Calavar 1y ago
> In many tailwind projects, you inevitably end up wanting to standardize how a button looks, how a field looks, etc., rather than copy+paste the same 20+ tailwind classes that you need to implement a nice looking button in tailwind. CSS classes already support this natively. The whole point of CSS was move up a level of abstraction, so you could collect related styles into a class and reference that class everywhere you need that same grouping of styles instead of copy/pasting your HTML2 attribute-based styles all over the place. But then we got Tailwind, which uses CSS classes to emulate the pre-CSS behavior of specifying styles at a hyperfine granularity everywhere. And now we get DaisyUI, which emulates class based styling on top of a toolkit that emulates attribute based styling on top of the class based system of CSS. After while we have to admit that this tech stack contortion is the result of picking a tool because of familiarity and not because it is the best fit for the problem.
- qq99 1y ago
  Just because you have Tailwind in your codebase doesn't mean you can _only_ use Tailwind. I often use a mixture of both when it makes sense. The Tailwind classes are often terser. Tailwind is not great for all things. > which emulates class based styling IMO, what DaisyUI does is how you are meant to be using Tailwind. You aren't supposed to use _only_ TailwindCSS classes in HTML directly (although you can). It's faster for prototyping, then once the prototype solidifies and becomes a pattern, you can extract your long tailwind string into a nice utility class. It happens to use things like `@apply gap-2` internally in its src, so that if you want to override "how large the gaps are" in Tailwind, Daisy will also inherit that override.
- jarjoura 1y ago
  Yes, Tailwind's CSS reminds me of the same unoptimized HTML tag soup that editors of the 2000s era web used to spit out. Tailwind is created by designers for designers. It's perfect for how designers think about layout and works well for them in a world with strict design specs. Unfortunately, it's also incredibly bespoke and since it's found in most recent well designed templates, engineers must also learn how to work with it. Something 5 years ago that would have died from its own complexity weighing it down for the new shiney, is now kept alive by the ease at which AI can keep it going.
- alexchamberlain 1y ago
  The first thought that came to my mind reading the DaisyUI website was "Is this an April Fool's joke?". I wouldn't normally post something like that, as it's entirely unfair to the hard work and dedication that someone has put into this. However, I think it captures my surprise by how smack on the nose this is in terms of the spiral of tech abstractions - this is exactly what CSS was designed to solve, and things like tailwind appear to be leading to people forgetting that.
  - jacobsimon 1y ago
    Had the same initial reaction - have we come full circle to Bootstrap 20 years later? But after playing around with their theme builder[1], I think there's real value here - you can quickly spin up a custom-ish set of Tailwind components. I'd rather it output an actual component library though more like shadcn. [1] https://daisyui.com/theme-generator https://daisyui.com/theme-generator
slightwinder 1y ago
> In many tailwind projects, you inevitably end up wanting to standardize how a button looks, how a field looks, etc., rather than copy+paste the same 20+ tailwind classes that you need to implement a nice looking button in tailwind. Isn't this called classes and Ids in CSS? Is Tailwind just CSS on top of CSS?
- qq99 1y ago
  Tailwind is a set of utility CSS classes you can use that tend to guide you into writing CSS that looks like it "fits" together. E.g., consistent gaps if you use `gap-1`, `gap-2`, etc., rather than a hodgepodge of "hmm did I use margin-right: 2px or 1em or what" that can emerge in a large CSS codebase with many developers. We can use a `m-1` or `p-1` class to define a base padding, and as long as everyone knows that `1` is the amount of space to use by default, everything will generally look like it fits together. Later, you can optionally redefine what `1` means if you want more space in your design. In a way, using tailwind can be like variablizing your CSS at compile time (in a faster way than just using writing and using CSS variables). For a lot of things, using just 1-3 tailwind classes on a div is sufficient for many common tasks, e.g., `flex flex-row gap-1` boom done. You can put this directly in the HTML, and is considered "fine". An example from DaisyUI's site is: ``` <button class="bg-zinc-100 border font-semibold text-zinc-900 text-sm px-4 duration-200 py-2.5 transition-all hover:border-zinc-300 hover:bg-zinc-200 focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-zinc-900 active:translate-y-[0.5px] inline-flex gap-2 rounded-sm active:border-zinc-300 active:bg-zinc-200 active:shadow-none text-center align-middle cursor-pointer border-zinc-200 dark:border-zinc-700 dark:bg-neutral-700 dark:text-zinc-300 dark:hover:border-zinc-950 dark:hover:bg-zinc-950 dark:focus-visible:outline-zinc-200 dark:active:border-zinc-950 dark:active:bg-zinc-900"> ``` This is everything needed to make a button look nice in tailwind, and obviously it would be insane to copy+paste this every time you want a nice looking button in your HTML (not to mention the byte size, it's just unreadable). The best thing to do is define a `.btn` or `.button` (usually I might avoid `button` DOM level selector for future flexibility) and encapsulate these styles as a semantic component in your .css file. You can write them with raw CSS or `@apply bg-zinc-100 border ...;` using tailwind style @apply. This is what DaisyUI provides you, a shortcut to common nice looking UI components.
doctoboggan 1y ago
> Can you just apply it to `button { @apply flex items-center blahblahblah; }` in app.css? Of course you can. I tried using tailwind a few years ago and I think this was explicitly recommended against, at least at that time.
- qq99 1y ago
  IIRC the creator of tailwind might have been against @apply too, but it didn't seem like a good recommendation to me
  - ChocolateGod 1y ago
    @apply to me I only use if I have no other choice, such as if I need to build a CSS file that needs to have classes with specific names. (Such as giving our company styling to a third party service).
- lowercased 1y ago
  The docs up through version 3.x explicitly called this out as not recommended and a poor choice, but the justifications were... sort of lame. "You'll have to come up with class names, your css bundle might be bigger, etc". I did read a more technical github issue on @apply vs theme() which called out the apply behaviour as doing a bit more than expected. I don't recall 'theme' being a thing in earlier tailwind versions, but I'm not an expert at it, so I might have missed that.
begueradj 1y ago
> you can continue to use tailwind for everything else that DaisyUI has not implemented. It's just an additive layer to tailwind. I used VuetifyJs with Tailwind in the same project, so I do not see the difference/advantage
jug 1y ago
But I mean, Tailwind exists to make you quickly prototype and standardize upon a personal look & feel for your site and reuse these styles with components. The standardization/reuse aspect is absolutely part of it.
- qq99 1y ago
  I think you're agreeing with me. DaisyUI is 1 implementation of a standardization shortcut so you don't have to e.g., develop your own button, dropdown, modal, nav, etc (whatever you are interested to consume from DaisyUI)
mejutoco 1y ago
> In many tailwind projects, you inevitably end up wanting to standardize how a button looks, how a field looks, etc., rather than copy+paste the same 20+ tailwind classes that you need to implement a nice looking button in tailwind. I think in most projects people are using some sort of component system outside of tailwind. A react component, for example, could have the tailwindcss classes. Then that component is used multiple times.
- qq99 1y ago
  Yes, they'll typically have a UI component that accepts props and may have some internal state. DaisyUI is operating at the style layer, so you might use it to achieve the visuals for your UI component (regardless of how you achieve your UI component, be it React/Vue/server-rendered/etc) I'm suggesting that just because you have a UI component, it doesn't mean you should be sending 30 tailwind classes for this button across the wire (in a server-rendered approach), and DaisyUI is 1 mechanism to achieve this with approximately 1 component CSS class.
  - mejutoco 1y ago
    Thank you for the rational well-argumented answer. > I'm suggesting that just because you have a UI component, it doesn't mean you should be sending 30 tailwind classes for this button across the wire (in a server-rendered approach), and DaisyUI is 1 mechanism to achieve this with approximately 1 component CSS class. Aesthetically/ideologically I like that efficiency, but I have to wonder: if we measured that wire with gzip and a lot of redundancy (all the classes) if I would be able to measure any difference in the size or in the cpu decompressing it? Still I like the idea of making it efficient by default.
SebastianKra 1y ago
That's what components are for. One of the issues with classes is that you inevitably run into a behavior that requires additional dom nodes or js. For example, what if your most of your buttons need to show loading states [^1]. Bootstrap is actually not as bad as I remember, but I still see quite a few examples where their api requires complex & specific combinations of elements. Just compare their Accordion to ShadCN's. For simple buttons you may get away with classes only (not worth the risk imo), but anything more complex than a dropdown should be a component. Case in point: daisyUIs dropdown doesn't support arrow key navigation or escape. [^1]: https://www.radix-ui.com/themes/docs/components/button#loading https://www.radix-ui.com/themes/docs/components/button#loadi...
- qq99 1y ago
  How are you going to style your components, if not via CSS classes?
  - fnordsensei 1y ago
    Inline on the component itself. Then reach for the button component when you need to make a button.
    - qq99 1y ago
      So your <Button> component still has 60 tailwind classes on it? I think that might work in React, but might have a payload impact on server-rendered React. Another interesting point for using something like this (specifically, using shorter semantic class names instead of multiple tailwind classes) is: Phoenix LiveView LiveView streams DOM changes over the websocket, so afaik can't really meaningfully be compressed to eliminate bytes. By using `btn` instead of 30 tailwind classes, your payloads will be smaller over the wire. A bit niche, but something to think about. The fact that your `<Button>` React component renders 60 tailwind classes might not seem bad (because gzip or otherwise might actually make it ~negligible if you have a ton of buttons on the page and you're server rendering with compression enabled), but in LiveView's case, I don't think there's really any other option (not enough of a text corpus to compress?). Not sure if this was a factor in Phoenix's recent default inclusion of DaisyUI or not. Even in Phoenix, I'm still using a `<.button>` Phoenix component, but that uses a smaller semantic classname most of the time
kylecordes 1y ago
Historically, the way to standardize how a component appears with Tailwind is to use component abstraction in whatever tool you are building with to accomplish that. Define a button once somewhere and then throw on whatever classes it needs. If you were copy-pasting long strings of Tailwind classes all over, you were already doing it wrong before you even heard of Daisy.
- qq99 1y ago
  Sure, you might make a `<Button>` UI component (assume React), but if it embeds 30 classes in it, when you server-render this, every button on your page is contributing ~30 classes worth of bytes to the payload sent across the wire.
- freeone3000 1y ago
  The need for a component abstraction is the problem? `<button class=“steve”>` will render like every other steve button, subject to context, cascading down the rules, and applied globally. You don’t need anything for this but CSS and HTML.
  - stagas 1y ago
    The thing with Tailwind, however, is it reduces your options by picking a certain set of values, where with CSS you can choose whichever, so it becomes easier to have something that is more symmetric and looks better using Tailwind rather than CSS for this reason.
    - freeone3000 1y ago
      This can also be solved by having good design sense, and doesn’t necessitate a builder library. Having your own style also breaks websites out from all looking the same.
martini333 1y ago
> copy+paste the same 20+ tailwind classes No sane developer does this. Where does the Tailwind team or documentation encourage this?
const_cast 1y ago
> In many tailwind projects, you inevitably end up wanting to standardize how a button looks, how a field looks, etc. You should be using components for this, in whatever backend or frontend framework you have. And if you say "well this button needs to have this specific piece of data or text but other buttons don't" - great, extract that from the component. There's no reason to create 12 different buttons.

by qq99 1y ago

Calavar 1y ago

> In many tailwind projects, you inevitably end up wanting to standardize how a button looks, how a field looks, etc., rather than copy+paste the same 20+ tailwind classes that you need to implement a nice looking button in tailwind. CSS classes already support this natively. The whole point of CSS was move up a level of abstraction, so you could collect related styles into a class and reference that class everywhere you need that same grouping of styles instead of copy/pasting your HTML2 attribute-based styles all over the place. But then we got Tailwind, which uses CSS classes to emulate the pre-CSS behavior of specifying styles at a hyperfine granularity everywhere. And now we get DaisyUI, which emulates class based styling on top of a toolkit that emulates attribute based styling on top of the class based system of CSS. After while we have to admit that this tech stack contortion is the result of picking a tool because of familiarity and not because it is the best fit for the problem.

qq99 1y ago
Just because you have Tailwind in your codebase doesn't mean you can _only_ use Tailwind. I often use a mixture of both when it makes sense. The Tailwind classes are often terser. Tailwind is not great for all things. > which emulates class based styling IMO, what DaisyUI does is how you are meant to be using Tailwind. You aren't supposed to use _only_ TailwindCSS classes in HTML directly (although you can). It's faster for prototyping, then once the prototype solidifies and becomes a pattern, you can extract your long tailwind string into a nice utility class. It happens to use things like `@apply gap-2` internally in its src, so that if you want to override "how large the gaps are" in Tailwind, Daisy will also inherit that override.
jarjoura 1y ago
Yes, Tailwind's CSS reminds me of the same unoptimized HTML tag soup that editors of the 2000s era web used to spit out. Tailwind is created by designers for designers. It's perfect for how designers think about layout and works well for them in a world with strict design specs. Unfortunately, it's also incredibly bespoke and since it's found in most recent well designed templates, engineers must also learn how to work with it. Something 5 years ago that would have died from its own complexity weighing it down for the new shiney, is now kept alive by the ease at which AI can keep it going.
alexchamberlain 1y ago
The first thought that came to my mind reading the DaisyUI website was "Is this an April Fool's joke?". I wouldn't normally post something like that, as it's entirely unfair to the hard work and dedication that someone has put into this. However, I think it captures my surprise by how smack on the nose this is in terms of the spiral of tech abstractions - this is exactly what CSS was designed to solve, and things like tailwind appear to be leading to people forgetting that.
- jacobsimon 1y ago
  Had the same initial reaction - have we come full circle to Bootstrap 20 years later? But after playing around with their theme builder[1], I think there's real value here - you can quickly spin up a custom-ish set of Tailwind components. I'd rather it output an actual component library though more like shadcn. [1] https://daisyui.com/theme-generator https://daisyui.com/theme-generator

slightwinder 1y ago

qq99 1y ago
Tailwind is a set of utility CSS classes you can use that tend to guide you into writing CSS that looks like it "fits" together. E.g., consistent gaps if you use `gap-1`, `gap-2`, etc., rather than a hodgepodge of "hmm did I use margin-right: 2px or 1em or what" that can emerge in a large CSS codebase with many developers. We can use a `m-1` or `p-1` class to define a base padding, and as long as everyone knows that `1` is the amount of space to use by default, everything will generally look like it fits together. Later, you can optionally redefine what `1` means if you want more space in your design. In a way, using tailwind can be like variablizing your CSS at compile time (in a faster way than just using writing and using CSS variables). For a lot of things, using just 1-3 tailwind classes on a div is sufficient for many common tasks, e.g., `flex flex-row gap-1` boom done. You can put this directly in the HTML, and is considered "fine". An example from DaisyUI's site is: ``` <button class="bg-zinc-100 border font-semibold text-zinc-900 text-sm px-4 duration-200 py-2.5 transition-all hover:border-zinc-300 hover:bg-zinc-200 focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-zinc-900 active:translate-y-[0.5px] inline-flex gap-2 rounded-sm active:border-zinc-300 active:bg-zinc-200 active:shadow-none text-center align-middle cursor-pointer border-zinc-200 dark:border-zinc-700 dark:bg-neutral-700 dark:text-zinc-300 dark:hover:border-zinc-950 dark:hover:bg-zinc-950 dark:focus-visible:outline-zinc-200 dark:active:border-zinc-950 dark:active:bg-zinc-900"> ``` This is everything needed to make a button look nice in tailwind, and obviously it would be insane to copy+paste this every time you want a nice looking button in your HTML (not to mention the byte size, it's just unreadable). The best thing to do is define a `.btn` or `.button` (usually I might avoid `button` DOM level selector for future flexibility) and encapsulate these styles as a semantic component in your .css file. You can write them with raw CSS or `@apply bg-zinc-100 border ...;` using tailwind style @apply. This is what DaisyUI provides you, a shortcut to common nice looking UI components.

doctoboggan 1y ago

> Can you just apply it to `button { @apply flex items-center blahblahblah; }` in app.css? Of course you can. I tried using tailwind a few years ago and I think this was explicitly recommended against, at least at that time.

qq99 1y ago
IIRC the creator of tailwind might have been against @apply too, but it didn't seem like a good recommendation to me
- ChocolateGod 1y ago
  @apply to me I only use if I have no other choice, such as if I need to build a CSS file that needs to have classes with specific names. (Such as giving our company styling to a third party service).
lowercased 1y ago
The docs up through version 3.x explicitly called this out as not recommended and a poor choice, but the justifications were... sort of lame. "You'll have to come up with class names, your css bundle might be bigger, etc". I did read a more technical github issue on @apply vs theme() which called out the apply behaviour as doing a bit more than expected. I don't recall 'theme' being a thing in earlier tailwind versions, but I'm not an expert at it, so I might have missed that.

begueradj 1y ago

> you can continue to use tailwind for everything else that DaisyUI has not implemented. It's just an additive layer to tailwind. I used VuetifyJs with Tailwind in the same project, so I do not see the difference/advantage

jug 1y ago

But I mean, Tailwind exists to make you quickly prototype and standardize upon a personal look & feel for your site and reuse these styles with components. The standardization/reuse aspect is absolutely part of it.

qq99 1y ago
I think you're agreeing with me. DaisyUI is 1 implementation of a standardization shortcut so you don't have to e.g., develop your own button, dropdown, modal, nav, etc (whatever you are interested to consume from DaisyUI)

mejutoco 1y ago

> In many tailwind projects, you inevitably end up wanting to standardize how a button looks, how a field looks, etc., rather than copy+paste the same 20+ tailwind classes that you need to implement a nice looking button in tailwind. I think in most projects people are using some sort of component system outside of tailwind. A react component, for example, could have the tailwindcss classes. Then that component is used multiple times.

qq99 1y ago
Yes, they'll typically have a UI component that accepts props and may have some internal state. DaisyUI is operating at the style layer, so you might use it to achieve the visuals for your UI component (regardless of how you achieve your UI component, be it React/Vue/server-rendered/etc) I'm suggesting that just because you have a UI component, it doesn't mean you should be sending 30 tailwind classes for this button across the wire (in a server-rendered approach), and DaisyUI is 1 mechanism to achieve this with approximately 1 component CSS class.
- mejutoco 1y ago
  Thank you for the rational well-argumented answer. > I'm suggesting that just because you have a UI component, it doesn't mean you should be sending 30 tailwind classes for this button across the wire (in a server-rendered approach), and DaisyUI is 1 mechanism to achieve this with approximately 1 component CSS class. Aesthetically/ideologically I like that efficiency, but I have to wonder: if we measured that wire with gzip and a lot of redundancy (all the classes) if I would be able to measure any difference in the size or in the cpu decompressing it? Still I like the idea of making it efficient by default.

SebastianKra 1y ago

That's what components are for. One of the issues with classes is that you inevitably run into a behavior that requires additional dom nodes or js. For example, what if your most of your buttons need to show loading states [^1]. Bootstrap is actually not as bad as I remember, but I still see quite a few examples where their api requires complex & specific combinations of elements. Just compare their Accordion to ShadCN's. For simple buttons you may get away with classes only (not worth the risk imo), but anything more complex than a dropdown should be a component. Case in point: daisyUIs dropdown doesn't support arrow key navigation or escape. [^1]: https://www.radix-ui.com/themes/docs/components/button#loading https://www.radix-ui.com/themes/docs/components/button#loadi...

qq99 1y ago
How are you going to style your components, if not via CSS classes?
- fnordsensei 1y ago
  Inline on the component itself. Then reach for the button component when you need to make a button.
  - qq99 1y ago
    So your <Button> component still has 60 tailwind classes on it? I think that might work in React, but might have a payload impact on server-rendered React. Another interesting point for using something like this (specifically, using shorter semantic class names instead of multiple tailwind classes) is: Phoenix LiveView LiveView streams DOM changes over the websocket, so afaik can't really meaningfully be compressed to eliminate bytes. By using `btn` instead of 30 tailwind classes, your payloads will be smaller over the wire. A bit niche, but something to think about. The fact that your `<Button>` React component renders 60 tailwind classes might not seem bad (because gzip or otherwise might actually make it ~negligible if you have a ton of buttons on the page and you're server rendering with compression enabled), but in LiveView's case, I don't think there's really any other option (not enough of a text corpus to compress?). Not sure if this was a factor in Phoenix's recent default inclusion of DaisyUI or not. Even in Phoenix, I'm still using a `<.button>` Phoenix component, but that uses a smaller semantic classname most of the time

kylecordes 1y ago

Historically, the way to standardize how a component appears with Tailwind is to use component abstraction in whatever tool you are building with to accomplish that. Define a button once somewhere and then throw on whatever classes it needs. If you were copy-pasting long strings of Tailwind classes all over, you were already doing it wrong before you even heard of Daisy.

qq99 1y ago
Sure, you might make a `<Button>` UI component (assume React), but if it embeds 30 classes in it, when you server-render this, every button on your page is contributing ~30 classes worth of bytes to the payload sent across the wire.
freeone3000 1y ago
The need for a component abstraction is the problem? `<button class=“steve”>` will render like every other steve button, subject to context, cascading down the rules, and applied globally. You don’t need anything for this but CSS and HTML.
- stagas 1y ago
  The thing with Tailwind, however, is it reduces your options by picking a certain set of values, where with CSS you can choose whichever, so it becomes easier to have something that is more symmetric and looks better using Tailwind rather than CSS for this reason.
  - freeone3000 1y ago
    This can also be solved by having good design sense, and doesn’t necessitate a builder library. Having your own style also breaks websites out from all looking the same.

martini333 1y ago

> copy+paste the same 20+ tailwind classes No sane developer does this. Where does the Tailwind team or documentation encourage this?

const_cast 1y ago

> In many tailwind projects, you inevitably end up wanting to standardize how a button looks, how a field looks, etc. You should be using components for this, in whatever backend or frontend framework you have. And if you say "well this button needs to have this specific piece of data or text but other buttons don't" - great, extract that from the component. There's no reason to create 12 different buttons.