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

261–270 of 351 posts

Re: The Overcomplexity of the Shadcn Radio Button

#261

Post by RHSeeger »

tomashubelbauer wrote: post #232
ehnto wrote: 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…

Personally, I like to look at the source for a page. And that, for anything React, winds up being useless (). I find React very hard to debug whenever anything doesn't work as expected.

Re: The Overcomplexity of the Shadcn Radio Button

#262

Post by tomashubelbauer »

davely wrote: post #258
tomashubelbauer wrote: post #232

Earlier quoted context omitted.

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…

I work on a React based web app in my Day Job and have genuinely enjoyed it. That said, it always feels like so much boilerplate to get up and running for a greenfield project (and things like NextJS or even TanStack Start add a lot of things that might be overkill for a simple web app). For some vibe coded side projects with Claude, I’ve been working with just using handlebars templates with Express and it has been…

> it always feels like so much boilerplate to get up and running for a greenfield project

This is why I love Bun + React. The setup is so easy I can do it off memory. I always hated boilerplate, templates etc. so this is a huge selling point for me.

Re: The Overcomplexity of the Shadcn Radio Button

#263

Post by tomashubelbauer »

RHSeeger wrote: post #261
tomashubelbauer wrote: post #232

Earlier quoted context omitted.

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…

Personally, I like to look at the source for a page. And that, for anything React, winds up being useless ( ). I find React very hard to debug whenever anything doesn't work as expected.

I agree with this and consider this to be a massive downside to React.

Re: The Overcomplexity of the Shadcn Radio Button

#264

Post by jadbox »

ponyous wrote: post #159

Developers remember, you can always push back on design requirements instead of bringing in more bloat. I was sitting next to one of the devs in a co-working space and he was trying to figure out some specific layout issue in react native. He spent 4 hours + installed a dependency to be able to do something completely tiny on a privacy policy screen. He asked me how I would do it, I told him to just ask if it can be…

I'm finding it's better to use "javascript-less" UI frameworks [Pico.CSS, Skeleton, Bulma, Tailwind/daisyUI]. You get most of the benefits using good use of CSS. Anyone used these JS-free solutions and have recommendations?

Re: The Overcomplexity of the Shadcn Radio Button

#265

Post by lunar_mycroft »

hombre_fatal wrote: post #173
freetonik wrote: post #107

Earlier quoted context omitted.

>If you are writing complex web applications with state, local processing of data and asynchronous interactions it's not enough. >Next objection usually is: do you need complex apps on the client? It's not even an objection, it's a question I ask and almost never hear a coherent answer to. The vast majority of web applications I use every day (online banking, github, forums, social media, admin interfaces of various…

> it's a question I ask and almost never hear a coherent answer to. There are a lot of coherent answers though. One is that responding with HTML encumbers the server with brittle UI over the wire when it could instead be a simpler API server that any client can talk to. Returning data instead of UI from the server is a clean separation of concerns. There's nothing incoherent about that.

That's the theory. In practice, if your UI is changing a lot, the data your UI needs is also changing a lot, meaning that your data API will either have a lot of churn or you'll allow a lot of flexibility in how untrusted clients can use it, which introduces it's own pile of issues.

Re: The Overcomplexity of the Shadcn Radio Button

#266

Post by chuckadams »

wouldbecouldbe wrote: post #67
ehnto wrote: 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…

It was fine when it started, it's the addition of useEffect and hooks that messed everything up. Although normaly I prefer functional, for react classes were 100 times better

Hooks were fine, but their implementation in React was barkingly insane. Vue's notion of "composables" is very similar, but not dependent on order, so you can use them in conditional statements without breaking the world. I don't even want to think about doing a complex Vue app without the VueUse library.

Re: The Overcomplexity of the Shadcn Radio Button

#267

Post by NoGravitas »

dyeje wrote: post #226
ezst wrote: post #224

Earlier quoted context omitted.

React was built to satisfy the specific scaling and complexity needs of Facebook, and this CV-driven industry jumped on board with it pretending that what's good for Facebook is good for them. The incentives are completely misaligned: it's like nobody gains anything out of using the least amount of force and abstraction to solve a specific problem.

I did frontend before React, and it was a welcomed change. The core insight of UI being a function of state is a good one. It saves you a bunch of headaches from the jQuery days where you’d have multiple code paths per UI element (adding, removing, mutating). That said I think they lost the plot with hooks and things have gotten needlessly complex since then.

> The core insight of UI being a function of state is a good one.

We had that before, it was called HATEOAS.

Re: The Overcomplexity of the Shadcn Radio Button

#268

Post by sam_lowry_ »

chrismorgan wrote: post #251
sam_lowry_ wrote: post #213

Earlier quoted context omitted.

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

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

Am I?

I was just quoting the React creator.

Re: The Overcomplexity of the Shadcn Radio Button

#269

Post by sam_lowry_ »

danabramov wrote: post #260
daveidol wrote: post #240

Earlier quoted context omitted.

The parent comment is seemingly blaming React for the decisions of Shadcn for some reason. There’s nothing about React that requires you to overcomplicate your DOM (unlike many other UI frameworks).

The point I wanted to emphasize is that even if you do overcomplicate your DOM, the component abstraction is what allows you to fix it in one place . Don't like what's in your component — add `return `, bam! It's fixed across the entire app now.

Which also allows to create an overcomplicated jack-of-all-trades component? After all, it's fun and can be justified via the "write once" argument.

Re: The Overcomplexity of the Shadcn Radio Button

#270

Post by jwr »

uxcolumbo wrote: post #117
jwr wrote: post #78

Incidentally, radio buttons are a (sadly) forgotten art and are neglected in modern browsers. There are many issues with them, which is why people reimplement them on their own.

Can you provide more details about the issues?

Not really, because I no longer remember. I only remember bugs and frustration. But I looked at my code quickly and found this:

;; Let's render radio buttons ourselves. Because of bugs in React and Chrome, radio buttons mysteriously stop working.

;; https://stackoverflow.com/questions/48423061/radio-buttons-n...

;; https://github.com/facebook/react/issues/3446

followed by my own implementation of radio buttons, followed by:

;; Original implementation, to be used when radio buttons actually work:

followed by an implementation using an input of type radio, commented out.

Post reply on HN