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

131–140 of 351 posts

Re: The Overcomplexity of the Shadcn Radio Button

#131

Post by cadamsdotcom »

A html forms based radio button is worse than a complex - but standard - shadcn radio button many ways that matter in the real world.

Why does no one do the simpler thing? Because there’s no extra value to it, and it in fact has negative value because then the team has to write and understand it and the rationale for the departure from just using the same component library everywhere.

“Only a few kb of javascript” may as well ZERO javascript, and because of that it’s not even close to the top thing to optimize on your favorite site.

So, you engineered a non-standard radio button that is different to the rest which all use shading?? Why weren’t you building features that you know.. make money?

Re: The Overcomplexity of the Shadcn Radio Button

#132

Post by whstl »

supermatt wrote: post #103
ruszki wrote: post #101

Earlier quoted context omitted.

The article explains how to style radio buttons with CSS however you want. What’s the problem with that?

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.

Wrapping it in a label is the idiomatic and correct way, and should be done even when not styling. Perhaps especially when not styling.

Putting an adjacent label is also possible, but scales poorly due to needing unique ids.

Re: The Overcomplexity of the Shadcn Radio Button

#133

Post by jcgl »

Tade0 wrote: post #127
jcgl wrote: post #113

Earlier quoted context omitted.

Yeah, as a solo dev quite new to frontend, that made me nope out of React almost immediately. Having to choose a bunch of critically important third-party dependencies right out of the gate? With how much of a mess frontend deps seem to be in general? No thanks. I settled on Svelte with SvelteKit. Other than stumbling block that was the Svelte 4 -> 5 transition, it's been smooth sailing. Like I said, I'm new here in…

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.

Re: The Overcomplexity of the Shadcn Radio Button

#134

Post by snowmobile »

cadamsdotcom wrote: post #131

A html forms based radio button is worse than a complex - but standard - shadcn radio button many ways that matter in the real world. Why does no one do the simpler thing? Because there’s no extra value to it, and it in fact has negative value because then the team has to write and understand it and the rationale for the departure from just using the same component library everywhere. “Only a few kb of javascript” ma…

How's using a custom library any way close to "standard"? How about the actual HTML standards? The whole reason you'd use "shadcn" is that customizing the actual HTML radio button isn't enough for you. Otherwise, if you just want a default-looking button, here you go:
If your team can't understand that, how are they going to understand a few KB of JS? Or maybe they're not supposed to understand it, but how can you then guarantee to your customers there isn't a crypto miner or tracker or something in that? Or perhaps you care more about "making money" than protecting your customers from such things?

Re: The Overcomplexity of the Shadcn Radio Button

#135

Post by realusername »

Tade0 wrote: post #127
jcgl wrote: post #113

Earlier quoted context omitted.

Yeah, as a solo dev quite new to frontend, that made me nope out of React almost immediately. Having to choose a bunch of critically important third-party dependencies right out of the gate? With how much of a mess frontend deps seem to be in general? No thanks. I settled on Svelte with SvelteKit. Other than stumbling block that was the Svelte 4 -> 5 transition, it's been smooth sailing. Like I said, I'm new here in…

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.

Even when it's the same router package, these things break backward compatibility so often that different versions of the same package will behave differently

Re: The Overcomplexity of the Shadcn Radio Button

#136

Post by throwaway5465 »

smartmic wrote: post #84
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…

You make a good point. From a philosophical point of view, abstractions should hide complexity and make things easier for the human user. It should be like a pyramid: the bottom layer should be the most complex, and each subsequent layer should be simpler. The problem is that many of today's abstractions are built on past technology, which was often much better designed and simpler due to the constraints of that time…

> divergent complexity of today's abstractions

The vast majority of websites and apps do not have complex divergent abstraction needs.

Some developers however require complex divergent abstractions in order to baffle brains and collect paycheck.

Re: The Overcomplexity of the Shadcn Radio Button

#137

Post by Bewelge »

smartmic wrote: post #84
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…

You make a good point. From a philosophical point of view, abstractions should hide complexity and make things easier for the human user. It should be like a pyramid: the bottom layer should be the most complex, and each subsequent layer should be simpler. The problem is that many of today's abstractions are built on past technology, which was often much better designed and simpler due to the constraints of that time…

I'm struggling to form a definitive statement about my thoughts here, but I'll give it a try:

Every (useful) abstraction that aims to make an action easier will have to be more complex inside than doing the action itself.

Would love for someone to challenge this or find better words. But honestly, if that's not the case, you end up with something like leftPad. Libraries also almost always cover more than one use case, which also leads to them being more complex than a simple tailored solution.

Re: The Overcomplexity of the Shadcn Radio Button

#138

Post by dylmye »

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.

I much prefer React Aria's components. Yes fuck Adobe but take their RadioGroup for example: https://react-aria.adobe.com/RadioGroup Much better than shadcn's in terms of deps and LOC, and it uses an input. All of their components are built for accessibility first.

Re: The Overcomplexity of the Shadcn Radio Button

#139

Post by strogonoff »

realusername wrote: post #82
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 also have the same somewhat controversial opinion, the frontend community wasn't ready and (still isn't) to organise a functional codebase. The second problem is that React has a "draw the rest of the owl" mindset. Sure you have nice frontend components but now what about caching? data transfers? static rendering? bundle size & spliting? routing?

The reason for React’s “draw the rest of the owl” (which is a great way to describe it) mindset is that it’s born not as a framework but as a library, and to this day self-identifies as such. It by design tells you nothing about and is agnostic with respect to how you organise your code, where to put tests, what bundler to use, etc.

IIRC React itself doesn’t even know anything about the Web or DOM, as that integration is supplied by the pluggable reconciler, which lives in a separate library (ReactDOM).

One could argue that with the amount of batteries included perhaps it ought to undergo a grand status change, but until then it’s hard to blame on the authors of a library that they are not delivering a framework.

Re: The Overcomplexity of the Shadcn Radio Button

#140

Post by azangru »

tiborsaas wrote: post #116
teaearlgraycold wrote: post #53

Earlier quoted context omitted.

Worse still is the misunderstanding that React is simple. It’s an endless stream of cache invalidation bugs. Linters are getting better at catching these. But they also have false positives.

What is cache in this context? useState? What do you mean by cache invalidation in react apps?

Stale closures, perhaps.
Post reply on HN