alt Hacker NewsExactly 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.
Replies
Perhaps this is the original PR for the Radio/RadioGroup[1].
It does seem the complexity was a deliberate decision.
"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.
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
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?
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.
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.