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

191–200 of 351 posts

Re: The Overcomplexity of the Shadcn Radio Button

#191

Post by Piraty »

> Web development is hard.

no it's not.

you all make it hard by bloating your sites with Jenga tower abstractions for styling, needlessly load content dynamically via Jenga tower javascript libraries that pulls complexity into frontend and most of the time puts unnecessary load on the content generator ("backend") too. I don't know a lof of sites where that actually makes sense, as web === text.

When html5 came about, along with CSS3, it was such a big leaf in terms of ease of use and accessibility. I argue that what most websites do to my taste nowadays can be achieved by early-stage html5+css3+ a few svg.

Nowadays on about 50% of websites it have to * enable 3rd-party JS just to get the text * enable massive amounts of 3rd-party JS to get the images * enable remote fonts just to grok your pathetic icon-only menu or even spot the 'search' feature (it's not even a 'button' most of the time) because you didn't care to use a proper or

Re: The Overcomplexity of the Shadcn Radio Button

#192

Post by niam »

yoz-y wrote: post #111
wouldbecouldbe wrote: post #67

Earlier quoted context omitted.

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

I know people love to make UIs stateless and functional. But they just aren’t. IMO UIs are fundamentally a bunch of state, graphically represented. So naturally all of the functional frameworks are full of escape hatches. I’d rather have a honest framework than a chimera. I have not followed SwiftUI recently but when it was introduced I quite liked to have the main composition in SwiftUI and then writing more complex…

> UIs are fundamentally a bunch of state

React doesn't really contest that as-worded. It's just that, ideally, a nested component isn't the owner of important state.

Re: The Overcomplexity of the Shadcn Radio Button

#193

Post by virtujoel »

snowmobile wrote: post #95
caseyross wrote: post #90

This is only "overcomplex" from a naive point of view. Radio buttons, as with all UI controls, have tremendous inherent complexity, which comes to light once requirements ask for something beyond the blessed happy path of the default browser button. Pixel perfect styling, animations, focus behaviors, interactions with external state, componentized branding to fit in with companies' ecosystems, etc. The baseline parad…

> it's clear from research that users prefer custom buttons if they provide more "features" than the defaults. Hate to be asking for a "source", but what research? And what "features" can a radio button even have? You click it and it's selected. I suppose accessibility can be considered "features", but I'm strongly suspecting that the overcomplex button has worse accessibility. > all UI controls, have tremendous inhe…

>I suppose accessibility can be considered "features", but I'm strongly suspecting that the overcomplex button has worse accessibility.

Accessibility is incredibly hard to get right, particularly managing screen reader announcements, focus management and form validation. I recently had to build a website that met WCAG 2.1 requirements and it was made significantly easier by using React Aria (https://react-aria.adobe.com/) which is a similarly complex headless component library. To get an idea of the work that goes into making an accessible component, see their blog post about making a combo box where they test 4 different screen readers x 4 different browsers: https://react-aria.adobe.com/blog/building-a-combobox

(I haven't used Radix so I'm unsure how well they do a11y)

Re: The Overcomplexity of the Shadcn Radio Button

#195

Post by azangru »

danabramov wrote: post #150
azangru wrote: post #140

Earlier quoted context omitted.

Stale closures, perhaps.

It never happens if you enable the lint rule.

I remember how react team's message, around the time hooks were introduced, was how hooks were going to save us from the tyranny of `this`, which people presumably found confusing.

I often think back to that message, while adding things in a dependency array. Especially those things that I know won't change (e.g. the redux `dispatch` function pulled from the context), but the linter doesn't. Or while being admonished by the linter for reading from a ref, or writing to it.

Re: The Overcomplexity of the Shadcn Radio Button

#196

Post by holbrad »

frderrin wrote: post #175
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…

> React is much more complex than the technology it's building on. Necessarily, to enable it's features React, just like most software today, is excessively complex for the tasks it performs. The only reason React is used is that many use it as a framework to attempt to provide more interactivity on the page without page reloads. There are other frameworks to do this, but none are as well-used. Webpage interactivity…

I'm just genuinely really confused by this take.

It's a 100x easier to build products today than it was in the 1990's. (I don't think that's an exaggeration in the slightest)

It would be basically be impossible to build anything like Maps, Excaidraw, Chat GPT etc.

Arguably people are reaching for the tools without those interactive requirements ?

Re: The Overcomplexity of the Shadcn Radio Button

#198

Post by nobleach »

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…

They hype-train on all of this stuff is unreal. React+NextJS+Tailwind+ShadCN is just a mess. It's complexity piled on deeper complexity - for little gain! But suggest any of that in many circles and you'll get the standard, "skill issu bro" comebacks. Say what you want about Remix/ReactRouter 7 (there are plenty of issues to talk about there) but at least those guys _tried_ to stay closer to existing web standards. I could go on and on about the disaster of NextJS caching. I could point out RSCs being one way to solve a problem that could already be solved by loaders in other frameworks....

Tailwind was my moment of saying, "Nope, I'm gonna sit this one out". I have a few trusted friends that assure me I'm missing out. I've told them to come back to me after they've done their first major refactor. If they tell me it was a pleasant experience, I'll have another look.

Re: The Overcomplexity of the Shadcn Radio Button

#199

Post by mhitza »

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?

> and it seemed like setting style="" on all elements, but with extra steps.

And extra benefits.

Generally more concise on the common usecase, but more importantly you can combine and use media queries, which can't be done with inline styles alone.

Re: The Overcomplexity of the Shadcn Radio Button

#200

Post by DaanDL »

smartmic wrote: post #84
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…

You make a good point. From a philosophical point of view, abstractions should hide complexity and make things easier for the human user. It should be like a pyramid: the bottom layer should be the most complex, and each subsequent layer should be simpler. The problem is that many of today's abstractions are built on past technology, which was often much better designed and simpler due to the constraints of that time…

The problem is also that every other year contracts/paradigms/... are broken, introducing bugs in libraries and documentation.
Post reply on HN