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

321–330 of 351 posts

Re: The Overcomplexity of the Shadcn Radio Button

#321

Post by shimman »

paulhebert wrote: post #298
virtujoel wrote: post #201

Earlier quoted context omitted.

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?

They do, most issues that arise from making things accessible are self inflicted. Some people just want to redesign things for the sake of design while ignoring a core principle of design (accessibility) over aesthetics.

Sounds harsh but maybe somethings SHOULDN'T be designed a certain way because it breaks a11y when there are other roads to be taken that can still look pleasant, be accessible, and way easier to maintain (less brittle JS to worry about).

Re: The Overcomplexity of the Shadcn Radio Button

#322

Post by shimman »

SahAssar wrote: post #317
shimman wrote: post #237

Earlier quoted context omitted.

You aren't using it wrong, the only thing tailwind does better than 99% of devs is having default values that both look nice and mesh together well. Utility based CSS has been around as long as classes have, tailwind is just one iteration of that. GitHub use to have a utility css library as well before switching to their new design.

> having default values that both look nice and mesh together well. So 99% of the value can be achieved with strict linting and autocomplete plugins.

Yes? I don't think anyone has ever argued that tailwindcss has a moat on anything, it has always been championed as a library created by a designer + dev who care about good UI design.

At least that's how I always seen it billed as, even when Adam was live streaming and saying as much in like 2018/2016.

Re: The Overcomplexity of the Shadcn Radio Button

#323

Post by paradox460 »

lucumo wrote: post #273
stavros wrote: post #174

Earlier quoted context omitted.

I really don't understand Tailwind. I heard great things about it, and then I tried it and it seemed like setting style="" on all elements, but with extra steps. Did we go off semantic CSS and returned to setting properties on each element, or was I using it wrong?

Plain CSS is very useful if all you have is an HTML page. Giving all buttons a consistent look is nice and easy if you can just specify that with a nice CSS selector. That's also the only place you can do it without changing all tags. If you're building a component-based UI, that need is less, because all your buttons are created in a specific Button component. That's also an easy place to attach styling. You don't e…

Why not scope your styles in the component, using either a css in js approach, like Vue, Svelte, and surface do, or use the modern css @scope property?

Re: The Overcomplexity of the Shadcn Radio Button

#324

Post by jauntywundrkind »

elktown wrote: post #244
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…

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.

I don't find litigating this to be useful or interesting. Debating what is needed could show us lots of things we could cut. But would that bring real gain?

SPA's have really nice performance characteristics. Code is all loaded. The page can transition between states rather than total redraw. A good SPA should offer the same capabilities too, ought have URL routing and good history support.

I do think the web would be faster and simpler without SPAs. But it wouldn't be anywhere near as capable, as interesting, and as loved.

Re: The Overcomplexity of the Shadcn Radio Button

#325

Post by ChromaticPanic »

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.

The react dev tools browser extensions deal with this pretty well. Not sure what the issue is. You can even inspect all the props.

Re: The Overcomplexity of the Shadcn Radio Button

#326

Post by fireant »

simlevesque wrote: post #241
WA wrote: post #86

Earlier quoted context omitted.

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

But that's just classically styled library like bootstrap? How is it in any way similar to shadcn where you copy the component definitions to your code and restyle them with tailwind? It looks visually similar, but completely misses the point of why someone would use shadcn. Also many of the components have degraded functionality on firefox, I couldn't use this in an actual production application.

Personally I also tend to hate on what React has made the modern web, and I say this as someone who's made money for the past 10 years making React apps, but reimplementing half of something poorly and declaring success because it looks kinda similar when you squint is just silly. Many (most?) "pure html frameworks" are like this unfortunately.

Re: The Overcomplexity of the Shadcn Radio Button

#327

Post by smrq »

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.

Vue and Svelte both introduce too much mystery-symbol syntax for my taste, and two way data binding has felt bad since Angular 1.

Re: The Overcomplexity of the Shadcn Radio Button

#328

Post by charrondev »

archerx wrote: post #165
christophilus wrote: post #161

Earlier quoted context omitted.

The date picker still sucks.

I admit I haven’t had to use the date picker in a long time but I looked at the MDN for an example of the default implementation of it and it seemed fine on my iPhone. What issues have you encountered with it? I imagine it’s a different story on desktop browsers.

It’s been good on mobile for a while, and it’s a travesty on desktop.

Then if you want something a little bit complicated you have to do it all yourself.

- What if I need a date range instead of a single date? - What if I have excluded dates? (Only weekdays/only in the future/blackout dates) - What if I want to show other metadata with each day? (Like in a calendar showing each day with some metadata next to it)

Beyond “give a whatever the system thinks is a good date picker that I have no control over” the input with type date isn’t very useful.

Re: The Overcomplexity of the Shadcn Radio Button

#330

Post by Sateeshm »

kaelwd wrote: post #329
mastermedo wrote: post #6

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

Straight up doesn't even register clicks or keyboard focus for me in firefox.

Same in chrome on Android. They work if I switch to Base UI tab and back.
Post reply on HN