[HN Gopher] DaisyUI: Tailwind CSS Components
___________________________________________________________________
DaisyUI: Tailwind CSS Components
Author : a_bored_husky
Score : 188 points
Date : 2025-07-22 13:48 UTC (9 hours ago)
(HTM) web link (daisyui.com)
(TXT) w3m dump (daisyui.com)
| PaulHoule wrote:
| This is like "Bootstrap for Tailwind?"
| coneonthefloor wrote:
| 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.
| thornewolf wrote:
| 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.
| sudhirj wrote:
| 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.
| thornewolf wrote:
| 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.
| stefanfisk wrote:
| How can you tell? Or are you referring to Tailwind UI?
| dmlittle wrote:
| 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
| bickfordb wrote:
| You might be bored by the aesthetics, but isn't usability
| improved by having familiar with UI components across websites?
| crowcroft wrote:
| 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.
| mpeg wrote:
| 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"
| jmull wrote:
| 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).
| foxygen wrote:
| That is like saying you can tell straight away if a website is
| using a separate CSS file or style="..." attributes. Non-sense.
| nikkwong wrote:
| 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
| jug wrote:
| Doesn't this miss the point with Tailwind and why we have
| Tailwind in the first place?
| cdaringe wrote:
| Yup. And if you use a component based design, the whole
| premise/problem largely disappears
| savanaly wrote:
| >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.
| bricej13 wrote:
| 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.
| vitaflo wrote:
| You can just use Bootstrap then, there's no need for the
| extra abstraction of Tailwind and DaisyUI.
| sudhirj wrote:
| 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?
| k__ wrote:
| Maybe Tailwind has better dead code removal.
| 65 wrote:
| Because you can use Tailwind on top of DaisyUI, e.g. `btn
| rounded-lg`
| Calavar wrote:
| 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?).
| treyd wrote:
| 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.
| PaulHoule wrote:
| 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.
| ipaddr wrote:
| You can use tailwind and classes at the same time.
| foxygen wrote:
| 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.
| Calavar wrote:
| 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.
| tshaddox wrote:
| 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.
| wrs wrote:
| 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.
| ibash wrote:
| The evolution of the tailwind enthusiast is almost complete. Soon
| they'll rejoin the old heads who never liked tailwind.
| Tade0 wrote:
| I think they'll do another lap for good measure before they
| settle on that.
| WesolyKubeczek wrote:
| 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!
| adocomplete wrote:
| At that point, why not just write CSS?
| 7bit wrote:
| What point?
| Liquidor wrote:
| 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.
| fbn79 wrote:
| "Do not remove a fence until you know why it was put up."
| mbb70 wrote:
| 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.
| metalliqaz wrote:
| Perhaps slightly related:
| https://en.wikipedia.org/wiki/Planck%27s_principle
| jovdg wrote:
| Might be the survivorship bias. Or "history is written by
| the victor".
| DonHopkins wrote:
| Hey don't blame Brett for where we ended up!
| tevon wrote:
| 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
| bricej13 wrote:
| 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.
| PaulHoule wrote:
| 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.
| 90s_dev wrote:
| 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.
| cheald wrote:
| 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.
| 90s_dev wrote:
| 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.
| cheald wrote:
| 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.
| CGamesPlay wrote:
| 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.
| qq99 wrote:
| I'm surprised that a lot of the comments seem to be missing the
| reason that this project exists.
|
| In many tailwind projects, you inevitably end up wanting to
| standardize how a button looks, how a field looks, etc., rather
| than copy+paste the same 20+ tailwind classes that you need to
| implement a nice looking button in tailwind.
|
| Can you just apply it to `button { @apply flex items-center
| blahblahblah; }` in app.css? Of course you can. Or you can use
| the btn from DaisyUI.
|
| I think DaisyUI is just a shortcut for many common UI components
| that you will inevitably want to build out and that you will
| necessarily eventually standardize in any app that grows large
| enough.
|
| How does it differ from bootstrap? Well, you can continue to use
| tailwind for everything else that DaisyUI has not implemented.
| It's just an additive layer to tailwind. The project is at its
| core just a shortcut for common UI components.
|
| As a user, my criticism is that many of the DaisyUI components
| seem to be lacking good contrast, so some just don't seem to be
| usable. The theming situation is really interesting and quite
| cool to use, but if you look at the example page, it just feels
| hard to read. I can't really find a light and dark default theme
| that look good to me (re: contrast and brightness). I think the
| color hooks might just not be there but I didn't dig far enough
| in.
|
| For me, I've found a lot of value in being able to easily
| copy+paste parts of DaisyUI source code, e.g., a particular
| widget and modifying it to fit my design system, rather than use
| it in its entirety.
| Calavar wrote:
| > In many tailwind projects, you inevitably end up wanting to
| standardize how a button looks, how a field looks, etc., rather
| than copy+paste the same 20+ tailwind classes that you need to
| implement a nice looking button in tailwind.
|
| CSS classes already support this natively.
|
| The whole point of CSS was move up a level of abstraction, so
| you could collect related styles into a class and reference
| that class everywhere you need that same grouping of styles
| instead of copy/pasting your HTML2 attribute-based styles all
| over the place.
|
| But then we got Tailwind, which uses CSS classes to emulate the
| pre-CSS behavior of specifying styles at a hyperfine
| granularity everywhere.
|
| And now we get DaisyUI, which emulates class based styling on
| top of a toolkit that emulates attribute based styling on top
| of the class based system of CSS.
|
| After while we have to admit that this tech stack contortion is
| the result of picking a tool because of familiarity and not
| because it is the best fit for the problem.
| qq99 wrote:
| Just because you have Tailwind in your codebase doesn't mean
| you can _only_ use Tailwind. I often use a mixture of both
| when it makes sense. The Tailwind classes are often terser.
| Tailwind is not great for all things.
|
| > which emulates class based styling
|
| IMO, what DaisyUI does is how you are meant to be using
| Tailwind. You aren't supposed to use _only_ TailwindCSS
| classes in HTML directly (although you can). It's faster for
| prototyping, then once the prototype solidifies and becomes a
| pattern, you can extract your long tailwind string into a
| nice utility class.
|
| It happens to use things like `@apply gap-2` internally in
| its src, so that if you want to override "how large the gaps
| are" in Tailwind, Daisy will also inherit that override.
| jarjoura wrote:
| Yes, Tailwind's CSS reminds me of the same unoptimized HTML
| tag soup that editors of the 2000s era web used to spit out.
| Tailwind is created by designers for designers. It's perfect
| for how designers think about layout and works well for them
| in a world with strict design specs.
|
| Unfortunately, it's also incredibly bespoke and since it's
| found in most recent well designed templates, engineers must
| also learn how to work with it. Something 5 years ago that
| would have died from its own complexity weighing it down for
| the new shiney, is now kept alive by the ease at which AI can
| keep it going.
| alexchamberlain wrote:
| The first thought that came to my mind reading the DaisyUI
| website was "Is this an April Fool's joke?". I wouldn't
| normally post something like that, as it's entirely unfair to
| the hard work and dedication that someone has put into this.
| However, I think it captures my surprise by how smack on the
| nose this is in terms of the spiral of tech abstractions -
| this is exactly what CSS was designed to solve, and things
| like tailwind appear to be leading to people forgetting that.
| jacobsimon wrote:
| 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
| paradox460 wrote:
| The whole tailwind thing feels like an emperor has no
| clothes thing
| tshaddox wrote:
| 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.
| exiguus wrote:
| Sure, but you want to do this also with your markup and have
| one source of truth not many.
| 0x457 wrote:
| > 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.
| paradox460 wrote:
| 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...
| montroser wrote:
| 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...
| paradox460 wrote:
| 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/
| koito17 wrote:
| 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.
| slightwinder wrote:
| > In many tailwind projects, you inevitably end up wanting to
| standardize how a button looks, how a field looks, etc., rather
| than copy+paste the same 20+ tailwind classes that you need to
| implement a nice looking button in tailwind.
|
| Isn't this called classes and Ids in CSS? Is Tailwind just CSS
| on top of CSS?
| qq99 wrote:
| 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.
| conductr wrote:
| > 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)
| wahnfrieden wrote:
| SCSS and Sass don't have a "gap-1"
| pests wrote:
| Then how does tailwind implement it? Use that.
| spicybright wrote:
| 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.
| wahnfrieden wrote:
| Yes that's why Tailwind is different
| qq99 wrote:
| 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.
| paradox460 wrote:
| 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/
| danenania wrote:
| 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.
| exiguus wrote:
| 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.
| doctoboggan wrote:
| > Can you just apply it to `button { @apply flex items-center
| blahblahblah; }` in app.css? Of course you can.
|
| I tried using tailwind a few years ago and I think this was
| explicitly recommended against, at least at that time.
| qq99 wrote:
| IIRC the creator of tailwind might have been against @apply
| too, but it didn't seem like a good recommendation to me
| ChocolateGod wrote:
| @apply to me I only use if I have no other choice, such as
| if I need to build a CSS file that needs to have classes
| with specific names. (Such as giving our company styling to
| a third party service).
| lowercased wrote:
| The docs up through version 3.x explicitly called this out as
| not recommended and a poor choice, but the justifications
| were... sort of lame. "You'll have to come up with class
| names, your css bundle might be bigger, etc". I did read a
| more technical github issue on @apply vs theme() which called
| out the apply behaviour as doing a bit more than expected. I
| don't recall 'theme' being a thing in earlier tailwind
| versions, but I'm not an expert at it, so I might have missed
| that.
| begueradj wrote:
| > you can continue to use tailwind for everything else that
| DaisyUI has not implemented. It's just an additive layer to
| tailwind.
|
| I used VuetifyJs with Tailwind in the same project, so I do not
| see the difference/advantage
| jug wrote:
| But I mean, Tailwind exists to make you quickly prototype and
| standardize upon a personal look & feel for your site and reuse
| these styles with components. The standardization/reuse aspect
| is absolutely part of it.
| qq99 wrote:
| I think you're agreeing with me. DaisyUI is 1 implementation
| of a standardization shortcut so you don't have to e.g.,
| develop your own button, dropdown, modal, nav, etc (whatever
| you are interested to consume from DaisyUI)
| mejutoco wrote:
| > In many tailwind projects, you inevitably end up wanting to
| standardize how a button looks, how a field looks, etc., rather
| than copy+paste the same 20+ tailwind classes that you need to
| implement a nice looking button in tailwind.
|
| I think in most projects people are using some sort of
| component system outside of tailwind. A react component, for
| example, could have the tailwindcss classes. Then that
| component is used multiple times.
| qq99 wrote:
| 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.
| SebastianKra wrote:
| 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...
| qq99 wrote:
| How are you going to style your components, if not via CSS
| classes?
| fnordsensei wrote:
| Inline on the component itself. Then reach for the button
| component when you need to make a button.
| qq99 wrote:
| 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
| SebastianKra wrote:
| (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.
| rcarr wrote:
| For anyone else reading, this is also stated in the Tailwind
| docs: https://tailwindcss.com/docs/styling-with-utility-
| classes#us....
| kylecordes wrote:
| Historically, the way to standardize how a component appears
| with Tailwind is to use component abstraction in whatever tool
| you are building with to accomplish that. Define a button once
| somewhere and then throw on whatever classes it needs.
|
| If you were copy-pasting long strings of Tailwind classes all
| over, you were already doing it wrong before you even heard of
| Daisy.
| qq99 wrote:
| Sure, you might make a `<Button>` UI component (assume
| React), but if it embeds 30 classes in it, when you server-
| render this, every button on your page is contributing ~30
| classes worth of bytes to the payload sent across the wire.
| freeone3000 wrote:
| The need for a component abstraction is the problem?
|
| `<button class="steve">` will render like every other steve
| button, subject to context, cascading down the rules, and
| applied globally.
|
| You don't need _anything_ for this but CSS and HTML.
| stagas wrote:
| The thing with Tailwind, however, is it reduces your
| options by picking a certain set of values, where with CSS
| you can choose whichever, so it becomes easier to have
| something that is more symmetric and looks better using
| Tailwind rather than CSS for this reason.
| freeone3000 wrote:
| This can also be solved by having good design sense, and
| doesn't necessitate a builder library. Having your own
| style also breaks websites out from all looking the same.
| martini333 wrote:
| > copy+paste the same 20+ tailwind classes
|
| No sane developer does this. Where does the Tailwind team or
| documentation encourage this?
| rckt wrote:
| 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.
| nop_slide wrote:
| Currently using Daisy for https://skatevideosite.com and love it!
| aniforprez wrote:
| 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
| seaal wrote:
| I imagine you're using most elements more than once in the HTML
| so the class names would be repeated X number of times.
| mpeg wrote:
| 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.
| rekoros wrote:
| 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.
| iambateman wrote:
| 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">.
| wener wrote:
| 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.
| alfonsodev wrote:
| 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!
| varbhat wrote:
| 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)?
| gizzlon wrote:
| Why not use Bootstrap or Semantic-UI?
|
| See they have actually updated Bootstrap =)
| varbhat wrote:
| I would like to use tailwind css for styling but i also like
| components provided by these CSS frameworks.
|
| Basically a DaisyUI, but with looks of Bootstrap or Semantic-
| UI
| commotionfever wrote:
| 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
| nailer wrote:
| > 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.
| trollied wrote:
| Any website that hijacks scrolling can get in the sea.
| techscruggs wrote:
| That is a rather dismissive attitude that could cause you to
| overlook some great technologies.
| metalliqaz wrote:
| Or it's a quick heuristic to filter out misaligned
| philosophies.
| ipaddr wrote:
| 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.
| nnurmanov wrote:
| 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
| james2doyle wrote:
| 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/
| assimpleaspossi wrote:
| 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.
| sgt wrote:
| What company is this?
| antonio07c wrote:
| You made Hacker News?, nice
| andrewmcwatters wrote:
| This is just themed Bootstrap.
| trevor-e wrote:
| 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.
| adenta wrote:
| 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.
| gedy wrote:
| > 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.)
| trevor-e wrote:
| 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!"
| sgt wrote:
| 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.
| alfonsodev wrote:
| 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.
| intrasight wrote:
| Any repos or articles you can reference that further explore
| this approach?
| sgt wrote:
| Not really. I think I'll do that and put it on my Medium or
| something.
| fkyoureadthedoc wrote:
| 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.
| mattstrayer wrote:
| DaisyUI is the best. so easy to _just start_ something.
| lawn wrote:
| 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?
| metalliqaz wrote:
| I mean, that's certainly a valid set of users to target: people
| already using Tailwind that want some off-the-shelf components.
| ashdev wrote:
| 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.
| throwingrocks wrote:
| > 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.
| JakeSc wrote:
| "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?
| kwar13 wrote:
| Wrapper of a wrapper. Front end dev is a mess lol
| rossant wrote:
| You summed it up pretty well.
| klaussilveira wrote:
| 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.
| elpalek wrote:
| Q: Has anyone used claude working with DaisyUI? Don't like
| claude's default ui choices.
| cafp12 wrote:
| Any of you that bitch about this actually used it?
| martini333 wrote:
| Sooo... Just like using componenets with Tailwind, as intended?
| guluarte wrote:
| i dont get it, this is a wrapper on top of tailwind that is a
| wrapper on top of css?
| wrs wrote:
| 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.)
| dang wrote:
| 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)
| kolanos wrote:
| 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.
| b_e_n_t_o_n wrote:
| 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.
| focusgroup0 wrote:
| ```html <button class="btn"> ```
|
| Congratulations! You've invented Bootstrap.
| vitaflo wrote:
| Just with two extra abstractions on top of it to get the same
| result.
| graypegg wrote:
| 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
| comechao wrote:
| 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.
| sureglymop wrote:
| 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.
| arathis wrote:
| 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
| cantalopes wrote:
| Is it just me or the tailwind users actually learned what is a
| semantic css?
___________________________________________________________________
(page generated 2025-07-22 23:01 UTC)