[SebastianKra]

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

[rcarr]

For anyone else reading, this is also stated in the Tailwind docs: https://tailwindcss.com/docs/styling-with-utility-classes#us....

[qq99]

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

[SebastianKra]

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

[fnordsensei]

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

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

[aniforprez]

There has never been an application where I worked that anyone is happy with the base design of the button. There is always some variant, some edge case, some requirement that doesn't fit. This is the whole reason why BEM became a thing briefly and it was tedious. Tailwind solves all that. Just have a base set of styles, pass in any additional styles to the component based on the specific requirements and where the component is used, use tailwind-merge in the component and now I never have to care ever again.