The Incredible Overcomplexity of the Shadcn Radio Button
55 points by FedericoSchonborn
55 points by FedericoSchonborn
And this is why the modern web feels slow and sluggish. Decades of optimisation in browser engines, only to be slandered for this useless bloat. It's a breath of fresh air when you visit a simple website.
This is called the rebound effect and has been described as early as the XIXth century, according to Wikipedia.
I'm sure these dependencies are imported early in the project when there isn't (enough) people to raise any concern. Later on, when there's a lot of people, there's too much bureaucracy to go through.
I would say this type of "coding horror" happens when the framework tries to be too much backward compatible e.g. they try to create their own Dialog instead of using the native one.
the component in the post is demoed here: https://ui.shadcn.com/docs/components/radio-group
And, just in case you thought this would surely be marvellous for accessibility… see that gap-3 and try clicking between the radio button and the text. Yep, they’ve abstracted the appearance of the radio button by itself, even though you will never use it without a label following it, and there’s a huge pitfall waiting right there for you to fall into.
Quite apart from its ridiculously low contrast which will render it all but invisible on poorly-calibrated screens.
Honestly, the further I look in these shadcn demos, the worse it seems. They seem determined to deliberately reimplement native browser functionality badly. (Not that all of it is such reimplementation, but more than a few bits are.)
About the gap-3, do you mean that you expected them to do <label><input type="radio"/>Hello</label> and that's why the gap is not clickable?
That’s one solution. Another would be to replace gap-3 on the parent div with pl-3 on the Label.
This is even more depressing when you realise that shadcdn/ui was "released" as version 0.0.2 (on NPM)... three years ago.
So, literally zero excuse for anyone to use this approach at the time it was written.
Edit: someone on the orange site posted a codepen showing how you can achieve essentially the same result in a whopping <checks notes> 489bytes of CSS.
Back in the days when I was doing a lot of ExtJS development, this didn't bother me too much. I mean, there you developed on a different level than HTML / CSS files, specifying everything with JS objects, and producing output that's supposed to emulate a 90s-era desktop GUI. The abstraction of the whole web stack as just a rendering engine was clear.
I also can see the cost/benefit ratio for intranet/admin applications.
It does get annoying a lot when it's "islands of interactivity" on more normal web pages, as the cruft accretion tends to generate more friction here, sooner or later.