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

211–220 of 351 posts

Re: The Overcomplexity of the Shadcn Radio Button

#211

Post by stevepotter »

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't into it

Re: The Overcomplexity of the Shadcn Radio Button

#212

Post by christophilus »

cztomsik wrote: post #188
christophilus wrote: post #160

Earlier quoted context omitted.

I guess it depends on your definition of complexity. Being able to think about your UI as a function of state is a lot simpler than dealing with mutability, coordinating imperative updates all over the place, etc. React’s core idea is simpler than the paradigms it replaced. By simple, I mean as in “Simple Made Easy”[0]. [0] https://m.youtube.com/watch?v=SxdOUGdseq4&pp=ygUQc2ltcGxlIG1...

React is not simple (preact is) and what's worse, it gets more and more overengineered in order to solve the problems they have themselves created (accidental complexity in your video). Sadly, accidental complexity is a common theme among react devs, not just ui libs, but also react-router, redux, redux-form, even tanstack useQuery() is way over-engineered and the core idea can be implemented in Maybe that's the bigg…

Well, to be fair, Preact is what I use. I use the name Preact annd React interchangeably when discussing tech, but I agree Preact is the simpler and preferable of the two. But, in the context of this thread, both provide a nearly identical way to model UI.

Re: The Overcomplexity of the Shadcn Radio Button

#213

Post by sam_lowry_ »

chrismorgan wrote: post #56
Alupis wrote: post #23

Earlier quoted context omitted.

Perhaps this is the original PR for the Radio/RadioGroup[1]. It does seem the complexity was a deliberate decision. [1] https://github.com/radix-ui/primitives/pull/121

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

Re: The Overcomplexity of the Shadcn Radio Button

#214

Post by supermatt »

ruszki wrote: post #119
supermatt wrote: post #103

Earlier quoted context omitted.

It doesn’t. It gives a very naive approach that doesn’t support any complex styling. For that you need to wrap the input and additional styling elements in a ref’ed label.

Can you give an example please? What kind of complexity are we talking about?

Any kind of nested markup: styled content, additional animation layers, etc.

Re: The Overcomplexity of the Shadcn Radio Button

#215

Post by layer8 »

socalgal2 wrote: post #121
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…

Is this the same with everything? In the past, a hard drive, a mouse, or a web camera was a dumb piece of hardware and a driver that ran on your PC. Now, IIUC, each of those has it's own computer (SoC) running an entire OS. Your phone probably has ~20+ SoC. One for USB, one for Wifi, One for Bluetooth, one for each of the 4 cameras, one for lidar, one for SSD, one for cellular, one for the secure enclave, one for aud…

There is a difference between implementations getting more complicated vs. interfaces. It doesn’t matter if the mouse has a SoC if it still only exposes the same old USB HID protocol. The issue discussed in this thread is that the developer using the thing isn’t shielded from the increased implementation complexity and can’t just work with the abstraction.

Re: The Overcomplexity of the Shadcn Radio Button

#216

Post by harel »

I evaluated a LOT of UI toolkits for React. The premise is always great - I want to save time by not having to build a UI toolkit for my application, so I'll use a great one off the shelf. But what I found was that the evaluation falls into three questions:

1. Does it look nice and professional?

2. Will it be here tomorrow?

3. How does it feel to work with - what does my instinct say?

The first question is easy. I either like it or not. I can't answer the second one with certainty. Nobody can. I can only guess. Sometimes I'm wrong.

The third one is instinct driven. If the ergonomics feel off, my instinct will tell me. If something is not right, I'll feel it. I might not always be able to explain it, but I'll know it's a go or no go. ShadCDN came with big praise, but my instinct said a big Nope. It's stuff like that that make me think that, maybe, we add complexity because we get bored with the "boring" tech.

Re: The Overcomplexity of the Shadcn Radio Button

#217

Post by jagged-chisel »

danabramov wrote: post #152
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…

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.

> That’s the power of component abstraction.

Yes. But React isn’t the only way to do components. Unfortunately, to the inexperienced, it is.

Re: The Overcomplexity of the Shadcn Radio Button

#218

Post by benrutter »

hu3 wrote: post #59
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…

https://www.mcmaster.com 2022 post about it. 1400 points. ~500 comments: https://news.ycombinator.com/item?id=32976978

Not the prettiest but absolutely amazing to use! I'm sure web devs are laughing at me right now, but I genuinely didn't realise websites with that many images etc could actually be that fast.

Re: The Overcomplexity of the Shadcn Radio Button

#219

Post by fsniper »

danabramov wrote: post #152
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…

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?

Re: The Overcomplexity of the Shadcn Radio Button

#220

Post by QuadmasterXLII »

stevepotter wrote: post #167
curtisblaine wrote: post #70

Earlier quoted context omitted.

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.

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.
Post reply on HN