The Overcomplexity of the Shadcn Radio Button
9 points by todsacerdoti a day ago | 5 comments
  • css_apologist a day ago |
    on Shadcn's codegen

    I think this is necessary since we need to regularly modify components to suit our needs.. (I've dreamt of extending this kind of approach to libraries for a long time)

    HOWEVER

    there has been an elegant solution to this problem for 30 years - CSS

    CSS tooling lags behind, but from a technical perspective CSS is superior to this component library approach in almost every way

    • paulhebert 21 hours ago |
      Author here. I agree that the having the code editable in my repo is nice!

      But the fact that it just wraps another dependency (Radix) kind of defeats the purpose for me.

      100% agreed on CSS being the right approach here! I’ve been using CSS hacks to style radio buttons for ages before we had good CSS support and never even considered recreating it in JS

  • sevenseacat 17 hours ago |
    UI libraries are hard :(

    (and that's not sarcasm)

    This makes me want to go back to the Tailwind days of `@apply` - usually we end up with crazy overcomplicated HTML markup because we want every part of the styling to be customizable, so you need to add in a way to add user classes to every HTML element. Or you could just define a reasonable HTML structure and let users go wild with `@apply`

  • gherkinnn 14 hours ago |
    I get paid to work with Shadcn and was equally surprised by its radio button. I can't see why Radix implements it this way, and it doesn't work without JS either.

    What I do like about Shadcn, is that its components are yours to modify. In our case, it was easy to replace it with a sensible label+input combination.

  • tefkah 12 hours ago |
    you should have included screenshots