DaisyUI: Tailwind CSS Components(daisyui.com)
daisyui.com
DaisyUI: Tailwind CSS Components
https://daisyui.com/
180 comments
> 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.
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.
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.
> 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.
I've been complaining about this for years, even writing an article on it. When the article initially made it's rounds on HN it was divisive. People seem to have cooled off a bit on tailwind since then, which is good, but you still see it being dumped into new projects, or originating things like this that attempt to build a facsimile of what we get "for free" in the browser
https://pdx.su/blog/2023-07-26-tailwind-and-the-death-of-cra...
https://pdx.su/blog/2023-07-26-tailwind-and-the-death-of-cra...
Yes to all you have written here. That helps me feel less insane.
If React had scoped styles like Vue has, I don't think tailwind would have gained such traction. Lack of scoped styles in native CSS has always been a fundamental shortcoming (always, except for the brief moment in like 2013 when @scope was spec'd and implemented, only to be snuffed out shortly thereafter). But it's coming for real now, maybe...
If React had scoped styles like Vue has, I don't think tailwind would have gained such traction. Lack of scoped styles in native CSS has always been a fundamental shortcoming (always, except for the brief moment in like 2013 when @scope was spec'd and implemented, only to be snuffed out shortly thereafter). But it's coming for real now, maybe...
We've got @scope back now, and, while it's not exactly the same as it was in the early part of the 2010s, it's still pretty good, as it let's you set both upper and lower bounds for a block of css. Being able to say "these selectors don't apply below this point" is immensely powerful, letting you build donut styles for components very easily
It wasn't quite ready when I wrote a sort of follow up article[1] about new CSS features largely eliminating the need for scss, but it's basically baseline now.
My personal new favorite feature is color mix and the other color compositional functions. You can do really neat tricks with them, current color, and variables, that are otherwise impossible, even with scss
[1] https://pdx.su/blog/2023-10-25-css-is-fun-again/
It wasn't quite ready when I wrote a sort of follow up article[1] about new CSS features largely eliminating the need for scss, but it's basically baseline now.
My personal new favorite feature is color mix and the other color compositional functions. You can do really neat tricks with them, current color, and variables, that are otherwise impossible, even with scss
[1] https://pdx.su/blog/2023-10-25-css-is-fun-again/
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.
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.
The original motivation of CSS was the cascading aspect of it. During its development, the web was largely seen as a web of documents. Style sheets tried mimicking how traditional publishers style their documents, books, etc. There is also a need to reconcile document styling applied by the user agent, the site author, and possibly other sources. This is where cascading comes into play.
Problems start to occur when using a system designed around traditional publishing to declare the layout of a web application. This is why CSS eventually gained layout-related functionality (flex, grid, container queries, etc.), among other features.
Tailwind provides two things out-of-the-box that make it convenient for building web applications: (1) it comes with a ready-to-use style system; (2) it allows styles to be colocated with markup. The second point is mostly useful for building UI components. Everything strictly related to presentation can be stored within a single file.
Before using Tailwind, I was a strong advocate of CSS modules (and I still strongly advocate for CSS modules if one wants to avoid Tailwind). With either approach, one can achieve isolated styling between components. Repeated styling or markup is a strong indicator that you should extract something into a component.
Problems start to occur when using a system designed around traditional publishing to declare the layout of a web application. This is why CSS eventually gained layout-related functionality (flex, grid, container queries, etc.), among other features.
Tailwind provides two things out-of-the-box that make it convenient for building web applications: (1) it comes with a ready-to-use style system; (2) it allows styles to be colocated with markup. The second point is mostly useful for building UI components. Everything strictly related to presentation can be stored within a single file.
Before using Tailwind, I was a strong advocate of CSS modules (and I still strongly advocate for CSS modules if one wants to avoid Tailwind). With either approach, one can achieve isolated styling between components. Repeated styling or markup is a strong indicator that you should extract something into a component.
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.
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
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
The whole tailwind thing feels like an emperor has no clothes thing
I built apps for a long, long time without Tailwind, just using CSS, sometimes Sass. And I still do at work because our build system doesn't support Tailwind compiler. But for all my side projects, of which there's a few, I use Tailwind. It's just so much easier. I don't see how this experience is compatible with a Emperor's no clothes situation.
Tailwind is better understood as a more powerful replacement for inline styles like <p style="color:blue;">, rather than a less powerful replacement for the full functionality of CSS.
Tailwind is an implementation of "Atomic CSS," and the biggest arguments to use Tailwind are the arguments in favor of Atomic CSS, which are well-known.
Tailwind is an implementation of "Atomic CSS," and the biggest arguments to use Tailwind are the arguments in favor of Atomic CSS, which are well-known.
> But then we got Tailwind, which uses CSS classes to emulate the pre-CSS behavior of specifying styles at a hyperfine granularity everywhere.
I think it's unfair to tailwind, the point of it that it provides you sensible defaults to choose from. It's perfect for hobby write-once stuff, prototyping, then once you're happy, create a class and @apply.
It has to work like this to provide fast feedback cycle during development. Why tailwind folks insist that copying and pasting it final product is okay, I don't know.
I think it's unfair to tailwind, the point of it that it provides you sensible defaults to choose from. It's perfect for hobby write-once stuff, prototyping, then once you're happy, create a class and @apply.
It has to work like this to provide fast feedback cycle during development. Why tailwind folks insist that copying and pasting it final product is okay, I don't know.
Most of my Tailwind objections have gone away with the availability of CSS layers. Now using a library for a utility layer, which can surgically override your component layer, makes perfect sense. And using a library for that component layer that adheres to the same design token API as the utility layer also makes sense.
One benefit of tailwind is that while all of the classes look like they set properties with fixed values, they are actually almost all controlled by variables. This makes it easier to retain a coherent design during redesigns. Doing the same in CSS is absolutely possible, but tailwind is terser.
Sure, but you want to do this also with your markup and have one source of truth not many.
And I still prefer using tailwind and daisyui to build my applications.
> 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.
I mean, no. Daisy doesn’t emulate anything, it is class based styling. It happens to have a build system that that emulates attribute based styling on top of the class based system of CSS, but Daisy’s classes appear in your CSS as normal CSS classes.
I mean, no. Daisy doesn’t emulate anything, it is class based styling. It happens to have a build system that that emulates attribute based styling on top of the class based system of CSS, but Daisy’s classes appear in your CSS as normal CSS classes.
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#loadi...
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#loadi...
For anyone else reading, this is also stated in the Tailwind docs: https://tailwindcss.com/docs/styling-with-utility-classes#us....
How are you going to style your components, if not via CSS classes?
(I didn't say to not use classes)
Depends on the conventions of the project. Tailwind is acceptable (shadcn is a great starting point), but if I write them from scratch, I use css modules.
You don't write component styles that often so the context switching and repetition don't matter, and css modules are close to the standard while still being locally scoped.
Depends on the conventions of the project. Tailwind is acceptable (shadcn is a great starting point), but if I write them from scratch, I use css modules.
You don't write component styles that often so the context switching and repetition don't matter, and css modules are close to the standard while still being locally scoped.
Inline on the component itself. Then reach for the button component when you need to make a button.
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
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
> So your <Button> component still has 60 tailwind classes on it?
Yes, and this is better I think, because you still have only one button. So you just reuse the component.
But if you make a .button class, now people are going to be tempted to use that to style their own buttons. And now, you have a dozen buttons and your app breaks in tiny little ways and your codebase is a hot mess.
Yes, and this is better I think, because you still have only one button. So you just reuse the component.
But if you make a .button class, now people are going to be tempted to use that to style their own buttons. And now, you have a dozen buttons and your app breaks in tiny little ways and your codebase is a hot mess.
> But if you make a .button class, now people are going to be tempted to use that to style their own buttons.
How is having consistent design across the entire application a bad thing?
How is having consistent design across the entire application a bad thing?
There has never been an application where I worked that anyone is happy with the base design of the button. There is always some variant, some edge case, some requirement that doesn't fit. This is the whole reason why BEM became a thing briefly and it was tedious. Tailwind solves all that. Just have a base set of styles, pass in any additional styles to the component based on the specific requirements and where the component is used, use tailwind-merge in the component and now I never have to care ever again.
I agree, same boat. You always end up with dozens of button styles and most devs treat CSS as read-only.
Changing the .button class is risky, you'll break the entire application. So you just create a new class. Um, oops.
Changing the .button class is risky, you'll break the entire application. So you just create a new class. Um, oops.
> 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?
Isn't this called classes and Ids in CSS? Is Tailwind just CSS on top of CSS?
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.
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.
> In a way, using tailwind can be like variablizing your CSS at compile time
Isn't this what SCSS or Sass did though? They were around long before tailwind. Is there a reason to pick Tailwind over those? I assume most projects were using them then decided to migrate to tailwind once it became popular, but why did that happen? Was it just keeping up with the cool kids or some actual differentiating features?
I still just handwrite my frontend code so I'm rather ignorant on this topic, it seems like a lot more extra hoops than just writing by hand which actually isn't very difficult (but I'm a single dev on rather smaller projects)
Isn't this what SCSS or Sass did though? They were around long before tailwind. Is there a reason to pick Tailwind over those? I assume most projects were using them then decided to migrate to tailwind once it became popular, but why did that happen? Was it just keeping up with the cool kids or some actual differentiating features?
I still just handwrite my frontend code so I'm rather ignorant on this topic, it seems like a lot more extra hoops than just writing by hand which actually isn't very difficult (but I'm a single dev on rather smaller projects)
Tailwind is just a set of utility classes (that also tends to be compiled), while SCSS is a full-on CSS compiler that offers no utility classes by default.
A lot of the features that SCSS enabled are now natively part of CSS, so it has fallen somewhat out of favor (because: why compile when you can use the same features for free without compiling?). Nesting is in CSS now, which was the killer feature at the time. & scoping too. Variables especially are better in raw CSS because you can re-assign them and have them transition/animate, which is not possible in SCSS. SCSS helped to evolve CSS.
I initially thought Tailwind was very stupid, but after using it, it is somewhat freeing to write some "1-off inline CSS" (essentially) on the DOM node itself. Sometimes inline CSS is OK (and it's nicer to do so with an easy to remember and powerful utility class rather than via `style=`).
For some, it eliminates `MyComponent.css` that has literally 1 rule with 1 style inside it. Colocation with the DOM in some cases making it easier to modify + reason about, less context switching.
A lot of the features that SCSS enabled are now natively part of CSS, so it has fallen somewhat out of favor (because: why compile when you can use the same features for free without compiling?). Nesting is in CSS now, which was the killer feature at the time. & scoping too. Variables especially are better in raw CSS because you can re-assign them and have them transition/animate, which is not possible in SCSS. SCSS helped to evolve CSS.
I initially thought Tailwind was very stupid, but after using it, it is somewhat freeing to write some "1-off inline CSS" (essentially) on the DOM node itself. Sometimes inline CSS is OK (and it's nicer to do so with an easy to remember and powerful utility class rather than via `style=`).
For some, it eliminates `MyComponent.css` that has literally 1 rule with 1 style inside it. Colocation with the DOM in some cases making it easier to modify + reason about, less context switching.
SCSS and Sass don't have a "gap-1"
It's not supposed to, the big value of those is variables and combining rules together in a modular way. You'd define your own gap-1. It's not supposed to be a design system.
Yes that’s why Tailwind is different
Why not use open props then? You get a style system, but not the weird turn-classes-into-inline-styles thing
https://open-props.style/
https://open-props.style/
The hole point of having a Component-Library is to reuse Components. And a component is markup, style and functionality. Not only the CSS. E.g. you want to use the same Button-Component all over the place in your project and not re-declare <button class="btn btn-secondary">text</button> again and again in your project. If you think about more complex Component like a sort able table, it becomes more obvious.
Imo the main benefit of Tailwind (or any other style-in-JS approach) is parameterization. Styling often changes based on runtime state. Mapping runtime states to css classes/ids (or scss functions et al) is brittle and doesn't scale well.
[deleted]
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.
If you were copy-pasting long strings of Tailwind classes all over, you were already doing it wrong before you even heard of Daisy.
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.
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.
`<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.
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.
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.
> 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.
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.
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.
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.
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.
> 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.
> 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.
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.
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.
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)
> 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
I used VuetifyJs with Tailwind in the same project, so I do not see the difference/advantage
> 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.
I tried using tailwind a few years ago and I think this was explicitly recommended against, at least at that time.
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.
IIRC the creator of tailwind might have been against @apply too, but it didn't seem like a good recommendation to me
@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).
> copy+paste the same 20+ tailwind classes
No sane developer does this. Where does the Tailwind team or documentation encourage this?
No sane developer does this. Where does the Tailwind team or documentation encourage this?
This is a rebuild of the antithesis of Tailwind on Tailwind. Bootstrap had this for decades (Daisy even copies the same semantic class names in some cases). Tailwind was supposed to break away from this, to specific actual styles directly, but looks like we're coming back full circle again. Why not just use Bootstrap?
Tailwind is already a full circle. It is essentially a toolkit for using CSS to emulate the pre-CSS era approach of putting styling info inside attributes on the markup (remember the HTML2 days of bgcolor and cellpadding?).
Yeah it's turning the crank another half turn. It's insane to me how the webdev ecosystem keeps reinventing itself over and over and over again, trying to solve their previous mistakes without ever reflecting on and learning from why those issues existed in the first place.
I'd say otherwise, it's not circular at all, it's a clean design that uses Tailwind at a low level and builds a high level on top of it.
Again, that's just Bootstrap with extra steps.
You can use tailwind and classes at the same time.
It's not a full circle, because you don't end up back where you started. Inline styles have many well-known missing features, like pseudo-classes and media queries.
Don’t forget it adds the “feature” of a build step that literally greps the source code to see which style shortcuts you used, or seemed to use, so it can render them into CSS definitions so they can be turned back into inline styles.
And why is that a bad thing? It might be the case that bgcolor and cellpadding stopped being used because they didn't support media queries for example, not because they were inline styles.
There was a 10 to 15 year gap between people ditching bgcolor and cellpadding for CSS1 and widespread browser support for CSS3 media queries (2011, when IE9 got support and Chrome broke 25% market share). So I strongly disagree that the migration was about media query support.
Because you can use Tailwind on top of DaisyUI, e.g. `btn rounded-lg`
[deleted]
Maybe Tailwind has better dead code removal.
I don't really use Tailwind. I enjoy my (S)CSS.
I took a look at https://daisyui.com/components/button/ and immediately I see classes that look similar to Bootstrap.
So my question is: Why build components on top of something like Tailwind instead of just regular CSS? Or are you able to customize and use Tailwind mixed in with the components? Then sure why not I guess.
Otherwise it feels like going full circle here.
I took a look at https://daisyui.com/components/button/ and immediately I see classes that look similar to Bootstrap.
So my question is: Why build components on top of something like Tailwind instead of just regular CSS? Or are you able to customize and use Tailwind mixed in with the components? Then sure why not I guess.
Otherwise it feels like going full circle here.
Yes, everything can be overridden with Tailwind classes (i.e. `btn p-8`). It's a great choice you're a Tailwind enjoyer, but want the batteries-included experience of Bootstrap.
As I see it, it's something like Bootstrap that's built on top of Tailwind which an architecturally valid approach in that it decomposes into clean layers. Personally I could see the appeal of Tailwind in how it encapsulates CSS into graphically meaningful classes, defining classes that are semantically meaningful out of those is a great idea.
Somebody who likes Tailwind would have an easy time specializing DaisyUI to look exactly like what they want. For that matter you could make Tailwind with DaisyUI easily. Their examples look great and I could totally see using DaisyUI instead of Bootstrap on my side projects, though my current ones have real back end problems that need solving and reworking the CSS isn't on the agenda any time soon.
Somebody who likes Tailwind would have an easy time specializing DaisyUI to look exactly like what they want. For that matter you could make Tailwind with DaisyUI easily. Their examples look great and I could totally see using DaisyUI instead of Bootstrap on my side projects, though my current ones have real back end problems that need solving and reworking the CSS isn't on the agenda any time soon.
I've been writing CSS manually since it came out. The latest additions make it less difficult, like & and nesting, variables, etc.
But overall, CSS is just really difficult to scale well properly. I should probably learn Tailwind at this point, instead of continually rolling my own CSS.
So now I have DaisyUI bookmarked since the site is excellent and looks so useful.
But overall, CSS is just really difficult to scale well properly. I should probably learn Tailwind at this point, instead of continually rolling my own CSS.
So now I have DaisyUI bookmarked since the site is excellent and looks so useful.
I've been writing CSS by hand since the late 90s. I resisted Tailwind for a long time, but I tried it on a pet project and I get it now. It doesn't fundamentally do anything that you can't do in CSS already, but it sort of "quantizes" the DX such that the vast majority of the CSS you'd usually end up writing boils down to a set of conventions.
You can still write your own CSS as needed (and probably should, for some of the more esoteric Tailwind cases), but stupid stuff like flexbox directives and padding/layout that you do literally everywhere become a lot easier, especially with things like the Tailwind VSCode plugin which provides autocomplete, reflection on defined variables, and linter errors for duplicated or incompatbile expressions.
You can still write your own CSS as needed (and probably should, for some of the more esoteric Tailwind cases), but stupid stuff like flexbox directives and padding/layout that you do literally everywhere become a lot easier, especially with things like the Tailwind VSCode plugin which provides autocomplete, reflection on defined variables, and linter errors for duplicated or incompatbile expressions.
Right but it comes after a long line of similar CSS frameworks with the same promise, starting with Bootstrap, and there were large movements about 10 years ago of whole orgs deserting those frameworks because of serious issues. Are you saying Tailwind somehow has resolved those? That was the main reason I didn't try to learn it considering it to be just yet another CSS framework's conventions.
Tailwind solves a somewhat different problem. It's maybe easiest to think of it as a bunch of aliases for writing inline styles. The fundamental problem with CSS at scale is leaky abstractions, right? Tailwind moves the abstractions down a level, so that rather than attaching semantic classes, you're just composing the properties of an element directly, except you don't have to remember if you used px or rem for this padding, or what the media query for a mobile breakpoint is. This tends to reduce the incidence of high-gravity classes which tend to accumulate features, at the cost of some verbosity vs something like Bootstrap, though it's significantly less verbose than equivalent inline styles would be.
“Do not remove a fence until you know why it was put up.”
Off topic, but is there a term for the opposite concept?
Something like "Decisions acquire a greater illusion of planning and deliberation the further into the past they were made".
Feels like assuming there is a reason can be just as damaging as assuming there isn't one.
Something like "Decisions acquire a greater illusion of planning and deliberation the further into the past they were made".
Feels like assuming there is a reason can be just as damaging as assuming there isn't one.
Perhaps slightly related: https://en.wikipedia.org/wiki/Planck%27s_principle
Might be the survivorship bias. Or "history is written by the victor".
Hey don't blame Brett for where we ended up!
You can use mixed in tailwind. Its for consistency (which I quite like). I'm a big fan of just saying "gap-1" and knowing that that will be consistent across the custom components I've written, and the component library
For those interested in how to use this with HTMX, read on. DaisyJS supports HTMX as it can work with just plain HTML without needing a fancy JS framework like Vue or React.
You start by setting up something that can serve HTML and with a template engine. My favorite is Django. You also need daisyui, tailwindcss etc in a local NodeJS dir. Those parts aren't too hard, I'll skip over it.
Now you make sure you build a solid base.html with HTMX bits added. HTMX will fetch content from the Django views.
Now if you were using plain Tailwind you'd probably need to use something like django_components to basically make reusable components instead of using HTML. Not with DaisyJS as it simplifies Tailwind vastly; now you can just use <div class="chat-bubble"> and so on, and you get great looking components.
Also use template inheritance and includes, which are basic concepts in Django.
All in all this is a really clean solution that builds future proof apps without a messy JS framework and and SPA that you most likely don't need.
Anyway I'm a big fan of this approach. I get that people have issues with Tailwind itself but one should rather just consider it as a layer of abstraction that we're now skipping.
You start by setting up something that can serve HTML and with a template engine. My favorite is Django. You also need daisyui, tailwindcss etc in a local NodeJS dir. Those parts aren't too hard, I'll skip over it.
Now you make sure you build a solid base.html with HTMX bits added. HTMX will fetch content from the Django views.
Now if you were using plain Tailwind you'd probably need to use something like django_components to basically make reusable components instead of using HTML. Not with DaisyJS as it simplifies Tailwind vastly; now you can just use <div class="chat-bubble"> and so on, and you get great looking components.
Also use template inheritance and includes, which are basic concepts in Django.
All in all this is a really clean solution that builds future proof apps without a messy JS framework and and SPA that you most likely don't need.
Anyway I'm a big fan of this approach. I get that people have issues with Tailwind itself but one should rather just consider it as a layer of abstraction that we're now skipping.
Totally agree, I do use it with Go lang and echo framework which is very light,
I have a very simple vite config to build the css and js, reload everything with air, and it's fast and simple.
Edit: I can't prove it but I think even AI coding is more efficient with this approach, clear server side rendering, plain JS with modern features built with vite and CSS classes.
Edit: I can't prove it but I think even AI coding is more efficient with this approach, clear server side rendering, plain JS with modern features built with vite and CSS classes.
I found daisyui through Jeremy Howard’s (python) fasthtml.
Any repos or articles you can reference that further explore this approach?
Not really. I think I'll do that and put it on my Medium or something.
The fact is that without using component-based HTML, Tailwind _is_ a mess and Daisy is probably useful. It's an amusing full-circle moment, where Daisy UI is a spiritual successor to Bootstrap, which did the same thing but with CSS as the underpinning.
Inside of a system that splits the HTML into components, Tailwind classes are not a problem...You just end up with <x-button.primary> instead of <button class="primary">.
Inside of a system that splits the HTML into components, Tailwind classes are not a problem...You just end up with <x-button.primary> instead of <button class="primary">.
I don’t know, it’s like you ask me to use CSS as it meant to be used all along, I don’t understand why I would need tailwind with daisy on top if I could just write CSS with the added benefit of no extra JS.
Or use Bootstrap for eye candy. Has been there for years and looks good enough.
In any case, it feels like we have come full circle, Red Queen race-style. Yay web development!
Or use Bootstrap for eye candy. Has been there for years and looks good enough.
In any case, it feels like we have come full circle, Red Queen race-style. Yay web development!
After 20 years, my little company still uses just HTML, CSS and JavaScript for everything including two sites I'd bet money most of you visit at least a couple of times a month.
I always find these sorts of weird-brags annoying. Either tell us the sites you built that are popular, or just don't comment about it at all.
You made Hacker News?, nice
What company is this?
prolly a porn company
No. Restaurant chain and entertainment company
> "including two sites I'd bet money most of you visit at least a couple of times a month."
I mean, I don't think I use any restaurant chain web sites. So that leaves an entertainment company.
Netflix, Apple TV+, Disney? I mean... you did say most of us will use some of these sites every month. Most of the entertainment web sites that people use all the time are HUGE companies, why would they use your little company (your own words) ?
I mean, I don't think I use any restaurant chain web sites. So that leaves an entertainment company.
Netflix, Apple TV+, Disney? I mean... you did say most of us will use some of these sites every month. Most of the entertainment web sites that people use all the time are HUGE companies, why would they use your little company (your own words) ?
Tailwind has the Bootstrap problem, in that I can tell straight away that a website uses Tailwind, and for some reason that is off putting.
Bootstrap fights you when you move away from its built-in look-and-feel.
Tailwind is pretty close to neutral. You get the tailwind look by copy-pasting the tailwind components directly and straightforward use of the built-in palette and fonts. But it’s pretty easy to use customized palettes, not that bad to use different fonts (well, the hairy parts are due to HTML, browsers and the web, not tailwind), and it’s probably easier to skip the tailwind components if you know HTML (not a trivial skill but one well worth developing).
Tailwind is pretty close to neutral. You get the tailwind look by copy-pasting the tailwind components directly and straightforward use of the built-in palette and fonts. But it’s pretty easy to use customized palettes, not that bad to use different fonts (well, the hairy parts are due to HTML, browsers and the web, not tailwind), and it’s probably easier to skip the tailwind components if you know HTML (not a trivial skill but one well worth developing).
That is like saying you can tell straight away if a website is using a separate CSS file or style="..." attributes. Non-sense.
What about the components on Blendful[0]? I agree that everything themed with Tailwind looks the same—but I think it's because the starter templates that are popularly used basically have the same look and feel, which is what this site is trying to escape from. Tailwind also has it's predefined color schemes, which enhance the stylistic lock-in.
Of course it's possible to break from the fray with Tailwind, but—I think generally speaking, it's fairly easy to build something that looks decently good, decently easy with Tailwind; and that's why people like it.
[0]: https://www.blendful.com
Of course it's possible to break from the fray with Tailwind, but—I think generally speaking, it's fairly easy to build something that looks decently good, decently easy with Tailwind; and that's why people like it.
[0]: https://www.blendful.com
Tailwind is just a different way of writing CSS.
UI libraries and websites all end up converging on a common set of ideas because of usability and readability, perhaps you're conflating Tailwind UI libraries with Tailwind itself. Tailwind doesn't inherently force a website to look a certain way any more than flexbox or CSS grids might.
I do agree in that if you're using Tailwind you're unlikely to be reaching deep into the full functionality of CSS for animation etc. but most websites aren't doing that whether they're using Tailwind or not.
UI libraries and websites all end up converging on a common set of ideas because of usability and readability, perhaps you're conflating Tailwind UI libraries with Tailwind itself. Tailwind doesn't inherently force a website to look a certain way any more than flexbox or CSS grids might.
I do agree in that if you're using Tailwind you're unlikely to be reaching deep into the full functionality of CSS for animation etc. but most websites aren't doing that whether they're using Tailwind or not.
Tailwind comes with a set of colors, shadows, typography scale, paddings, etc.
Sure, you can override them, but most people don't and there is definitely a "tailwind look"
Sure, you can override them, but most people don't and there is definitely a "tailwind look"
Preface:
I accidentally mixed up Tailwind and DaisyUI in my brain. The commenter above me is talking about Tailwind and my "Previous Comment" is responding by talking about DaisyUI but accidentally also using the word Tailwind.
For previous versions of DaisyUI my main complaint was that it looked childish. V5 fixed this. I misread the parent comment as if they were talking about this same issue. My bad.
Previous comment:
I'm not sure when you most recently used Tailwind, but V5 is a big improvement on V4. 4 definitely looked somewhat childish. 5 corrected most/all of this.
I accidentally mixed up Tailwind and DaisyUI in my brain. The commenter above me is talking about Tailwind and my "Previous Comment" is responding by talking about DaisyUI but accidentally also using the word Tailwind.
For previous versions of DaisyUI my main complaint was that it looked childish. V5 fixed this. I misread the parent comment as if they were talking about this same issue. My bad.
Previous comment:
I'm not sure when you most recently used Tailwind, but V5 is a big improvement on V4. 4 definitely looked somewhat childish. 5 corrected most/all of this.
How does the version of Tailwind itself make difference? The look depends on what styles are applied using Tailwind, not the ability to specify styles. Think the problem is the most tailwind sites have a similar set of styles applied, most likely copies of the docs or examples. TailwindUI is a paid system, but yeah, could be a case of most of the defaults copying that.
I'm sorry. Brain fart. Replace Tailwind V4/V5 with DaisyUI V4/V5.
After re-reading double brain fart.
I misread the comment as complaining about DaisyUI. I then responded as if they were complaining about DaisyUI but ALSO accidentally used "Tailwind" in my comment.
After re-reading double brain fart.
I misread the comment as complaining about DaisyUI. I then responded as if they were complaining about DaisyUI but ALSO accidentally used "Tailwind" in my comment.
How can you tell? Or are you referring to Tailwind UI?
It depends on how much effort you put into it vs. just using any of the base templates/components that Tailwind Plus (previously Tailwind UI) has to offer.
If you look at their Showcase section[1], you can't tell it's using TailwindCSS for most of them (imo).
[1] https://tailwindcss.com/showcase
If you look at their Showcase section[1], you can't tell it's using TailwindCSS for most of them (imo).
[1] https://tailwindcss.com/showcase
You might be bored by the aesthetics, but isn't usability improved by having familiar with UI components across websites?
A bit baffled by all the "Why not just use CSS?" comments here.
Did we forget how much of a pain CSS still is?
For example, I recently made a UI with a series of numbered steps. To the left of each step is a number with a circle around it as a highlight.
The CSS I came up with looked like this:
.step-number { align-items: center; background-color: #0074cc; border-radius: 50%; color: white; display: flex; font-size: 14px; font-weight: bold; height: 24px; justify-content: center; line-height: 24px; margin-right: 10px; width: 24px; }
Did it produce a circle? Of course not. It produced a squished egg shape.
What did I have to do? I had to add "min-width: 24px;" to the class. Why? Hell if I know. "width: 24px;" should've done the job.
Bootstrap (and now Tailwind) exist for a reason: CSS still sucks.
Did we forget how much of a pain CSS still is?
For example, I recently made a UI with a series of numbered steps. To the left of each step is a number with a circle around it as a highlight.
The CSS I came up with looked like this:
.step-number { align-items: center; background-color: #0074cc; border-radius: 50%; color: white; display: flex; font-size: 14px; font-weight: bold; height: 24px; justify-content: center; line-height: 24px; margin-right: 10px; width: 24px; }
Did it produce a circle? Of course not. It produced a squished egg shape.
What did I have to do? I had to add "min-width: 24px;" to the class. Why? Hell if I know. "width: 24px;" should've done the job.
Bootstrap (and now Tailwind) exist for a reason: CSS still sucks.
Yeah it's odd, CSS is pretty horrible to use and Tailwind eliminates some of its biggest problems (cascading, naming, organisation). DaisyUI isn't some sort of return to traditional CSS, it's a way to componentize your markup if you aren't using a system that has components built in, like React et al. This isn't some sort of full-circle reinvention of the wheel.
"instead of writing
100 class names
For every element, every page, every project,
again and again…
use semantic class names sunglasses emoji It's descriptive, faster, cleaner and easier to maintain."
Semantic class names!? Brilliant. Does it seem like the web is reinventing itself to anyone else?
use semantic class names sunglasses emoji It's descriptive, faster, cleaner and easier to maintain."
Semantic class names!? Brilliant. Does it seem like the web is reinventing itself to anyone else?
It is a shame that https://smacss.com never caught on and, instead, Tailwind won. DaisyUI is almost there, but it's just one of few projects that follow this architectural guideline.
I used DaisyUI for a recent project and really enjoyed it. It definitely isn't "Bootstrap for Tailwind". While it does have some semantic class names like bootstrap, it's very few comparatively. It does have a semantic palette (customizable), but this is integrated with tailwind, so all your tailwind utility classes share the palette.
It also has some unstyled or lightly-styled components (modal, dropdown, etc). These are just like using headless UI, but with less JavaScript. These also work well with the Tailwind utility classes to let you customize the actual display.
It also has some unstyled or lightly-styled components (modal, dropdown, etc). These are just like using headless UI, but with less JavaScript. These also work well with the Tailwind utility classes to let you customize the actual display.
I've been using daisyUI for a couple of years and really love it - it's a quick, reliable way to rig up a nice looking/functioning UI with minimal work, while making things appear reasonably uniform across pages/workflows.
The combination of Tailwind and daisyUI made it possible for me - a backend developer - to pretentd to be somewhat competent in frontendland, which has been incredibly handy, work-wise.
The combination of Tailwind and daisyUI made it possible for me - a backend developer - to pretentd to be somewhat competent in frontendland, which has been incredibly handy, work-wise.
I didn't like Tailwind initially, but after using it for a week, it's hard to go back to regular CSS or even SCSS. I have a project that uses SCSS, and sometimes I wish I was using Tailwind instead, it makes the workflow so much easier.
I'd highly recommend people try out Tailwind for a week on their projects before giving up on it.
That said, I haven't tried DaisyUI so no opinions on that.
I'd highly recommend people try out Tailwind for a week on their projects before giving up on it.
That said, I haven't tried DaisyUI so no opinions on that.
And abstraction of an abstraction of an abstraction of an abstraction... Man, I'm never going to use it, but sometimes it's amazing to see what people can find worth their time.
I really don't understand why you use Tailwind for a CSS component library.
To use your component library now people have to use Tailwind, while if you'd used regular CSS both sites with and without Tailwind could use the library (Tailwind is additive on top of CSS after all).
Maybe it appeals to people in the Tailwind bubble, and gain momentum that way?
To use your component library now people have to use Tailwind, while if you'd used regular CSS both sites with and without Tailwind could use the library (Tailwind is additive on top of CSS after all).
Maybe it appeals to people in the Tailwind bubble, and gain momentum that way?
I'm using Tailwind mainly because it came installed by default with create-react-router-app, and it seemed easier to just go with the flow (this is my first web project in about 10 years, so I'm re-learning everything), rather than trying to come up with my own bespoke thing.
After learning it a bit, I liked Tailwind. Writing CSS manually sucks. It's fiddly, and often you have to sit around adding and changing random things until it looks the way you want, and you have no idea why what you did worked. Tailwind doesn't completely fix that, but it makes it significantly better.
But I don't feel like building my own components from scratch. That's where DaisyUI comes in to make my day easier. But if I want to override any of DaisyUI's choices, I have Tailwind's easier-to-use classes that I can use to easily do so.
After learning it a bit, I liked Tailwind. Writing CSS manually sucks. It's fiddly, and often you have to sit around adding and changing random things until it looks the way you want, and you have no idea why what you did worked. Tailwind doesn't completely fix that, but it makes it significantly better.
But I don't feel like building my own components from scratch. That's where DaisyUI comes in to make my day easier. But if I want to override any of DaisyUI's choices, I have Tailwind's easier-to-use classes that I can use to easily do so.
I have used DaisyUI as a base class and then extend on it with additional tailwind classes. Sensible defaults.
I mean, that's certainly a valid set of users to target: people already using Tailwind that want some off-the-shelf components.
So for everyone hating on Daisy and Tailwind, what is the alternative?
I do my best to use vanilla CSS, BEM style, with SCSS preprocessing, but it's not incredibly intuitive, it's apparently hard for most "full stack" devs to do because they think it is beneath them so they will reach for something like MaterialUI.
I agree with the criticisms about tailwind and Daisy but the problem these seem to solve that vanilla CSS does not is that Tailwind for all of its quirks requires less internal agreement than vanilla CSS. Without internal agreement every dev does their own crazy thing to the CSS and it turns to spaghetti fast.
So again my question is, what is my alternative here that gives me this property of "nicely packaged, well documented, modular, scalable CSS" without using Tailwind/Daisy?
I do my best to use vanilla CSS, BEM style, with SCSS preprocessing, but it's not incredibly intuitive, it's apparently hard for most "full stack" devs to do because they think it is beneath them so they will reach for something like MaterialUI.
I agree with the criticisms about tailwind and Daisy but the problem these seem to solve that vanilla CSS does not is that Tailwind for all of its quirks requires less internal agreement than vanilla CSS. Without internal agreement every dev does their own crazy thing to the CSS and it turns to spaghetti fast.
So again my question is, what is my alternative here that gives me this property of "nicely packaged, well documented, modular, scalable CSS" without using Tailwind/Daisy?
I've worked with and without tailwind, with and without n other opinionated styling solutions. It honestly doesn't matter. Use whatever you want. Your project gets big enough you're going to make a mess of it anyway.
Moving to Scoped CSS in Vue components was a pleasure though at the time.
Moving to Scoped CSS in Vue components was a pleasure though at the time.
Fiddling with the theme builder, [0] wow I really like how well done it is! Like a few other comments have said, you can tell when a website uses bootstrap/a tailwind theme you've seen before. The customization options do actually give just enough leeway to make something "not daisyUI like" while not looking garish. The colour themes to pick from are a nice touch too, many theme-rollers just give you a single theme and 100s of colours to configure individually yourself.
I don't use tailwind myself but I might try it with a this as a theme.
[0] https://daisyui.com/theme-generator
I don't use tailwind myself but I might try it with a this as a theme.
[0] https://daisyui.com/theme-generator
I don't like the way how Daisy UI looks. But, I do like the way how Bootstrap or Semantic-UI CSS frameworks look. Has anyone tried to recreate the components of Bootstrap or Semantic UI using Tailwind CSS (including the looks)?
this isn't how Tailwind is supposed to be used. you abstract at the level of components, not class names. <Button /> instead of <button class="btn">
then, inside your Button, you get a small bit of markup and your class names. makes it easy to see which markup gets which styles
that's also why the other discourage use of @apply, and why "ugly HTML" is rarely am issue. at least not in my experience
---
that said, if you're using Tailwind in an environment where there's no components, fragments, partials, whatever - then this might make sense
then, inside your Button, you get a small bit of markup and your class names. makes it easy to see which markup gets which styles
that's also why the other discourage use of @apply, and why "ugly HTML" is rarely am issue. at least not in my experience
---
that said, if you're using Tailwind in an environment where there's no components, fragments, partials, whatever - then this might make sense
> why "ugly HTML" is rarely am issue. at least not in my experience
Fascinating, 5/5 Tailwind projects I have ever used, from YC companies to multibillion dollar private companies have had "ugly HTML". Not every single HTML element is a component, and top levels of components still need to by styled using tailwind's long lists of classes.
Fascinating, 5/5 Tailwind projects I have ever used, from YC companies to multibillion dollar private companies have had "ugly HTML". Not every single HTML element is a component, and top levels of components still need to by styled using tailwind's long lists of classes.
Not entirely convinced about their graphs where they "improve" over tailwind with just HTML size and "number of class names". Why do these matter exactly? You're basically removing the number of classes in the HTML and adding the CSS anyways so how much are you really saving here?
I don't mind the existence of this library obviously but condensing into tiny abbreviated classes seems like the antithesis of tailwind but maybe it's for folks who can't or don't want to define a base button component every time and want a jumping off point. In that case I'd much rather use shadcn or something based on react-aria that gives me solid primitives that I can extend with tailwind classes passed to it in specific instances
I don't mind the existence of this library obviously but condensing into tiny abbreviated classes seems like the antithesis of tailwind but maybe it's for folks who can't or don't want to define a base button component every time and want a jumping off point. In that case I'd much rather use shadcn or something based on react-aria that gives me solid primitives that I can extend with tailwind classes passed to it in specific instances
I imagine you're using most elements more than once in the HTML so the class names would be repeated X number of times.
Repeated strings like that should compress pretty well with gzip, which is one of the core ideas behind atomic css performance, alongside the difficulty to remove dead css – with vanilla html/css your css grows unconstrained
With atomic css, your css stays a constant size, your html will be bigger but is easier to manage as you naturally add/remove html as page content changes, plus compression should be pretty efficient.
I've had to manage legacy frontend codebases with tens of thousands of lines of mostly unused css that were not easy to remove as they might have been used somewhere, that's what led me to start using atomic css.
I don't really love tailwind, but I appreciate it has become ubiquitous so I do use it, and the ideas behind atomic css are solid when you maintain a large frontend codebase. It has also led to the rise of self-contained components as opposed to libraries (shadcn and all the others) which I couldn't be happier about.
With atomic css, your css stays a constant size, your html will be bigger but is easier to manage as you naturally add/remove html as page content changes, plus compression should be pretty efficient.
I've had to manage legacy frontend codebases with tens of thousands of lines of mostly unused css that were not easy to remove as they might have been used somewhere, that's what led me to start using atomic css.
I don't really love tailwind, but I appreciate it has become ubiquitous so I do use it, and the ideas behind atomic css are solid when you maintain a large frontend codebase. It has also led to the rise of self-contained components as opposed to libraries (shadcn and all the others) which I couldn't be happier about.
Related:
DaisyUI: The most popular component library for Tailwind CSS - https://news.ycombinator.com/item?id=38978290 - Jan 2024 (1 comment)
My Journey to build daisyUI: Why Tailwind CSS was not enough? - https://news.ycombinator.com/item?id=38727252 - Dec 2023 (16 comments)
DaisyUI – Tailwind CSS Components - https://news.ycombinator.com/item?id=28004515 - July 2021 (166 comments)
DaisyUI: The most popular component library for Tailwind CSS - https://news.ycombinator.com/item?id=38978290 - Jan 2024 (1 comment)
My Journey to build daisyUI: Why Tailwind CSS was not enough? - https://news.ycombinator.com/item?id=38727252 - Dec 2023 (16 comments)
DaisyUI – Tailwind CSS Components - https://news.ycombinator.com/item?id=28004515 - July 2021 (166 comments)
> instead of writing 100 class names for every element, every page, every project, again and again…
I'm turned off from daisyUI with marketing like this. The alternative to daisyUI certainly isn't this.
I use Tailwind in a similar way that daisyUI does: by putting my utility classes in components and reusing the components.
daisyUI's value prop is that not everyone wants to do this for their custom design system. They should just stick to that instead of making false claims.
I'm turned off from daisyUI with marketing like this. The alternative to daisyUI certainly isn't this.
I use Tailwind in a similar way that daisyUI does: by putting my utility classes in components and reusing the components.
daisyUI's value prop is that not everyone wants to do this for their custom design system. They should just stick to that instead of making false claims.
I agree with others that this is not how Tailwind is meant to be used. For example, the approach shadcn (https://ui.shadcn.com/) takes is much better IMO.
Creating helpers like `btn` makes it very difficult to understand how it works and is not very customizable. Shadcn creates an actual component for you in your codebase and is just trivial Tailwind styles to modify.
Creating helpers like `btn` makes it very difficult to understand how it works and is not very customizable. Shadcn creates an actual component for you in your codebase and is just trivial Tailwind styles to modify.
I tried shadcn and didn't like it. I don't want a new component in my source tree that I have to maintain.
For nearly everything, I won't need to customize it (and if I do have to customize often, it probably means that particular component library wasn't a good choice).
And for the rare cases where I do need to customize something, I can always go into the source of the component library, copy what I want out into my project, and edit it.
> this is not how Tailwind is meant to be used
Who cares? If it works, and makes the development process easier, and doesn't cause problems, then that's a good thing.
For nearly everything, I won't need to customize it (and if I do have to customize often, it probably means that particular component library wasn't a good choice).
And for the rare cases where I do need to customize something, I can always go into the source of the component library, copy what I want out into my project, and edit it.
> this is not how Tailwind is meant to be used
Who cares? If it works, and makes the development process easier, and doesn't cause problems, then that's a good thing.
The problem I have with shad is that it’s react based, not HTML based.
So if I want to use shad, I can’t mix and match static HTML partials in with app code. To maintain a consistent theme, I would need to make literally everything react.
So if I want to use shad, I can’t mix and match static HTML partials in with app code. To maintain a consistent theme, I would need to make literally everything react.
> I agree with others that this is not how Tailwind is meant to be used.
I mean, whatever it's "meant" to be used like, Tailwind is popular enough that it ends up being used in a lot places where how it's meant to be used is a terrible fit. (Big apps, with existing UI code, can't assume a monolithic technology stack, an actual design system with tokens that is not just a react component library, etc).
Ultimately, these are webapps and 99% of what we do ends up being the same shit over and over: "here's a button, here's a card", etc and all ends being like what DaisyUI, Bootstrap, etc offers and I'm glad DaisyUI is there to make Tailwind feasible for the people who are hot on it (don't realize it might not be a good fit for what they are doing.)
I mean, whatever it's "meant" to be used like, Tailwind is popular enough that it ends up being used in a lot places where how it's meant to be used is a terrible fit. (Big apps, with existing UI code, can't assume a monolithic technology stack, an actual design system with tokens that is not just a react component library, etc).
Ultimately, these are webapps and 99% of what we do ends up being the same shit over and over: "here's a button, here's a card", etc and all ends being like what DaisyUI, Bootstrap, etc offers and I'm glad DaisyUI is there to make Tailwind feasible for the people who are hot on it (don't realize it might not be a good fit for what they are doing.)
Yea sure, there are still some spots where I might find DaisyUI helpful, like building a quick internal admin page for something. And another commenter pointed out this works in non-react projects unlike shadcn. But I would know going into it that it will be a pain to customize/maintain, should I ever need to do that. Maybe that's already the expectation for people familiar with Bootstrap though.
My advice is more cautionary for folks who search "Tailwind components library", see DaisyUI as the 4th result, and think "great!"
My advice is more cautionary for folks who search "Tailwind components library", see DaisyUI as the 4th result, and think "great!"
My experience with DaisyUI has been great, is the type of library that:
- Is super useful, and keeps adding value over time.
- It doesn't get in the way when you don't need it.
Gives you prebuilt standards and semantics, (e.g https://daisyui.com/docs/colors) and you can extend it like tailwind easily.
Bonus: The way it implements themes, it makes sense to me, super easy. Love it!
- Is super useful, and keeps adding value over time.
- It doesn't get in the way when you don't need it.
Gives you prebuilt standards and semantics, (e.g https://daisyui.com/docs/colors) and you can extend it like tailwind easily.
Bonus: The way it implements themes, it makes sense to me, super easy. Love it!
Just switched from Flowbite to Daisy.
It’s far simpler, and I don’t have to mess around as much with defining my own button styles etc.
As with all tech, Tis all a long road to the middle
It’s far simpler, and I don’t have to mess around as much with defining my own button styles etc.
As with all tech, Tis all a long road to the middle
Bootstrap is a good practice in old time, tailwind is modern css, daisy ui is a battery included components in pure css based on tw. I use daisy ui in every project I work on, by using daisy ui, I don't need shadcn, I prefer <button> instead of wrap my own <Button>, and menu, dialog etc. With baseui components I have a very powerful toolset that let me build thing's fast and good enough.
Currently using Daisy for https://skatevideosite.com and love it!
Only tangentially related but does anyone know if it's possible to override tailwind locally (in some component) with regular css, perhaps scoped to that component?
For example, tailwind typography is really nice but once that prose class is assigned to an element it seems hard to override things inside of that element.
For example, tailwind typography is really nice but once that prose class is assigned to an element it seems hard to override things inside of that element.
The biggest advantage is I can have great looking components with simple bootstrap syntax (add a primary or secondary class). When I need to I can write full tailwind syntax if I need something different. Great timesaver and while giving you all of your powertools.
Or use a better atomic CSS in JS tool like Panda CSS and just make a mixin however you want (or use their batteries included library if you don’t want to). It’s too bad Tailwind is so popular despite it being so bad at composition and unreadable.
Any website that hijacks scrolling can get in the sea.
That is a rather dismissive attitude that could cause you to overlook some great technologies.
Or it's a quick heuristic to filter out misaligned philosophies.
DaisyUI is like Bootstrap, it's great for me, I'm not a front-end developer. I'm using Rails and DaisyUI to build apps.
Are there any cool UI libraries for Svelte or Vue? Similar to Baseweb or Grommet?I am planning to move away from ReactJS some day
There are a boatload for Vue:
https://www.radix-vue.com/ https://vuetifyjs.com/en/ https://www.unaui.com/ https://vuesax.com/ https://primevue.org/ https://inspira-ui.com/ https://www.naiveui.com/
And for Nuxt there is https://ui.nuxt.com/
https://www.radix-vue.com/ https://vuetifyjs.com/en/ https://www.unaui.com/ https://vuesax.com/ https://primevue.org/ https://inspira-ui.com/ https://www.naiveui.com/
And for Nuxt there is https://ui.nuxt.com/
This is like "Bootstrap for Tailwind?"
Q: Has anyone used claude working with DaisyUI? Don't like claude's default ui choices.
i dont get it, this is a wrapper on top of tailwind that is a wrapper on top of css?
```html
<button class="btn">
```
Congratulations! You've invented Bootstrap.
Congratulations! You've invented Bootstrap.
Just with two extra abstractions on top of it to get the same result.
Sooo... Just like using componenets with Tailwind, as intended?
DaisyUI is the best. so easy to _just start_ something.
Any of you that bitch about this actually used it?
Doesn't this miss the point with Tailwind and why we have Tailwind in the first place?
Yup. And if you use a component based design, the whole premise/problem largely disappears
>Doesn't this miss the point with Tailwind and why we have Tailwind in the first place?
Not for me. Say I have a new app and I want it to have a left nav. I could write my own styles with tailwind or...I could just put a .menu on there and gets all the sensible defaults for padding, spacing, font size, background colors, etc.
But having done that, I'll still want to edit the specific padding, spacing, fonts, and background color of the menu to suit my needs. Plus there's...the whole rest of the site, not all of which is made up of DaisyUI components. So I will be wanting Tailwind for all that for the regular reasons one wants Tailwind.
Not for me. Say I have a new app and I want it to have a left nav. I could write my own styles with tailwind or...I could just put a .menu on there and gets all the sensible defaults for padding, spacing, font size, background colors, etc.
But having done that, I'll still want to edit the specific padding, spacing, fonts, and background color of the menu to suit my needs. Plus there's...the whole rest of the site, not all of which is made up of DaisyUI components. So I will be wanting Tailwind for all that for the regular reasons one wants Tailwind.
I think it's the best of both worlds. Tons of free components right out of the box for non-designer developers (like bootstrap), but you still have the power of Tailwind at your fingertips.
I think the theming & semantic color support is underrated. You just use `-primary` or `-secondary` classes everywhere instead of hardcoding the colors. The theme colors are then just updated with css variables.
Dark mode is free, you don't have to pepper your code with a million "dark:*" classes.
I think the theming & semantic color support is underrated. You just use `-primary` or `-secondary` classes everywhere instead of hardcoding the colors. The theme colors are then just updated with css variables.
Dark mode is free, you don't have to pepper your code with a million "dark:*" classes.
You can just use Bootstrap then, there's no need for the extra abstraction of Tailwind and DaisyUI.
This is just themed Bootstrap.
Tailwind gives me the same feeling of impotent nerdrage that Helm does. In both cases, as soon as I figured it what it was really doing, I was like, no. This is just…wrong.
(I’m sure people find it useful in some way, despite that.)
(I’m sure people find it useful in some way, despite that.)
Is it just me or the tailwind users actually learned what is a semantic css?
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.