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

171–180 of 351 posts

Re: The Overcomplexity of the Shadcn Radio Button

#171

Post by SwiftyBug »

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…

photopea.com is entirely written in JavaScript and as far as I know, it doesn't use any fancy JS framework.

Re: The Overcomplexity of the Shadcn Radio Button

#172

Post by worble »

FrontAid wrote: post #158
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

I'd never heard of Ark UI before, and as a svelte and solidjs dabbler it's great it supports multiple frameworks. Thanks for this site!

Re: The Overcomplexity of the Shadcn Radio Button

#173

Post by hombre_fatal »

freetonik wrote: post #107
curtisblaine wrote: post #57

Earlier quoted context omitted.

> Isn't html/css enough? No, obviously. If you are writing complex web applications with state, local processing of data and asynchronous interactions it's not enough. You need javascript. If your javascript is especially complex and you desire it to be declarative, you probably need a framework. Do you need, I don't know, Tomcat in Java? Probably yes for a complex application and no for a simple proof of concept. Do…

>If you are writing complex web applications with state, local processing of data and asynchronous interactions it's not enough. >Next objection usually is: do you need complex apps on the client? It's not even an objection, it's a question I ask and almost never hear a coherent answer to. The vast majority of web applications I use every day (online banking, github, forums, social media, admin interfaces of various…

> it's a question I ask and almost never hear a coherent answer to.

There are a lot of coherent answers though.

One is that responding with HTML encumbers the server with brittle UI over the wire when it could instead be a simpler API server that any client can talk to.

Returning data instead of UI from the server is a clean separation of concerns.

There's nothing incoherent about that.

Re: The Overcomplexity of the Shadcn Radio Button

#174

Post by stavros »

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

Re: The Overcomplexity of the Shadcn Radio Button

#175

Post by frderrin »

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…

> React is much more complex than the technology it's building on. Necessarily, to enable it's features

React, just like most software today, is excessively complex for the tasks it performs.

The only reason React is used is that many use it as a framework to attempt to provide more interactivity on the page without page reloads. There are other frameworks to do this, but none are as well-used.

Webpage interactivity with data was accomplished with page reloads via cgi-bin in the 1990s. Everything that has been done since then was not strictly necessary to produce the websites we use today; it would just be a more choppy experience.

A smoother experience didn’t require the overwhelming complexity that was introduced primarily in the 2010s in a framework war that React basically won. That complexity is the reason why many web and full-stack developers in the 2010s (such as myself) lost their minds and quit or seem incredibly depressed, grumpy, and confused much of the time today, and why some have invented strange new frameworks to attempt to reduce this complexity.

Re: The Overcomplexity of the Shadcn Radio Button

#176

Post by curtisblaine »

stevepotter wrote: post #167
curtisblaine wrote: post #70

Earlier quoted context omitted.

Managing state and syncing it to the DOM manually is much harder than React (or any other big framework) for any non-trivial web app. Reactive, inherently asynchronous, event driven applications get complex easily.

Right. I encourage young devs to build a complex app using vanilla js. Feel the pain of two way state management. Then you’ll gain an appreciation for react. And you’ll learn browser APIs and know when react is overkill because it has its own pain

It's not even the young devs. It looks like most of those complaining are back end developers who "rarely tinker with frontend" but think they can teach everyone else how to make it simple because "it should be static forms".

A great example of all-world-is-a-nail stance mixed with extreme hubris.

Re: The Overcomplexity of the Shadcn Radio Button

#177

Post by curtisblaine »

freetonik wrote: post #107
curtisblaine wrote: post #57

Earlier quoted context omitted.

> Isn't html/css enough? No, obviously. If you are writing complex web applications with state, local processing of data and asynchronous interactions it's not enough. You need javascript. If your javascript is especially complex and you desire it to be declarative, you probably need a framework. Do you need, I don't know, Tomcat in Java? Probably yes for a complex application and no for a simple proof of concept. Do…

>If you are writing complex web applications with state, local processing of data and asynchronous interactions it's not enough. >Next objection usually is: do you need complex apps on the client? It's not even an objection, it's a question I ask and almost never hear a coherent answer to. The vast majority of web applications I use every day (online banking, github, forums, social media, admin interfaces of various…

Immediate feedback informs the visual language in order to convey meaning in a easier way to a larger public. You may know what an eventually consistent system is, but many users don't, and they want visual information abstracted to something they can understand. It's reassuring.

Also, not everything can be reduced to static forms. Charts with knobs, drag and drop interfaces, interactive diagrams are all useful visual aids that you would like to erase because... they don't conform with your naive views on how things should look like?

Re: The Overcomplexity of the Shadcn Radio Button

#179

Post by stevepotter »

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…

We went out of business, but I made a web app for videographers to collaborate during production. Same things as frame.io. This was over 15 years ago. Frontend was pretty vanilla except relied heavily on jQuery. The main section of the app allowed you to commend on specific frames in a video. The code is split up amongst multiple files. Here is one: https://github.com/StevePotter/Takeoff/blob/main/Takeoff.Web...

Look at any of the sibling `app-productions-details*.js` files. Combined they formed a single interface. It was dicey. But damn the interface was snappy. I mean, instant. Code would have been much less these days but probably nowhere near as responsive.

Re: The Overcomplexity of the Shadcn Radio Button

#180

Post by BigJ1211 »

rustystump wrote: post #37
discomrobertul8 wrote: post #26

Earlier quoted context omitted.

> I genuinely don’t understand how front-end developers accept this level of needless complexity. in my anecdotal experience as a bit of an old fogey with a greying beard, the enthusiastic juniors come along, watch a video by some YouTube guru (who makes videos about code for a living instead of making actual software) proselytizing about whatever the trendy new library is, and they assume that it's just what everyon…

Please name some names of these performative developer/engineers. I want to know how many are on my bingo card. Ill start, something imegen and tnumber geegee.

I don't really keep up with these Tech/Soft tubers, but watch a video on occasion. Can't really say I find something-imagen guilty of this, but like I said I watch the occasional video, not the stream. What I've watched from him is generally about what he agrees/disagrees with and he also tells you why he thinks that. Often reading articles/blogposts. Not to dismiss your opinion, but I would put him in the entertaining with substantive arguments category.

IMO software education/tainment suffers much worse though. They teach you how to do X in only this specific way with these specific tools, generally sponsored. Not the admittedly far more boring basics to do it yourself, or how to actually use these tools in a broader sense.

Post reply on HN