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

251–260 of 351 posts

Re: The Overcomplexity of the Shadcn Radio Button

#251

Post by chrismorgan »

sam_lowry_ wrote: post #213
chrismorgan wrote: post #56

Earlier quoted context omitted.

Half of that complexity springs from the requirement of being able to put any element as the radio button. If you’re willing to say “you can only use anything that can be expressed with CSS applied to the , including psuedoelements” (which is plenty for thing like shadcn), it melts away. The other half of it looks to come from an overloaded Label component which should probably have been split into two. There’s a rea…

Bingo! For the "requirement of being able to put any element as the radio button.", Dan Abramov tells you that this is exactly the point of React, see his comment above: > 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. [0] [0] https://news.ycombinator.com/item?id=46690762

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 like Handlebars a lot of the time).

Re: The Overcomplexity of the Shadcn Radio Button

#252

Post by shermantanktop »

Bewelge wrote: post #137
smartmic wrote: post #84

Earlier quoted context omitted.

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…

I'm struggling to form a definitive statement about my thoughts here, but I'll give it a try: Every (useful) abstraction that aims to make an action easier will have to be more complex inside than doing the action itself. Would love for someone to challenge this or find better words. But honestly, if that's not the case, you end up with something like leftPad. Libraries also almost always cover more than one use case…

I think of it as: adding an abstraction relocates complexity away from what you want to make easy and moves it somewhere else. It does not eliminate complexity in total, it increases it. The best abstractions have a soft edge between using them and not using them. The worst are like black holes.

Re: The Overcomplexity of the Shadcn Radio Button

#253

Post by gf000 »

strogonoff wrote: post #145
realusername wrote: post #142

Earlier quoted context omitted.

Indeed but while being a library is okay for math tools or pdf generation, it evidently didn't work well for building UI components.

Did it not work? Many successful and complex sites and apps use React—whether directly or via a framework (Next, Astro, or something homegrown)—and indeed many frameworks are built on React. > math tools or pdf generation In this case the original scope of the library was “reactive rendering”, which sort of makes sense.

It worked as in react is the de facto frontend choice.

It didn't work as in if I were to ask for the router, state management, etc library, there would be a combinatorial explosion of react "frameworks", all sucking in different ways.

I am (and supposedly grandparent also) on the option that react leaves out way too much that would still be well in the scope of a 'UI framework', and while modularity can be a good thing in certain things, more modular, more moving parts does increase complexity.

Re: The Overcomplexity of the Shadcn Radio Button

#254

Post by scoot »

sesm wrote: post #236
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.

Not true. Radix was built by a team on a Modulz paycheck, then acquired and (more or less) abandoned by WorkOS.

Your (implicit) point that Shadcn didn't develop the underlying component library still stands.

Re: The Overcomplexity of the Shadcn Radio Button

#255

Post by efilife »

supermatt wrote: post #77
snowmobile wrote: post #72

Earlier quoted context omitted.

There's literally an example of that in the post. > where you don’t hide the native appearance What do you mean by this? Seems like an arbitrary requirement to set. Could you show an actual example of how this overengineered style is easier to customize?

The pseudo element solution alone is extremely limiting in its ability to be customised. For more complex customisation you will need to decorate with additional elements within a ref’ed label - and then you are effectively back to what radix does.

> and then you are effectively back to what radix does

I certainly won't need to import x elements from a library that imports y elements itself

Re: The Overcomplexity of the Shadcn Radio Button

#256

Post by gf000 »

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.

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 slow is using it badly, and having 10 other libraries getting in the picture loading fat UI elements, etc.

And frankly these would be much slower in your render everything anew approach.

Re: The Overcomplexity of the Shadcn Radio Button

#257

Post by knallfrosch »

So? Did you open a PR for shadcdn or Radix? Did you throw out the shadcdn code rendering the radio button from your codebase? Did you ensure it doesn't come back the next version?

Otherwise you haven't engineered anything, you've barely outlined the concept of a plan.

Two lessons here: The complexity exists for a reason. Try to understand where it comes from.

Second: Thinking "it could be done this way, I think" is barely 1% of really outlining a solution, implementing it and convincing others to use it. The latter is the hard part, but actually changes things outside of your head..

Re: The Overcomplexity of the Shadcn Radio Button

#258

Post by davely »

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 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 pretty glorious!

I don’t think I’d recommend building a complex web app this way, but for some mild JS interactivity, form submission, etc, handlebars works.

Bonus: I find it much easier to get 100 across the board on Lighthouse scores this way.

Re: The Overcomplexity of the Shadcn Radio Button

#259

Post by andai »

elktown wrote: post #244
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…

Not everything needs to be a SPA. I genuinely believe that the web would've been a much better place today on most important metrics (performance, simplicity, accessibility etc.) if this SPA shift would've never happened. The opportunity cost seems massive to me.

Most software I've used could have been a few hundred lines of PHP. But then they'd be done in like a day, which is great if you're a business owner (and the reason Pieter Levels uses PHP, for example), but not so great if you need to get paid to keep churning the code indefinitely (i.e. most people's situation)... and ideally hire all your friends to help too ;)

Re: The Overcomplexity of the Shadcn Radio Button

#260

Post by danabramov »

daveidol wrote: post #240
fsniper wrote: post #219

Earlier quoted context omitted.

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

The point I wanted to emphasize is that even if you do overcomplicate your DOM, the component abstraction is what allows you to fix it in one place. Don't like what's in your component — add `return `, bam! It's fixed across the entire app now.
Post reply on HN