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

161–170 of 181 posts

Re: DaisyUI: Tailwind CSS Components

#161

Post by const_cast »

qq99 wrote: post #97
fnordsensei wrote: post #93

Earlier quoted context omitted.

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

> So your component still has 60 tailwind classes on it?

Yes, and this is better I think, because you still have only one button. So you just reuse the component.

But if you make a .button class, now people are going to be tempted to use that to style their own buttons. And now, you have a dozen buttons and your app breaks in tiny little ways and your codebase is a hot mess.

Re: DaisyUI: Tailwind CSS Components

#163

Post by CGamesPlay »

Calavar wrote: post #36
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…

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

> And now we get DaisyUI, which emulates class based styling on top of a toolkit that emulates attribute based styling on top of the class based system of CSS.

I mean, no. Daisy doesn’t emulate anything, it is class based styling. It happens to have a build system that that emulates attribute based styling on top of the class based system of CSS, but Daisy’s classes appear in your CSS as normal CSS classes.

Re: DaisyUI: Tailwind CSS Components

#164

Post by drewbitt »

lawn wrote: post #94

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?

I have used DaisyUI as a base class and then extend on it with additional tailwind classes. Sensible defaults.

Re: DaisyUI: Tailwind CSS Components

#165

Post by savanaly »

paradox460 wrote: post #130
alexchamberlain wrote: post #101

Earlier quoted context omitted.

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

The whole tailwind thing feels like an emperor has no clothes thing

I built apps for a long, long time without Tailwind, just using CSS, sometimes Sass. And I still do at work because our build system doesn't support Tailwind compiler. But for all my side projects, of which there's a few, I use Tailwind. It's just so much easier. I don't see how this experience is compatible with a Emperor's no clothes situation.

Re: DaisyUI: Tailwind CSS Components

#166

Post by enricozb »

Calavar wrote: post #36
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…

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

One benefit of tailwind is that while all of the classes look like they set properties with fixed values, they are actually almost all controlled by variables. This makes it easier to retain a coherent design during redesigns. Doing the same in CSS is absolutely possible, but tailwind is terser.

Re: DaisyUI: Tailwind CSS Components

#168

Post by xigoi »

const_cast wrote: post #161
qq99 wrote: post #97

Earlier quoted context omitted.

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

> So your component still has 60 tailwind classes on it? Yes, and this is better I think, because you still have only one button. So you just reuse the component. But if you make a .button class, now people are going to be tempted to use that to style their own buttons. And now, you have a dozen buttons and your app breaks in tiny little ways and your codebase is a hot mess.

> But if you make a .button class, now people are going to be tempted to use that to style their own buttons.

How is having consistent design across the entire application a bad thing?

Re: DaisyUI: Tailwind CSS Components

#170

Post by mejutoco »

qq99 wrote: post #84
mejutoco wrote: post #70

Earlier quoted context omitted.

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

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…

Thank you for the rational well-argumented answer.

> I'm suggesting that just because you have a UI component, it doesn't mean you should be sending 30 tailwind classes for this button across the wire (in a server-rendered approach), and DaisyUI is 1 mechanism to achieve this with approximately 1 component CSS class.

Aesthetically/ideologically I like that efficiency, but I have to wonder: if we measured that wire with gzip and a lot of redundancy (all the classes) if I would be able to measure any difference in the size or in the cpu decompressing it? Still I like the idea of making it efficient by default.

Post reply on HN