Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DaisyUI: Tailwind CSS Components

daisyui.com

Post reply on HN
Print view View original

91–100 of 181 posts

Re: DaisyUI: Tailwind CSS Components

#91

Post by mpeg »

seaal wrote: post #32
aniforprez wrote: post #30

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 bu…

I imagine you're using most elements more than once in the HTML so the class names would be repeated X number of times.

Repeated strings like that should compress pretty well with gzip, which is one of the core ideas behind atomic css performance, alongside the difficulty to remove dead css – with vanilla html/css your css grows unconstrained

With atomic css, your css stays a constant size, your html will be bigger but is easier to manage as you naturally add/remove html as page content changes, plus compression should be pretty efficient.

I've had to manage legacy frontend codebases with tens of thousands of lines of mostly unused css that were not easy to remove as they might have been used somewhere, that's what led me to start using atomic css.

I don't really love tailwind, but I appreciate it has become ubiquitous so I do use it, and the ideas behind atomic css are solid when you maintain a large frontend codebase. It has also led to the rise of self-contained components as opposed to libraries (shadcn and all the others) which I couldn't be happier about.

Re: DaisyUI: Tailwind CSS Components

#92

Post by nailer »

commotionfever wrote: post #56

this isn't how Tailwind is supposed to be used. you abstract at the level of components, not class names. instead of 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 envir…

> 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.

Re: DaisyUI: Tailwind CSS Components

#93

Post by fnordsensei »

qq99 wrote: post #81
SebastianKra wrote: post #72

Earlier quoted context omitted.

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 Shad…

How are you going to style your components, if not via CSS classes?

Inline on the component itself. Then reach for the button component when you need to make a button.

Re: DaisyUI: Tailwind CSS Components

#94

Post by lawn »

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?

Re: DaisyUI: Tailwind CSS Components

#95

Post by spicybright »

wahnfrieden wrote: post #59
conductr wrote: post #52

Earlier quoted context omitted.

> 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 j…

SCSS and Sass don't have a "gap-1"

It's not supposed to, the big value of those is variables and combining rules together in a modular way. You'd define your own gap-1. It's not supposed to be a design system.

Re: DaisyUI: Tailwind CSS Components

#96

Post by ashdev »

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.

Re: DaisyUI: Tailwind CSS Components

#97

Post by qq99 »

fnordsensei wrote: post #93
qq99 wrote: post #81

Earlier quoted context omitted.

How are you going to style your components, if not via CSS classes?

Inline on the component itself. Then reach for the button component when you need to make a button.

So your 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 `` 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 `` Phoenix component, but that uses a smaller semantic classname most of the time

Re: DaisyUI: Tailwind CSS Components

#98

Post by freeone3000 »

kylecordes wrote: post #83
qq99 wrote: post #27

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…

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.

The need for a component abstraction is the problem?

`` 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.

Re: DaisyUI: Tailwind CSS Components

#99

Post by throwingrocks »

> 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.

Re: DaisyUI: Tailwind CSS Components

#100

Post by lowercased »

doctoboggan wrote: post #49
qq99 wrote: post #27

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…

> 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.

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.
Post reply on HN