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

291–300 of 351 posts

Re: The Overcomplexity of the Shadcn Radio Button

#291

Post by jakubmazanec »

Surac wrote: post #30

Im not in web development. Reading this article makes me think: is it realy neccersary to use all those complex frameworks? Isn't html/css enough? People always say "every line not written can't be a bug" but moving those lines into a library was not the idea behind the words

If you're not into web development, Hacker News discussions about React are really bad way to gain unbiased perspective - it's been really popular here for last few years to just hate React (usually they know nothing, e.g. anyone who claims hooks compose worse than class components). But there's a reason why React is still used the most (large ecosystem, fast development and backwards compatibility). Of course, it's easy for inexperienced developer to produce slow and buggy apps (maybe slightly easier than in other frameworks, but that's practically unquantifiable), to include unnecessary or even badly written dependencies, etc. - but it's not the tool's fault when it's being used incorrectly.

Re: The Overcomplexity of the Shadcn Radio Button

#292

Post by 12_throw_away »

freetonik wrote: post #107
curtisblaine wrote: post #57

Earlier quoted context omitted.

> Isn't html/css enough? No, obviously. If you are writing complex web applications with state, local processing of data and asynchronous interactions it's not enough. You need javascript. If your javascript is especially complex and you desire it to be declarative, you probably need a framework. Do you need, I don't know, Tomcat in Java? Probably yes for a complex application and no for a simple proof of concept. Do…

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

> I really don't understand this desire to make websites behave like local apps while in reality they aren't.

Since the dawn of time, humans have sought to eliminate mushy laggy UIs, such as having to wait for a full page reload whenever you click a button. I don't like SPAs either, but dunno, I don't find it particularly hard to understand how we got here.

Re: The Overcomplexity of the Shadcn Radio Button

#294

Post by jwxz »

diordiderot wrote: post #242
hu3 wrote: post #59

Earlier quoted context omitted.

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

~$500 for hosting that site feels insane to me [0]. I feel like a single $10 VPS could handle that load.

[0] https://github.com/ethanniser/NextFaster?tab=readme-ov-file#...

Re: The Overcomplexity of the Shadcn Radio Button

#295

Post by onli »

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.

And how is the surrounding JS code, like the event handlers, and the CSS of the component supposed to still work now? A radio input will need at the very least additional CSS to remove the native appearance. Unlikely that was set already --> it's not that easy.

Re: The Overcomplexity of the Shadcn Radio Button

#296

Post by davely »

thedelanyo wrote: post #284
davely wrote: post #258

Earlier quoted context omitted.

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…

> and have genuinely enjoyed it. People who haven't work with other frameworks like svelte, Vue - normally say they are enjoying React.

This is a bit reductive.

For what it’s worth, I’ve used Vue and don’t like it (stuff like custom directives that are nonstandard html, not as explicit about event handling and data flow, etc).

I’ve seen a lot of buzz (particularly on HN) about Svelte but have lacked the motivation to try it.

Re: The Overcomplexity of the Shadcn Radio Button

#297

Post by paulhebert »

supermatt wrote: post #214
ruszki wrote: post #119

Earlier quoted context omitted.

Can you give an example please? What kind of complexity are we talking about?

Any kind of nested markup: styled content, additional animation layers, etc.

Author here. Can you provide a screenshot or more detail?

I'd be happy to implement an HTML + CSS only solution and share it with you.

Thanks

Re: The Overcomplexity of the Shadcn Radio Button

#298

Post by paulhebert »

virtujoel wrote: post #201
CommonGuy wrote: post #141

I recently tried out https://daisyui.com/ (CSS only components, depends on tailwind) and so far I really like it. It also highlights how far browser have come with new features such as dialogs, which I always implemented with (a lot of) JavaScript in the past

This library doesn't appear to be accessible. Just looking at two random components: The Drawer ( https://daisyui.com/components/drawer/ ) doesn't trap focus inside itself (letting you tab to the page behind the drawer while it's open). The Accordion ( https://daisyui.com/components/accordion/ ) first example is using radio buttons as a hack to avoid Javascript, which would be very confusing to screen reader users (a…

> This is why there's so much complexity in libraries like Radix - accessibility in the real world usually requires a lot of Javascript.

I agree in many scenarios, but for the two you mentioned it seems like the and elements provide accessible solutions out of the box?

Re: The Overcomplexity of the Shadcn Radio Button

#299

Post by paulhebert »

parhamn wrote: post #10

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

Author here.

You can do pretty much any styling!

I did a basic example because that matches what Shadcn does (black/white circle) but you can customize it a lot more.

Re: The Overcomplexity of the Shadcn Radio Button

#300

Post by paulhebert »

xearl wrote: post #8

Did they ask the original authors of Radix why it's the way it is?

Author here: I tried to find answers in their docs but they don't provide any context. I expected to find an explanation of why to use their solution there but did not.

How would you suggest I reach out?

Post reply on HN