The Overcomplexity of the Shadcn Radio Button • Hacker News Board

Re: The Overcomplexity of the Shadcn Radio Button

#281

Post by cloverich » Tue, Jan 20, 2026, 5:01 PM UTC

benrutter wrote: post #22

This radio selection is brilliant silly, especially because the end result is indecipherable from a vanilla css rqdio button. For some reason people keep going back to complex UI and interactivity frameworks though, does anyone have a good example of a large website built without all this bloat? Asking because I've seen hundreds of small sites built with elegance and simplicity, and few large ones. Is it just inevita…

Its because everyone can see UI, and many have strong opinions on it. Its always the first tragedy of the commons. In a typical tech company built on compromise, fighting the complexity is a fools errand.

Re: The Overcomplexity of the Shadcn Radio Button

#282

Post by QuadmasterXLII » Tue, Jan 20, 2026, 5:06 PM UTC

gf000 wrote: post #256

QuadmasterXLII wrote: post #220

Earlier quoted context omitted.

i’ve tried this, and it almost almost works to just rebuild the Dom on every state change as a pure function of state without any react or anything. The resulting interface is actually way snappier than react – but preserving local state of elements like what text is highlighted, where the cursor is, which radio button is tabbed to etc turns into a nightmare.

With all due respect, I don't believe it is "more snappier than react". React itself with nothing else is plenty fast. You would have to go way out of your way to see performance differences between different UI approaches, computers are just way too fast to notice whether this click resulting in the div's text changing to +1 is slow or fast, even if the implementation were crazy convoluted. What makes react apps slo…

This is where "react is a library, not a framework" kinda lets it have its cake and eat it too. preact is 4 kb, React + react dom is like 30 kb, but when I use it under commercial pressure to deliver it seems to climb into the megabytes. I'm working on a react native app right now that is a completely embarrassing 150 Mb. The experiment in no react, build UI from scratch every state change has stayed around 65 kb without much attention paid to bundle size, with 10 kB of that being a bunch of linear algebra and differential equation solving code and 50 kb of that a plotting library that's completely nonblocking for the rest of the app.

Re: The Overcomplexity of the Shadcn Radio Button

#283

Post by chrismorgan » Tue, Jan 20, 2026, 5:14 PM UTC

sam_lowry_ wrote: post #268

chrismorgan wrote: post #251

Earlier quoted context omitted.

