DaisyUI: Tailwind CSS Components
daisyui.com
daisyui.com
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.
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.
> 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.
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.
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.
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.
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.
https://pdx.su/blog/2023-07-26-tailwind-and-the-death-of-cra...
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...
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
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.
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.
Isn't this called classes and Ids in CSS? Is Tailwind just CSS on top of CSS?
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.
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)
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.
I tried using tailwind a few years ago and I think this was explicitly recommended against, at least at that time.
I used VuetifyJs with Tailwind in the same project, so I do not see the difference/advantage
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.
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.
> 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.
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...
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
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.
How is having consistent design across the entire application a bad thing?
Changing the .button class is risky, you'll break the entire application. So you just create a new class. Um, oops.
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.
If you were copy-pasting long strings of Tailwind classes all over, you were already doing it wrong before you even heard of Daisy.
`<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.
No sane developer does this. Where does the Tailwind team or documentation encourage this?
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.
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.
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.
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.
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.
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 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.
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.
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">.
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!
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 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.
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.
If you look at their Showcase section[1], you can't tell it's using TailwindCSS for most of them (imo).
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.
Sure, you can override them, but most people don't and there is definitely a "tailwind look"
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).
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.
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.
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 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.
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'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.
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?
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 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?
Moving to Scoped CSS in Vue components was a pleasure though at the time.
I don't use tailwind myself but I might try it with a this as a theme.
See they have actually updated Bootstrap =)
Basically a DaisyUI, but with looks of Bootstrap or Semantic-UI
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
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.
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
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.
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)
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.
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.
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 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.)
My advice is more cautionary for folks who search "Tailwind components library", see DaisyUI as the 4th result, and think "great!"
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.
- 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!
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
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.
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/
Congratulations! You've invented Bootstrap.
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 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’m sure people find it useful in some way, despite that.)