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

91–100 of 351 posts

Re: The Overcomplexity of the Shadcn Radio Button

#91

Post by dreadnip »

curtisblaine wrote: post #57
Surac wrote: post #30

Im not in web development. Reading this article makes me think: is it realy neccersary to use all those complex frameworks? Isn't html/css enough? People always say "every line not written can't be a bug" but moving those lines into a library was not the idea behind the words

> Isn't html/css enough? No, obviously. If you are writing complex web applications with state, local processing of data and asynchronous interactions it's not enough. You need javascript. If your javascript is especially complex and you desire it to be declarative, you probably need a framework. Do you need, I don't know, Tomcat in Java? Probably yes for a complex application and no for a simple proof of concept. Do…

Most web apps are a combination of static pages, simple forms and highly interactive content though. That's what makes the choice so hard.

Re: The Overcomplexity of the Shadcn Radio Button

#92

Post by nake89 »

shubhamjain wrote: post #18

This is the reason I absolutely hate shadcn. The number of dependencies and files you introduce for trivial components is insane. Even tiny little divs are their own component for no good reason. I genuinely don’t understand how front-end developers accept this level of needless complexity. Shoutout to Basecoat UI[1], so implementing the same components using Tailwind and minimal JS. That's what I am preferring to us…

Another shoutout to Basecoat. Easy to use. Makes your website look nice. Works with any/no framework.

Re: The Overcomplexity of the Shadcn Radio Button

#93

Post by ErroneousBosh »

leoff wrote: post #13
xearl wrote: post #8

Did they ask the original authors of Radix why it's the way it is?

Exactly this. OP fails to understand that there are reasons why it was done this way, and that someone who spent thousand of hours working on this might know something that they don't.

Okay, what exactly are those reasons?

Why does it need so much complexity to draw a radio button that doesn't look all that different to the normal one you'd get with a perfectly ordinary field, except it takes around ten seconds to draw and then doesn't work properly?

Re: The Overcomplexity of the Shadcn Radio Button

#95

Post by snowmobile »

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 inherent complexity

Well, this is true in a sense, but it's not exactly a good argument for re-implementing all that complexity in JS / HTML, instead of simply using the browser's implementation that's written in a real language.

Re: The Overcomplexity of the Shadcn Radio Button

#96

Post by invalidusernam3 »

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…

Agree, this kind of complexity is there for a reason. I would rather have a complex component that handles all the cases within its usage in the codebase over having a bunch of little hacks/changes in the usage. It's far easier to maintain one complex component than many different usages of that component.

And you don't have to use such a complex component library if you don't need it. For small codebases it often is overkill. But for large codebases it's a massively worthwhile investment.

Re: The Overcomplexity of the Shadcn Radio Button

#98

Post by yen223 »

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.

Re: The Overcomplexity of the Shadcn Radio Button

#100

Post by spiderfarmer »

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.

> bear in mind that the default radio button has poor usability for mobile users

Wrap it in a label, give the label a padding. Boom!

Post reply on HN