You’re misunderstanding. This isn’t about React, it’s the Radix UI primitives library which is being overcomplicated by it allowing you to put any element as the visual part of the radio button. As for “the point of React” being that you can just do such and such… there’s nothing special about React there, that’s what any of these component libraries achieve (React, Vue, Svelte, &c. , even basic templating systems li…

Am I? I was just quoting the React creator.

Radix UI Primitives has placed this requirement on itself. What you’re quoting amounts to “component abstractions allow you to easily throw Radix UI Primitives away” which is irrelevant.

Re: The Overcomplexity of the Shadcn Radio Button

#284

Post by thedelanyo » Tue, Jan 20, 2026, 5:19 PM UTC

davely wrote: post #258

tomashubelbauer wrote: post #232

Earlier quoted context omitted.

FWIW I've been writing UIs using plain JavaScript and the DOM API for like 15 years and at a certain scale, I always ended up building an ad-hoc framework or being disgruntled when I had to reach for any of the pre-React UI frameworks whose APIs and approaches I didn't like. React changes this, nowadays I either start with pure DOM and then rewrite to React or just start with React. I see a lot of hate online for Rea…

I work on a React based web app in my Day Job and have genuinely enjoyed it. That said, it always feels like so much boilerplate to get up and running for a greenfield project (and things like NextJS or even TanStack Start add a lot of things that might be overkill for a simple web app). For some vibe coded side projects with Claude, I’ve been working with just using handlebars templates with Express and it has been…

> and have genuinely enjoyed it.

People who haven't work with other frameworks like svelte, Vue - normally say they are enjoying React.

Re: The Overcomplexity of the Shadcn Radio Button

#285

Post by lyu07282 » Tue, Jan 20, 2026, 5:20 PM UTC

tmvnty wrote: post #153

So for a React developer who doesn't want to include Shadcn/Radix, but also doesn't have time to build every component/a11y/compat/edge cases from scratch, what are the better alternatives? Would be nice to list them here so developers can know a midpoint between DIY Shadcn/Radix

I heard that a more modern alternative to radix is react-aria: https://react-aria.adobe.com/

Re: The Overcomplexity of the Shadcn Radio Button

#286

Post by PaulHoule » Tue, Jan 20, 2026, 5:22 PM UTC

tomashubelbauer wrote: post #232

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…

FWIW I've been writing UIs using plain JavaScript and the DOM API for like 15 years and at a certain scale, I always ended up building an ad-hoc framework or being disgruntled when I had to reach for any of the pre-React UI frameworks whose APIs and approaches I didn't like. React changes this, nowadays I either start with pure DOM and then rewrite to React or just start with React. I see a lot of hate online for Rea…

I came to really appreciate React over time.

My initial objections were: (a) circa 2006 I was making very demanding RIAs such as knowledge graph editors and GIS decision support software and I've yet to see any modern framework that is as good as what I was using then (not in JS but rather GWT and Silverlight w/ the same async comms) and (b) the React model is not a 100% match for the form-based applications that we usually write with it (but boy do I love react-hook-form)

React is like the code in Graham's On Lisp [1] in that functional programming is used to create a sort of DSL. There are a lot of ways to implement reactivity that usually require a special interpreter (spreadsheets) or compiler (Svelte). React's system does show seams (you really need to be on top of identity and equality) but it is remarkably simple.

React shines, in my mind, for things that aren't form applications. For instance, VR applications with AFrame -- it's somewhere between VRML and Unity. I am working on a (mainly) heart rate variability biofeedback application [2] and it is so easy to make dashboards that display real-time metrics as well as Poincare sections and time series. That is, I can slap together a few data processing functions and widgets and make a new dashboard with new metrics and charts or new sensors. One goal is to get it working on a tablet in a two player version.

The disadvantage of React is that it does not work so well for highly dynamic layouts. In my case I have a library of functions to "fetch" the data stream and put them into the top of the component (may even package as hooks) and then put the layout together with JSX. I'd like to have a version where the user can drag and drop the components to make a custom layout and the system figures out the dependencies for the data fetching, preparation and processing like the things I made in 2006 and that kind of application with a dynamic layout (think programs like Photoshop with lots of different little widgets and property sheets) wants a different approach to reactivity.

[1] use of macros in that book is a red herring, the one example in it where you really need macros is when he is implementing cooperative multitasking, a feature that Python and Javascript already have -- most examples from that book as with Norvig's Lisp book can be coded up just fine with

[2] see https://github.com/paulhoule/VulpusVision it might "just work" if you npm install, npm run dev, and look at it in Chrome and connect with a Polar H10 or other BT monitor

Re: The Overcomplexity of the Shadcn Radio Button

#287

Post by PaulHoule » Tue, Jan 20, 2026, 5:24 PM UTC

thedelanyo wrote: post #284

davely wrote: post #258

Earlier quoted context omitted.

I work on a React based web app in my Day Job and have genuinely enjoyed it. That said, it always feels like so much boilerplate to get up and running for a greenfield project (and things like NextJS or even TanStack Start add a lot of things that might be overkill for a simple web app). For some vibe coded side projects with Claude, I’ve been working with just using handlebars templates with Express and it has been…

> and have genuinely enjoyed it. People who haven't work with other frameworks like svelte, Vue - normally say they are enjoying React.

I wanted to like Vue but when I tried it I didn't. For writing ordinary business applications I wish React reified lists more than it does, but what I like about React is that I know how to draw absolutely anything with it, including 3-d worlds, see

https://aframe.io/

Re: The Overcomplexity of the Shadcn Radio Button

#288

Post by lyu07282 » Tue, Jan 20, 2026, 5:28 PM UTC

supermatt wrote: post #69

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

I almost had the same reaction tbh! Like I remember inline-grid and place-content for example was not at all supported css, it would've been a nightmare to do, but modern browsers css support is way more powerful than my mental model of them still is. So it's time to update that mental model.

Re: The Overcomplexity of the Shadcn Radio Button

#289

Post by pembrook » Tue, Jan 20, 2026, 5:44 PM UTC

oneeyedpigeon wrote: post #146

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…

> So anybody building a web app... ... beyond a specific size. This important distinction might transform "anybody" into "10%" or "5%" or "0.001%"—who knows, I'm still trying to figure this out! What is it about multiselect or radio buttons that you feel is lacking in the current Web platform?

Native radios are notoriously hard to style consistently across browsers. You can do it with appearance: none, pseudo-elements, etc., but:

- You re-implement focus rings, checked states, hover, disabled, error states.

- You end up bloating your stylesheet incomprehensibly

- Cross-browser differences (especially Safari) still leak through.

- Controlled components, validation layers, animations/transitions, rich layouts are annoying and break accessibility

- Turning native radios into radio cards for example breaks accessibility and keyboard navigation

- Rows with icons, badges, subtext, etc. between the radio and label is a huge issue

Hence why everybody uses Shadcn instead.

Re: The Overcomplexity of the Shadcn Radio Button

#290

Post by parhamn » Tue, Jan 20, 2026, 5:52 PM UTC

mcintyre1994 wrote: post #108

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…

Fun exercise! https://codepen.io/mcintyre94/pen/pvbPVrP Everything in styles.css in that example maps to the vanilla input, so you just have to move them around a bit. Should work at least as well as theirs across browsers, because it's vanilla inputs and the same CSS.

The case is made. That's awesome.