Live data from Hacker News

The Overcomplexity of the Shadcn Radio Button

paulmakeswebsites.com

241–250 of 351 posts

Re: The Overcomplexity of the Shadcn Radio Button

#241
post #86
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…

> when all someone knows is React or other frameworks, things get overengineered The next level annoyance is that everybody just assumes React to be the default for everything. Check the Shadcn website. The landing page doesn’t mention that this is a React-only UI library at all. Same with Radix. The marketing sounds like a general-purpose UI lib. You gotta dig around a bit to realize that this is React-only.

For pure HTML pages I use Basecoat which is shadcn without React: https://basecoatui.com/

Re: The Overcomplexity of the Shadcn Radio Button

#242
post #59

This radio selection is brilliant silly, especially because the end result is indecipherable from a vanilla css rqdio button. For some reason people keep going back to complex UI and interactivity frameworks though, does anyone have a good example of a large website built without all this bloat? Asking because I've seen hundreds of small sites built with elegance and simplicity, and few large ones. Is it just inevita…

https://www.mcmaster.com 2022 post about it. 1400 points. ~500 comments: https://news.ycombinator.com/item?id=32976978

I would recommend comparing to

https://next-faster.vercel.app/

NextFaster feels faster than McMaster IMHO

Re: The Overcomplexity of the Shadcn Radio Button

#243

Earlier quoted context omitted.

i’ve tried this, and it almost almost works to just rebuild the Dom on every state change as a pure function of state without any react or anything. The resulting interface is actually way snappier than react – but preserving local state of elements like what text is highlighted, where the cursor is, which radio button is tabbed to etc turns into a nightmare.

Based on your description it sounds like you were halfway into reimplementing the virtual dom that react uses (or use to use? unsure if they moved away from that with the implementation of a compiler).

Yep. The “I’m sick and tired of of X (re-implements X)” cycle haunts me- I think I’m the wrong mix of picky, whiny and industrious

Re: The Overcomplexity of the Shadcn Radio Button

#244
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…

FWIW I've been writing UIs using plain JavaScript and the DOM API for like 15 years and at a certain scale, I always ended up building an ad-hoc framework or being disgruntled when I had to reach for any of the pre-React UI frameworks whose APIs and approaches I didn't like. React changes this, nowadays I either start with pure DOM and then rewrite to React or just start with React. I see a lot of hate online for Rea…

Not everything needs to be a SPA. I genuinely believe that the web would've been a much better place today on most important metrics (performance, simplicity, accessibility etc.) if this SPA shift would've never happened. The opportunity cost seems massive to me.

Re: The Overcomplexity of the Shadcn Radio Button

#245

Earlier quoted context omitted.

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. React gives you boxes to put stuff into but you decide what to put into them. Then React ensures that you can change what’s in those boxes without breaking anything. That’s the power of component abstraction.

> That’s the power of component abstraction. Yes. But React isn’t the only way to do components. Unfortunately, to the inexperienced, it is.

What are some much better ways to do components?

React with is so prevalent because it's a deep local optimum.

Re: The Overcomplexity of the Shadcn Radio Button

#246
post #235

Earlier quoted context omitted.

The only that is annoying to style is the “select” one because it’s hard to style the “options”. The rest seem reasonable and quite customizable in my experience.

And even select is fully customisable now if you're targeting modern browsers

really? how?

Re: The Overcomplexity of the Shadcn Radio Button

#248
post #28

Earlier quoted context omitted.

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

I think accessibility is one area where some of these components libraries can be helpful as they automatically include a11y features that might otherwise be ignored.

Re: The Overcomplexity of the Shadcn Radio Button

#250

The shadcn radio button in action: https://ui.shadcn.com/docs/components/radio-group

For some reason it's exceptionally slow for me on chromium. I click and I see it register half a second later. It also has no cursor:pointer which makes it look non-clickable. Is it expected or a bug?
Post reply on HN