[flagged]
If all you have to contribute is being insulting, you don't have to comment.
The Overcomplexity of the Shadcn Radio Button
41–50 of 351 posts
Re: The Overcomplexity of the Shadcn Radio Button
#42[flagged]
Go on, then. Point them out.
As it is, you've joined the ranks of multiple others commenters who sound like cargo cultists, attacking OP for not understanding frontend dev without actually pointing out any issues in their writing. If it's easy to point out, then surely you can show how easy it is.
Re: The Overcomplexity of the Shadcn Radio Button
#43It has to be this way because we (the collective we) refuse to agree on adding proper UI primitives to the web.
We’re like 20+ years into web apps being a big thing and there’s still nothing like what’s offered in OS-native frameworks like Swift.
So anybody building a web app has to recreate SwiftUI in the browser every time via various bloated hacks (basically what Shadcn is).
If we could just agree on adding non-terrible cross-browser primitives for multiselect, popovers, modals, proper radio buttons, tabs, etc to the HTML spec and allow extensive CSS styling on every part of the element we could avoid these massive UI frameworks.
Re: The Overcomplexity of the Shadcn Radio Button
#44[flagged]
Re: The Overcomplexity of the Shadcn Radio Button
#45Earlier quoted context omitted.
Where do you draw the line tho? How many kilobytes and how much future maintenance work is avoiding a potential slight visual inconsistency with a radio button worth? Is it worth to lose the x amount of people who have bad network connection? Use this approach everywhere and the actual content of the page (you know: the stuff people came for) suffers. All I can think about is a quote by world famous video artist Nam…
Based on profits of many webapps, there is no line. What eng here forget is that they are oft not the targeted consumer. The hypothetically perfect website doesnt sell as well as a colorful fat choncker does. It is like fast food, not every cares about farm to table.
> It is like fast food, not every cares about farm to table
I mean, a "colorful fat choncker" website is literally the opposite of fast food - its slower to arrive, and focuses way too much on appearances.
In this analogy, the website using these ridiculous abstractions is more like Salt Bae or whatever idiotic trend has replaced him. All glitz, zero substance, slower, and for no apparent reason.
The fast food equivalent is stuff like the Google home page: it doesn't validate, is actively harmful to you, the community, and the planet but is immensely popular.
Re: The Overcomplexity of the Shadcn Radio Button
#46Earlier quoted context omitted.
Where do you draw the line tho? How many kilobytes and how much future maintenance work is avoiding a potential slight visual inconsistency with a radio button worth? Is it worth to lose the x amount of people who have bad network connection? Use this approach everywhere and the actual content of the page (you know: the stuff people came for) suffers. All I can think about is a quote by world famous video artist Nam…
Based on profits of many webapps, there is no line. What eng here forget is that they are oft not the targeted consumer. The hypothetically perfect website doesnt sell as well as a colorful fat choncker does. It is like fast food, not every cares about farm to table.
Except the correct way can be just as colorful, and it takes more effort to implement the bad way.
Re: The Overcomplexity of the Shadcn Radio Button
#47Well 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, that's true. I oversimplified.
Re: The Overcomplexity of the Shadcn Radio Button
#48Earlier quoted context omitted.
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.
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…
well said!
Re: The Overcomplexity of the Shadcn Radio Button
#49I normally share the sentiments of the article. But I am also curious, if the goal was: - Implement the radio as the designer sent in the figma file (e.g. something like the radix demo one they're commenting on: https://www.radix-ui.com/primitives/docs/components/radio-gr... ) - Make sure it looks the exact same across all browsers How doable is it with vanilla css? The example they gave was rendered to a black/white…
> - Make sure it looks the exact same across all browsers > How doable is it with vanilla css? It's not doable with your fancy frontend framework and your 20 imports and your ten thousand lines of typescript. "Make sure it looks the exact same across all browsers" is, and always has been, fundamentally at odds with how the web is intended to work. How well does this shadcn crap render in arachne? ladybird? netsurf? l…
Particularly given that on a screen reader -- which yes is an example of a browser -- it doesn't "look like" anything at all
Re: The Overcomplexity of the Shadcn Radio Button
#50The shadcn radio button in action: https://ui.shadcn.com/docs/components/radio-group
This interactivity definitely adds a wow effect.
In a hilarious turn of fate, on iOS safari the first time one of the radio options is clicked after loading, the css focus style is applied, but a click is not always registered so the radio item ends up stuck in an invalid weird-looking state. I highly doubt the issue would occur if the built in radio were being used