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

331–340 of 351 posts

Re: The Overcomplexity of the Shadcn Radio Button

#331

Post by sevenseacat »

ikety wrote: post #147
yoz-y wrote: post #111

Earlier quoted context omitted.

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…

What about Elm? I think most people could grasp the elm architecture in an afternoon. To me this MVU style is pretty much perfect for UI. I think a lot of the time React appears complex and hacky is because we tried to solve world hunger with one component. I've worked on plenty of React projects that were very easy to scale, modify and iterate because they focused so heavily on small independent stateless components…

Elm is awesome until you try to use it in an actual app. The amount of pain we went through trying to make a basic web app with a sidebar and a few pages... I don't remember the specifics, it was a few years ago, but I don't think Elm has changed much since then (it was 0.18).

Re: The Overcomplexity of the Shadcn Radio Button

#332

Post by atoav »

rustystump wrote: post #308
stephenr wrote: post #45

Earlier quoted context omitted.

> It is like fast food, not every cares about farm to table I mean, a "colorful fat choncker" website is literally the opposite of fast food - its slower to arrive, and focuses way too much on appearances . In this analogy, the website using these ridiculous abstractions is more like Salt Bae or whatever idiotic trend has replaced him. All glitz, zero substance, slower, and for no apparent reason. The fast food equiv…

Everyone always says slower and bloat and bad etc etc but it is all relative. Not everyone is an eng who scoffs at waiting another 100ms. I do like your analogy tho. It is better. Most people want that trendy experience or fast food. Still, both exist because the market demands it be so despite how much it tilts a subset.

I worked in first level IT support and I think most people don't even consider it consciously like that. They read the news at that page. That page changes. A lot has to happen to piss them off enough to make them go. They habitually click away fifty windows a day without reading them anyways.

But people do notice if something just works on a subconscious level and that colors their perception of your project/brand/page or whatever. Even my totally tech-illiterate father actively complains about junk interfaces like the one at Temu. But he goes there for the sweet deals. I just wonder if it wouldn't work out better for them if the page was snappy and allowed a person to visit more product pages.

And one mistake you make is to think you need a megabyte of javascript to create a junk look. You can easily do that with HTML and CSS alone, including animations and all.

The way I see it the causal arrow points in the other way: successful sites tend to get bloaty, but they do no et successful because of it, but despite it.

And by bloaty I don't mean it as a problem if the page does a lot. Bloaty means you use a intricate Rube-Goldberg-machine to in the end do very basic things. Like displaying a popup, which can be done with a single line of Javascript, but is for some reason done using the amount of code that would result in a veritable, heavyweight book if printed.

Re: The Overcomplexity of the Shadcn Radio Button

#333

Post by kaizenb »

dylmye wrote: post #138
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.

Thanks, no love for Adobe but React Aria seems good. Saved, will look in to it.

Re: The Overcomplexity of the Shadcn Radio Button

#334

Post by port11 »

benrutter wrote: post #22

This radio selection is brilliant silly, especially because the end result is indecipherable from a vanilla css rqdio button. For some reason people keep going back to complex UI and interactivity frameworks though, does anyone have a good example of a large website built without all this bloat? Asking because I've seen hundreds of small sites built with elegance and simplicity, and few large ones. Is it just inevita…

One major reason for this, in my past experience, is that designers push for heavily customised components. If you go back to them with “why not use the default radio button with a bit of styling?”, I’ve yet to work with a designer that would relent, the specs are always for crazy UI work.

Re: The Overcomplexity of the Shadcn Radio Button

#336

Post by elktown »

jauntywundrkind wrote: post #324
elktown wrote: post #244

Earlier quoted context omitted.

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

> I don't find litigating this to be useful or interesting.

I think it is useful because our field is woefully inept at anything resembling backtracking, and it's having concrete detrimental effects all over the field by, for example, increasing mountains of bloat eating up hardware improvements.

> SPA's have really nice performance characteristics. [..] A good SPA should offer the same capabilities too

The problem is that not even large teams without any obvious lack of resources are also unable to prevent sluggishness from creeping in to SPAs. So I guess there's a theoretical SPA and a de facto one.

> But it wouldn't be anywhere near as capable, as interesting, and as loved.

Capable sure, if you're creating Google Earth style apps. But when you start using vague and extremely subjective adjectives like "interesting" and "loved" it should be a signal that something's off here.

Re: The Overcomplexity of the Shadcn Radio Button

#337

Post by boppo1 »

fireant wrote: post #326
simlevesque wrote: post #241

Earlier quoted context omitted.

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

New to webdev, coming from graphics:

What is better than react? I started with direct dom manipulation and it was a nightmare for making a 'modern' experience.

Re: The Overcomplexity of the Shadcn Radio Button

#338

Post by beckler »

jadbox wrote: post #264
ponyous wrote: post #159

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…

I'm finding it's better to use "javascript-less" UI frameworks [Pico.CSS, Skeleton, Bulma, Tailwind/daisyUI]. You get most of the benefits using good use of CSS. Anyone used these JS-free solutions and have recommendations?

If you like how shadcn looks, you might want to consider basecoat: https://basecoatui.com/

Re: The Overcomplexity of the Shadcn Radio Button

#339

Post by LocalPCGuy »

chris_engel wrote: post #312
LocalPCGuy wrote: post #223

Earlier quoted context omitted.

> widely regarded as terrible and slow to adapt I know you are saying you do work mainly in Angular, but for others reading this, I don't think this is giving modern Angular the credit it deserves. Maybe that was the case in the late 20-teens, but the Angular team has been killing it lately, IMO. There is a negative perception due to the echo chamber that is social media but meanwhile, Angular "just works" for enterp…

Strong disagree. Angular is cursed to the bone. It got a bit better recently but its still just making almost everything totally overcomplicated and bloated.

I'd say what you call bloated is in many cases basic functionality that I don't have to go looking for some third party package to fill. There is something to be said for having a straightforward and built-in way to do things, which leads to consistency between Angular projects and makes them easier to understand and onboard to.

IMO, it is only as complicated or simple as you want to make it these days, and claiming otherwise likely is due to focusing on legacy aspects rather than the current state of the framework.

FWIW, I'm not arguing that it's the "best" or that everyone should use it. Or that it doesn't still have flaws. Just that it is still firmly in the top set of 3-5 frameworks that are viable for making complex web apps and it shouldn't be dismissed out of hand.

Re: The Overcomplexity of the Shadcn Radio Button

#340

Post by evilduck »

stavros wrote: post #174
sorahn wrote: post #148

Earlier quoted context omitted.

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

Encapsulation, e.g. utility classes (and Tailwind, by extension) solve for project management or organization level problems, not styling problems directly. The nice defaults are a bonus but the actual value is a common and agreed upon approach to avoiding a write-only stylesheet that grows forever and for not fucking up cascading styles that impact someone else's feature or page you didn't intend to and causing releases to grind to a halt while they sort out what you did. Everyone here who misses that point is basically broadcasting how they are the cause of long term problems in their project or at their organization.
Post reply on HN