[qq99]

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

[const_cast]

> So your <Button> 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.

[xigoi]

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