The Overcomplexity of the Shadcn Radio Button • Hacker News Board

Re: The Overcomplexity of the Shadcn Radio Button

#61

Post by curtisblaine » Tue, Jan 20, 2026, 9:22 AM UTC

antisol wrote: post #28

parhamn wrote: post #10

I normally share the sentiments of the article. But I am also curious, if the goal was: - Implement the radio as the designer sent in the figma file (e.g. something like the radix demo one they're commenting on: https://www.radix-ui.com/primitives/docs/components/radio-gr... ) - Make sure it looks the exact same across all browsers How doable is it with vanilla css? The example they gave was rendered to a black/white…

> - Make sure it looks the exact same across all browsers > How doable is it with vanilla css? It's not doable with your fancy frontend framework and your 20 imports and your ten thousand lines of typescript. "Make sure it looks the exact same across all browsers" is, and always has been, fundamentally at odds with how the web is intended to work. How well does this shadcn crap render in arachne? ladybird? netsurf? l…

Exactly the same when rendered by the evergreen mainstream browsers. That's perfectly doable.

Re: The Overcomplexity of the Shadcn Radio Button

#62

Post by skrebbel » Tue, Jan 20, 2026, 9:24 AM UTC

hu3 wrote: post #17

supriyo-biswas wrote: post #12

Earlier quoted context omitted.

Is it sarcastic or does it appear only on high frame rate devices? To me it simply feels like another radio button.

> Is it sarcastic or does it appear only on high frame rate devices? To me it simply feels like another radio button. You're absolutely right! Today I'm using a friends gaming computer. It's a 244hz monitor powered by a RTX 5070 TI and a screamingly fast AMD Ryzen 7 9800X3D CPU with 128GB of overclocked 6000MT/s RAM. Not only does the radio look mundane for such overcomplicated component, but it also misses clicks wh…

It also doesn't catch clicks between the label and the radio button.

Re: The Overcomplexity of the Shadcn Radio Button

#63

Post by tobyhinloopen » Tue, Jan 20, 2026, 9:24 AM UTC

mastermedo wrote: post #6

The shadcn radio button in action: https://ui.shadcn.com/docs/components/radio-group

Is this developed by these 10x developers I've heard about?

Re: The Overcomplexity of the Shadcn Radio Button

#64

Post by curtisblaine » Tue, Jan 20, 2026, 9:24 AM UTC

xearl wrote: post #8

Did they ask the original authors of Radix why it's the way it is?

In 2020, radio buttons weren't easily stylable in all mainstream evergreen browsers. That's usually the case why some components are over engineered. Of course they should have simplified them when all browsers fell in line, but tech debt is hard.

Re: The Overcomplexity of the Shadcn Radio Button

#65

Post by mad182 » Tue, Jan 20, 2026, 9:25 AM UTC

pembrook wrote: post #43

It has to be this way because we (the collective we) refuse to agree on adding proper UI primitives to the web. We’re like 20+ years into web apps being a big thing and there’s still nothing like what’s offered in OS-native frameworks like Swift. So anybody building a web app has to recreate SwiftUI in the browser every time via various bloated hacks (basically what Shadcn is). If we could just agree on adding non-te…

Radio buttons are in html spec for over 30 years and they allow extensive CSS styling on every part of the element.

Re: The Overcomplexity of the Shadcn Radio Button

#66

Post by rrr_oh_man » Tue, Jan 20, 2026, 9:25 AM UTC

teaearlgraycold wrote: post #55

yellow_lead wrote: post #51

Earlier quoted context omitted.

> does anyone have a good example of a large website built without all this bloat? How about this one?

Don’t think it counts

Why not?

Re: The Overcomplexity of the Shadcn Radio Button

#67

Post by wouldbecouldbe » Tue, Jan 20, 2026, 9:26 AM UTC

ehnto wrote: post #52

I don't touch frontend very often anymore, but you could see the writing on the wall for complexity when React took over and newer devs were working exclusively in that abstraction. Unlike other abstractions where things get tidied up and more simple, React is much more complex than the technology it's building on. Necessarily, to enable it's features, but none the less it is a consequence of this that when all someo…

It was fine when it started, it's the addition of useEffect and hooks that messed everything up. Although normaly I prefer functional, for react classes were 100 times better

Re: The Overcomplexity of the Shadcn Radio Button

#68

Post by curtisblaine » Tue, Jan 20, 2026, 9:26 AM UTC

eddie1o wrote: post #5

There has to be a reason for picking button instead of input type="radio", right?

Yep, radio buttons weren't easily stylable in all evergreen browsers back on 2020.

Re: The Overcomplexity of the Shadcn Radio Button

#69

Post by supermatt » Tue, Jan 20, 2026, 9:27 AM UTC

> Why would you want to do this?

Have you tried completely customising a radio button with CSS? Feel free to demonstrate a heavily customised radio button style where you don’t hide the native appearance.

Re: The Overcomplexity of the Shadcn Radio Button

#70

Post by curtisblaine » Tue, Jan 20, 2026, 9:29 AM UTC

ehnto wrote: post #52

I don't touch frontend very often anymore, but you could see the writing on the wall for complexity when React took over and newer devs were working exclusively in that abstraction. Unlike other abstractions where things get tidied up and more simple, React is much more complex than the technology it's building on. Necessarily, to enable it's features, but none the less it is a consequence of this that when all someo…

Managing state and syncing it to the DOM manually is much harder than React (or any other big framework) for any non-trivial web app. Reactive, inherently asynchronous, event driven applications get complex easily.