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

201–210 of 351 posts

Re: The Overcomplexity of the Shadcn Radio Button

#201

Post by virtujoel »

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 (announcing the radio buttons to them).

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

Re: The Overcomplexity of the Shadcn Radio Button

#202

Post by Tade0 »

jcgl wrote: post #133
Tade0 wrote: post #127

Earlier quoted context omitted.

I've been doing frontend since 2012 and I still don't understand why React became so popular. No two React projects are the same. Like, even the router has at least three different mainstream options to choose from. It's exhausting.

That router thing seems crazy. I'm all for having options that are available . But not having, at the minimum, some blessed implementations for basic stuff like routers seems nuts. There is so much ecosystem power in having high-quality, blessed implementations of things. I'm coming from working primarily in Go, where you can use the stdlib for >80% of everything you do (ymmv), so I feel this difference very keenly.

> There is so much ecosystem power in having high-quality, blessed implementations of things.

Indeed. I work mainly in Angular because while it's widely regarded as terrible and slow to adapt, it's predictable in this regard.

Also now with typed forms, signals and standalone components it's not half bad. I prefer Svelte, but when I need Boring Technology™, I have Angular.

90%+ of all web apps are just lists of stuff with some search/filtering anyway, where you can look up the details of a list entry and of course CRUD it via a form. No reason to overthink it.

Re: The Overcomplexity of the Shadcn Radio Button

#203

Post by nobleach »

kaizenb wrote: post #123

I use shadcn/ui for side projects, mostly coding with agents. Good to have a base design system for building products. Are there any alternatives? Coded systems, not just UI components.

Yup, agents LOVE Tailwind+ShadCN. Even when I've explicitly told them not to use it, it still creeps in. There's a lot of prior art out on GitHub and LLMs can't help themselves. FWIW, the result does tend to look nice enough. For a POC I can't complain. If I'm really going to roll up my sleeves and get into the code though? I don't think I'd enjoy all of it.

Re: The Overcomplexity of the Shadcn Radio Button

#204

Post by supermatt »

mcintyre1994 wrote: post #120
supermatt wrote: post #103

Earlier quoted context omitted.

It doesn’t. It gives a very naive approach that doesn’t support any complex styling. For that you need to wrap the input and additional styling elements in a ref’ed label.

Out of interest what's an example of styling that the radix/shadcn version enables that their approach doesn't? I was able to (AFAICT) replicate the radix docs example by just moving their styles around: https://codepen.io/mcintyre94/pen/pvbPVrP

In the example they are just using an empty for the pip as it is easy to target with a classname, but you can put any content in there instead for e.g. card-style radios (as used for complex selections, like a subscription tier).

By using radix, the underlying behaviour is compliant and identical for each of those implementations - you just change the content. Radix isn't looking at it like an html radio element, it is looking at it as a completely unstyled unique item selector.

The pseudo-element styling approach limits you to 3 layers - the container, and the 2 pseudo elements, none of which you can provide with meaningful content besides plain text. The best you can do is provide a basic styles and set background image. For anything else you need to use labels to either wrap the radio (in which case you can access state via sibling selectors) and/or ref them with "for" (in which case you cant access the state).

Re: The Overcomplexity of the Shadcn Radio Button

#205

Post by milutinovici »

normie3000 wrote: post #97
jackfranklyn wrote: post #44

[flagged]

> I've watched teams spend weeks just getting comfortable with component library internals Would a good library allow developers to ignore internals and get on with higher-level stuff?

It would. But even then, it would still bloat your html/JavaScript and tank your Lighthouse score

Re: The Overcomplexity of the Shadcn Radio Button

#206

Post by mejutoco »

yoz-y wrote: post #111
wouldbecouldbe wrote: post #67

Earlier quoted context omitted.

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

I know people love to make UIs stateless and functional. But they just aren’t. IMO UIs are fundamentally a bunch of state, graphically represented. So naturally all of the functional frameworks are full of escape hatches. I’d rather have a honest framework than a chimera. I have not followed SwiftUI recently but when it was introduced I quite liked to have the main composition in SwiftUI and then writing more complex…

> I know people love to make UIs stateless and functional. But they just aren’t. IMO UIs are fundamentally a bunch of state, graphically represented. So naturally all of the functional frameworks are full of escape hatches.

Functional does not mean no state, just constraining state to inputs and outputs. Breaking that is a choice, and not good design.

Elm, for example, provides all of that with one escape hatch: ports. It is really well-defined and that not fall into any of the impossibilities you mention.

Re: The Overcomplexity of the Shadcn Radio Button

#208

Post by bromuro »

I don’t see the “complexity” the author is yelling about. Maybe is the tailwind verbosity?

It seems they don’t understand the underlying requirements when building a reusable UI library. Yes in shadcn there are some opinionated choices , but the “i can do better/ i am smarter” attitude of this article is off putting.

We used shadcn in one project , and wrote a custom UI library for another (using the same “smart trick” for input elements). Shadcn wins for clarity, consistency, maintenanility and simplicity.

Re: The Overcomplexity of the Shadcn Radio Button

#209

Post by stevepotter »

Piraty wrote: post #191

> Web development is hard. no it's not. you all make it hard by bloating your sites with Jenga tower abstractions for styling, needlessly load content dynamically via Jenga tower javascript libraries that pulls complexity into frontend and most of the time puts unnecessary load on the content generator ("backend") too. I don't know a lof of sites where that actually makes sense, as web === text. When html5 came about…

I don't think it's hard, it's harder than people think it's going to be. So they get frustrated and start abstracting away, ignoring history and hoping their fresh approach will finally make this thing easy.
Post reply on HN