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.
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|7 months ago
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|7 months ago
qq99|7 months ago
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