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.

▲

whackernews 6 hours ago | parent | next [-]

Well, usually, the reasons are to support every single use-case. A great selling point, but ultimately why I don’t like using things like this and importing loads of other libraries. Most of the code your importing is for some other user and any one app will probably be using a slither of the functionality.

I know if the lib is written well then you won’t be introducing unused code into your code base but you still often are left with an overly complex scaffold or other infrastructure to support all the stuff you’re not using. Just use a radio button for gods sake.

▲

Alupis 7 hours ago | parent | prev | next [-]

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

▲

chrismorgan 7 hours ago | parent [-]

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 <input type=radio>, 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 reason that HTML has <fieldset> and <label> as different things. The implementation is also trivially incorrect: role=label isn’t a thing. Other parts of it are wrong or dubious too. In general, if the HTML way of expressing something isn’t permitted, the ARIA way of expressing the same thing is probably wrong too.

And so it goes, through the entire system. They assume you might want something ridiculously complex, and so they complicate and make worse the normal case.

▲

sam_lowry_ 2 hours ago | parent [-]

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

	▲	chrismorgan 2 minutes ago \| parent \| next [-]
		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).
	▲	stephenr an hour ago \| parent \| prev [-]
		Quite an ironic use of the word "fix" there.

▲

snowmobile 6 hours ago | parent | prev | next [-]

"There are reasons" is a pretty bland defense of why something was done in a bad way. You'd have to show that the reasons are valid, which I highly doubt. Also, somebody spending thousands of hours on making a worse version of something existing, isn't a good justification either. That's on the level of counting lines of code as a measure of productivity.

▲

pftburger 7 hours ago | parent | prev | next [-]

Can here to say this exactly. Not saying they don’t raise an interesting point but the complete lack of curiosity why a group of experts in simplicity and accessibility decided to take this path is jarring

	▲	stephenr 7 hours ago \| parent [-]
		> a group of experts in simplicity and accessibility According to who? This alone is a pretty damning case against such a claim.

▲

ErroneousBosh 6 hours ago | parent | prev | next [-]

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 <input> field, except it takes around ten seconds to draw and then doesn't work properly?

▲

stephenr 7 hours ago | parent | prev [-]

I mean, that much is obvious just based on casual reading of a few articles/discussions about "modern" front-end dev.

I am 100% convinced that "Modern" front end developers are in fact, afraid of CSS and HTML. Like, "it will steal my eyeballs and look back at my face with them" scared.

Nothing else explains things like this, tailwind, JSX components, etc. Nothing. There is no explanation besides absolute morbid fear of the underlying technology - because the browser support has improved immensely but apparently they're all deathly scared of using it.

Before you tell me that I don't know what challenges these problems solve: I was primarily doing front-end development.... 20ish years ago. One of my first jobs in the space was adapting the client side code for a J2EE app - mostly this meant removing an IKEA worth of tables and using CSS - in IE6 of all fucking things. Subsequently I created reusable UI frontend components (i.e. output some HTML, maybe this little bit of corresponding JS, you'll get a usable interactive components in a browser) for two different organisations.

I have said it before and I'll say it again. I think JavaScript developers heard about (or saw over someone's shoulder) how J2EE guys had ant/etc build toolchains, and had abstraction like FactoryFactoryImplementationFactoryBuilderFactory and said HEY THAT LOOKS COOL, and if it's harder to understand they can't fire me!!

It's like NIH syndrome but for an entire community of people whose primary goal is chasing the shiny, followed closely by resume padding.

	▲	antisol 7 hours ago \| parent [-]
		well said!