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

111–120 of 351 posts

Re: The Overcomplexity of the Shadcn Radio Button

#111

Post by yoz-y »

wouldbecouldbe wrote: post #67
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…

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 components in pure UIKit. Both could be used what they are best suited for. But trying to shoehorn good interactivity into a SwiftUI component always ended in horrible code.

Re: The Overcomplexity of the Shadcn Radio Button

#113

Post by jcgl »

realusername wrote: post #82
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 also have the same somewhat controversial opinion, the frontend community wasn't ready and (still isn't) to organise a functional codebase. The second problem is that React has a "draw the rest of the owl" mindset. Sure you have nice frontend components but now what about caching? data transfers? static rendering? bundle size & spliting? routing?

Yeah, as a solo dev quite new to frontend, that made me nope out of React almost immediately. Having to choose a bunch of critically important third-party dependencies right out of the gate? With how much of a mess frontend deps seem to be in general? No thanks.

I settled on Svelte with SvelteKit. Other than stumbling block that was the Svelte 4 -> 5 transition, it's been smooth sailing. Like I said, I'm new here in the frontend world and don't have much to judge by. But it's been such a relief to have most things simply included out of the box.

Re: The Overcomplexity of the Shadcn Radio Button

#115

Post by chrysoprace »

scoot wrote: post #15
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.

> everything lives in your own code base A common misconception. In reality Shadcn is a thin wrapper around libraries such as Radix, recharts, etc. The article says as much.

Sure, but if you wanted to change it to just use a radio input you could. Shadcn gives you a baseline.

Re: The Overcomplexity of the Shadcn Radio Button

#116

Post by tiborsaas »

teaearlgraycold wrote: post #53
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…

Worse still is the misunderstanding that React is simple. It’s an endless stream of cache invalidation bugs. Linters are getting better at catching these. But they also have false positives.

What is cache in this context? useState? What do you mean by cache invalidation in react apps?

Re: The Overcomplexity of the Shadcn Radio Button

#118

Post by ifh-hn »

supermatt wrote: post #103
ruszki wrote: post #101

Earlier quoted context omitted.

The article explains how to style radio buttons with CSS however you want. What’s the problem with that?

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.

But is that still less complex than what the author found?

Re: The Overcomplexity of the Shadcn Radio Button

#119

Post by ruszki »

supermatt wrote: post #103
ruszki wrote: post #101

Earlier quoted context omitted.

The article explains how to style radio buttons with CSS however you want. What’s the problem with that?

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?

Re: The Overcomplexity of the Shadcn Radio Button

#120

Post by mcintyre1994 »

supermatt wrote: post #103
ruszki wrote: post #101

Earlier quoted context omitted.

The article explains how to style radio buttons with CSS however you want. What’s the problem with that?

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.

Out of interest what's an example of styling that the radix/shadcn version enables that their approach doesn't? I was able to (AFAICT) replicate the radix docs example by just moving their styles around: https://codepen.io/mcintyre94/pen/pvbPVrP
Post reply on HN