Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Overcomplexity of the Shadcn Radio Button

paulmakeswebsites.com

Post reply on HN
Print view View original

231–240 of 351 posts

Re: The Overcomplexity of the Shadcn Radio Button

#231

Post by sesm »

adithyassekhar wrote: post #168

The biggest mistake I did in 2025 was picking shadcn because it was so hyped. Saw it importing from radix anytime you enter a command. First red flag. Then I saw the radio component. Second red flag. You should see what they've done with the select component. But we were too far into the deadline for a project with running targets. So I just gave up and asked copilot to make the changes for me, and I'm not a fan of A…

In general, Tailwind and React don't match well. Why use a soup of CSS classes when React has props? If someone needs an a11y-focused base for their component library, they can start with Radix UI directly, ignoring Tailwind and Shadcn.

Re: The Overcomplexity of the Shadcn Radio Button

#232

Post by tomashubelbauer »

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 React these days and I agree with probably 99 % of it, but the problem in my eyes is not React itself, but the ecosystem that spurred around it. If you stick to just React and take some care with your craft, React is a joy to use IME.

Re: The Overcomplexity of the Shadcn Radio Button

#233

Post by sesm »

stevepotter wrote: post #211
worldsayshi wrote: post #4

Well Shadcn gives you more freedom to fix stuff like this and rewrite how you want the component to work and look, since everything lives in your own code base. In a regular component lib it would be less likely that you'd think about this complexity, since it would be "hidden" away in node_modules or even transpiled and minified.

I still don't understand why someone would choose to essentially clone some code vs import a library. Suddenly you increase your maintenance burden, lose updates, etc. I've had no problems at all with UI libraries like Mantine. If you follow this logic, why not just clone all your npm repos and build from source. Ultimate control, right? Please help me understand the benefits here, because I tried out shadcn and wasn…

It's for projects that are design-first, where you'll have to implement your own component library that matches the design.

Re: The Overcomplexity of the Shadcn Radio Button

#234

Post by flakeoil »

WA wrote: post #86
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…

> when all someone knows is React or other frameworks, things get overengineered The next level annoyance is that everybody just assumes React to be the default for everything. Check the Shadcn website. The landing page doesn’t mention that this is a React-only UI library at all. Same with Radix. The marketing sounds like a general-purpose UI lib. You gotta dig around a bit to realize that this is React-only.

There is a Vue version as well.

Here it is: https://www.shadcn-vue.com/

Re: The Overcomplexity of the Shadcn Radio Button

#235

Post by dbbk »

archerx wrote: post #124
yen223 wrote: post #98

This is the kind of stuff we have to do because almost all browser elements are terrible in terms of customisability. Especially radios and selects If you're one of those who think we should just use the default, bear in mind that the default radio button has poor usability for mobile users.

The only that is annoying to style is the “select” one because it’s hard to style the “options”. The rest seem reasonable and quite customizable in my experience.

And even select is fully customisable now if you're targeting modern browsers

Re: The Overcomplexity of the Shadcn Radio Button

#236

Post by sesm »

tekkk wrote: post #143

Well I want to give shadcn some credit, building a comprehensive open-source UI toolkit, on your own basically, isn't as easy as one would think. Yeah you can use native elements except for some tiny edge case with say Safari and then you go deeper into the rabbit hole, until you decide you'll just customize everything. But at this point you probably have lost a lot of time and sanity already. I'd put the blame on Re…

> on your own basically

The base (Radix UI) was built by a team on WorkOS paycheck.

Re: The Overcomplexity of the Shadcn Radio Button

#237

Post by shimman »

stavros wrote: post #174
sorahn wrote: post #148

Earlier quoted context omitted.

I don't think this is specifically a react problem. The problem is that people don't want to learn what modern CSS can do, or write it themselves (see Tailwind), and most new frameworks make it easy to just sidestep that with div soup. Some of us _like_ CSS, and try to use as much of it when possible, but I feel like we are few and far between. I use react to manage the state of my app, but that doesn't mean I have t…

I really don't understand Tailwind. I heard great things about it, and then I tried it and it seemed like setting style="" on all elements, but with extra steps. Did we go off semantic CSS and returned to setting properties on each element, or was I using it wrong?

You aren't using it wrong, the only thing tailwind does better than 99% of devs is having default values that both look nice and mesh together well.

Utility based CSS has been around as long as classes have, tailwind is just one iteration of that. GitHub use to have a utility css library as well before switching to their new design.

Re: The Overcomplexity of the Shadcn Radio Button

#238

Post by sesm »

oneeyedpigeon wrote: post #144
ediatedia wrote: post #85

Ok, I'll bite. I've been coding for almost 25 years so have seen various things come and go, so hopefully have a bit of capital in the bank. Don't get me wrong, a HTML5 radio button is a beautiful thing, and sometimes React is a hammer and everything is a nail. However, I think something that OP doesn't mention super explicitly in their post is the codebase they are working on is probably a React codebase. React is a…

As someone who has never really dived into React etc., my main question is "where is the line?" I'm sure you'll agree that React is overkill for some applications and, for the sake of this discussion, I'll agree that it's beneficial for applications beyond a certain complexity. But where exactly (or even, roughly) does that line lie? A basic CRUD app? Surely not. A calculator? I'm guessing "no". Bluesky? Maybe/probab…

2 pieces of UI in different parts of the page that depend on the same data - that's the line (also matches the initial goal of React - sync FB chat widgets).

Re: The Overcomplexity of the Shadcn Radio Button

#239

Post by shimman »

QuadmasterXLII wrote: post #220
stevepotter wrote: post #167

Earlier quoted context omitted.

Right. I encourage young devs to build a complex app using vanilla js. Feel the pain of two way state management. Then you’ll gain an appreciation for react. And you’ll learn browser APIs and know when react is overkill because it has its own pain

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.

Based on your description it sounds like you were halfway into reimplementing the virtual dom that react uses (or use to use? unsure if they moved away from that with the implementation of a compiler).

Re: The Overcomplexity of the Shadcn Radio Button

#240

Post by daveidol »

fsniper wrote: post #219
danabramov wrote: post #152

Earlier quoted context omitted.

For what it’s worth, the point of React is that you can just fix that Radio component to be an input (if that makes sense) and it’ll just be an input. React gives you boxes to put stuff into but you decide what to put into them. Then React ensures that you can change what’s in those boxes without breaking anything. That’s the power of component abstraction.

So is a span or div element? What am I missing here?

The parent comment is seemingly blaming React for the decisions of Shadcn for some reason.

There’s nothing about React that requires you to overcomplicate your DOM (unlike many other UI frameworks).

Post reply on HN