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.
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.
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 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.
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.
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...
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.
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
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?
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.
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.
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">.
- 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!
See they have actually updated Bootstrap =)
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.
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/
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!"
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.
Moving to Scoped CSS in Vue components was a pleasure though at the time.
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'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'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.
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?
(I’m sure people find it useful in some way, despite that.)
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)
PaulHoule•6h ago