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

151–160 of 351 posts

Re: The Overcomplexity of the Shadcn Radio Button

#151

Post by vachina »

snowmobile wrote: post #134
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 th…

You should not look at the button in isolation. The library is likely used to do other things vanilla HTML cannot do, but instead of maintaining multiple code, they just use the library to implement everything.

The library has in essence became an interface for developers to build for.

Re: The Overcomplexity of the Shadcn Radio Button

#152

Post by danabramov »

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…

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.

React gives you boxes to put stuff into but you decide what to put into them. Then React ensures that you can change what’s in those boxes without breaking anything. That’s the power of component abstraction.

Re: The Overcomplexity of the Shadcn Radio Button

#153

Post by tmvnty »

So for a React developer who doesn't want to include Shadcn/Radix, but also doesn't have time to build every component/a11y/compat/edge cases from scratch, what are the better alternatives?

Would be nice to list them here so developers can know a midpoint between DIY Shadcn/Radix

Re: The Overcomplexity of the Shadcn Radio Button

#154

Post by strogonoff »

realusername wrote: post #149
strogonoff wrote: post #145

Earlier quoted context omitted.

Did it not work? Many successful and complex sites and apps use React—whether directly or via a framework (Next, Astro, or something homegrown)—and indeed many frameworks are built on React. > math tools or pdf generation In this case the original scope of the library was “reactive rendering”, which sort of makes sense.

I've been there since the early days of React and I haven't seen a single React codebase which isn't a pile of duck-taped random packages, often leading to poor user performance. Maybe it can be done, maybe not, but the average front-end dev doesn't have the insights to fill the gaps that React has left.

Some codebases are better than others, more mature open-source projects tend to be more polished, closed enterprisey things can be nightmare fuel, but that’s all probably universal to a degree and not specific to whether you’re using React or not. (OK, dependency mess is at least somewhat specific to JS.)

My real development experience started with Django—arguably one of the best-documented proper frameworks out there even before it reached 1.x—and let me tell you: the kind of garbage I have seen once I started doing it professionally still makes me shudder[0].

I agree with you in the sense that the choice to forgo a framework and use only a bunch of libraries directly should be very carefully considered. Frameworks exist for a reason. The decision should be made with the full understanding that one would implicitly undertake a task to create a framework (even if it is a narrowly specialised one just for that project). A lot of what you do if you go with raw React will not actually be front-end development: prepare to be vetting dependencies for (or implementing yourself) very basic functionality, fighting bundlers, trying to get TS to use correct global typings for the context, managing version hell to get all of the above to interoperate, etc.

(By the way, any mistake you make will be on you. Picked a test runner that was discontinued? Some transitive dependency got hijacked? There is no one else to blame. There’s no BDFL and expert core dev team vetting things, knowing when and how to write from scratch if there’s no trustworthy third-party implementation, orchestrating working version combinations, or writing migration guides.)

[0] Indeed it would be hubris to claim I myself have never ever architected something I would later call a monster held together with bits of duct tape.

Re: The Overcomplexity of the Shadcn Radio Button

#155

Post by troupo »

chrysoprace wrote: post #115
scoot wrote: post #15

Earlier quoted context omitted.

> everything lives in your own code base A common misconception. In reality Shadcn is a thin wrapper around libraries such as Radix, recharts, etc. The article says as much.

Sure, but if you wanted to change it to just use a radio input you could. Shadcn gives you a baseline.

native radio buttons gives you a baseline.

You can only call Shadcn a "baseline" if it was a baseline of the last floor of the babel tower of abstractions.

Re: The Overcomplexity of the Shadcn Radio Button

#156

Post by rahoulb »

sorahn wrote: post #148
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…

I don't think this is specifically a react problem. The problem is that people don't want to learn what modern CSS can do, or write it themselves (see Tailwind), and most new frameworks make it easy to just sidestep that with div soup. Some of us _like_ CSS, and try to use as much of it when possible, but I feel like we are few and far between. I use react to manage the state of my app, but that doesn't mean I have t…

I agree it's not just React - I think a lot of people simply do not know what CSS can do nowadays.

I do like Tailwind (I guess it fits with how I think). But to make good use of it you _do_ need to know how CSS works (for example, using variant selectors for picking out child elements, using container queries instead of global breakpoints etc).

One addition - I learnt a _lot_ about CSS by reading [Every Layout](https://every-layout.dev/).

Re: The Overcomplexity of the Shadcn Radio Button

#157

Post by [deleted] »

danabramov wrote: post #152
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…

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. React gives you boxes to put stuff into but you decide what to put into them. Then React ensures that you can change what’s in those boxes without breaking anything. That’s the power of component abstraction.

[deleted]

Re: The Overcomplexity of the Shadcn Radio Button

#158

Post by FrontAid »

tmvnty wrote: post #153

So for a React developer who doesn't want to include Shadcn/Radix, but also doesn't have time to build every component/a11y/compat/edge cases from scratch, what are the better alternatives? Would be nice to list them here so developers can know a midpoint between DIY Shadcn/Radix

There are many options, each with their own pros and cons. Also, you may or may not like their default styling and/or styling options. There is no one size fits all. Having said that, we maintain an incomplete list of popular UI libraries here:

https://frontaid.ch/web/ui/libraries.html

Re: The Overcomplexity of the Shadcn Radio Button

#159

Post by ponyous »

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 laid out differently. He got it approved and implemented in 10 minutes. No bloat.

Re: The Overcomplexity of the Shadcn Radio Button

#160

Post by christophilus »

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…

I guess it depends on your definition of complexity. Being able to think about your UI as a function of state is a lot simpler than dealing with mutability, coordinating imperative updates all over the place, etc. React’s core idea is simpler than the paradigms it replaced. By simple, I mean as in “Simple Made Easy”[0].

[0] https://m.youtube.com/watch?v=SxdOUGdseq4&pp=ygUQc2ltcGxlIG1...

Post reply on HN