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

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. Due to the divergent complexity of today's abstractions and unavoidable leaks, we have a plethora of "modern" frameworks and tools that are difficult to use and create mental strain for developers. In short, I always avoid using such frameworks and prefer the old, boring basics wherever possible.

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

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

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

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 to make a 27 div component to style an input.

The big problem is trying to convince the rest of the team that they should learn and use CSS.

Is this the same with everything? In the past, a hard drive, a mouse, or a web camera was a dumb piece of hardware and a driver that ran on your PC. Now, IIUC, each of those has it's own computer (SoC) running an entire OS. Your phone probably has ~20+ SoC. One for USB, one for Wifi, One for Bluetooth, one for each of the 4 cameras, one for lidar, one for SSD, one for cellular, one for the secure enclave, one for audio, Each of them is an entire computer, more powerful than most 1980s general purpose computers, running an entire OS with multiple abstractions internally and all of that to make that device appear as yet another abstraction.

Am I wrong?

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.

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.

The problem is app-document impedence mismatch. CSS makes stuff easier but for doc-like pages. In addition doc-like pages want some app-like niceness too.

If you need to be an app you usually need a framework to stay sane (evidence: most other native UI kits are frameworks of some sort) and thus React etc. But they want full contol. Thus 2 ways to do a radio etc.

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.

https://www.mcmaster.com

2022 post about it. 1400 points. ~500 comments:

https://news.ycombinator.com/item?id=32976978

> does anyone have a good example of a large website built without all this bloat?

How about this one?

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

Cant speak for shady lib specifically but yes as you grow you do find that default styling doesnt work or you want something which doesn’t exist.

The crux tho is that this usually happens in what id call web apps and not websitess. Web apps are far more complex and powerful. It is a spectrum tho and sometimes websites grow into web apps which is why people oft over engineer early on.

There are lots of ways to style these native controls, though, including ways to start from scratch and retain the accessibility affordances.

I'd be curious to know more about the usability issues you've found on mobile -- I've not had any personally when using radio buttons. I'll readily grant you that 'select' is awful everywhere though!

> bear in mind that the default radio button has poor usability for mobile users

Wrap it in a label, give the label a padding. Boom!

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

The only <input> that is annoying to style is the “select” one because it’s hard to style the “options”. The rest seem reasonable and quite customizable in my experience.

> I've watched teams spend weeks just getting comfortable with component library internals

Would a good library allow developers to ignore internals and get on with higher-level stuff?

They hype-train on all of this stuff is unreal. React+NextJS+Tailwind+ShadCN is just a mess. It's complexity piled on deeper complexity - for little gain! But suggest any of that in many circles and you'll get the standard, "skill issu bro" comebacks. Say what you want about Remix/ReactRouter 7 (there are plenty of issues to talk about there) but at least those guys _tried_ to stay closer to existing web standards. I could go on and on about the disaster of NextJS caching. I could point out RSCs being one way to solve a problem that could already be solved by loaders in other frameworks....

Tailwind was my moment of saying, "Nope, I'm gonna sit this one out". I have a few trusted friends that assure me I'm missing out. I've told them to come back to me after they've done their first major refactor. If they tell me it was a pleasant experience, I'll have another look.

You can get a lot closer with only small modifications:

    input[type="radio"] {
      appearance: none;
      margin: 0;
      width: 25px;
      height: 25px;
      background: white;
      border-radius: 50%;
      display: inline-grid;
      place-content: center;
      box-shadow: 0 2px 10px color(display-p3 0 0 0/0.5);

      &::before {
        content: "";
        width: 11px;
        height: 11px;
        border-radius: 50%;
      }

      &:checked::before {
        background: color(display-p3 0.383 0.317 0.702);
      }
    }

> How doable is it with vanilla css?

Under all of the framework complexity that specific look is still achieved with CSS. In fact, you could rip out the CSS they use with very little modification and pair it with a ~five-line React component that doesn't require any third-party imports.

Fun exercise! https://codepen.io/mcintyre94/pen/pvbPVrP

Everything in styles.css in that example maps to the vanilla input, so you just have to move them around a bit. Should work at least as well as theirs across browsers, because it's vanilla inputs and the same CSS.

Where do you draw the line tho? How many kilobytes and how much future maintenance work is avoiding a potential slight visual inconsistency with a radio button worth? Is it worth to lose the x amount of people who have bad network connection?

Use this approach everywhere and the actual content of the page (you know: the stuff people came for) suffers.

All I can think about is a quote by world famous video artist Nam June Paik: When to perfect, Gott böse ("God gets mad when too perfect", the original isn't exactly a full sentence and mixes English and German).

  > - Make sure it looks the exact same across all browsers
  > How doable is it with vanilla css? 

"Make sure it looks the exact same across all browsers" is, and always has been, fundamentally at odds with how the web is intended to work.

How well does this shadcn crap render in arachne? ladybird? netsurf? links? dillo? netscape 3? The latest version of chrome with user styles applied?

When you say "exactly the same", I assume you mean that the design only uses black and white, because some people might have black and white monitors, right? But you're also going to use amber-on-black because some people might have amber screen monitors, right? How do you plan on ensuring it looks exactly the same on a braille terminal?

Maybe you think I'm being silly. Because nobody uses monochrome monitors in 2026, right? So it's safe to ignore that and put an asterisk next to "exactly the same" (And also just forget that e-ink is a thing that exists).

(Just like how it was safe in 2006 to assume people would always have 800x600 or bigger displays, and nobody would ever come along using a screen with, say, 480×320 resolution)

What measures have you taken to ensure that your colours appear exactly the same across a bunch of different types/brands of monitors that render colours differently? Or, perhaps we should just add another asterisk next to "exactly the same"?

I could go on.

How many asterisks is acceptable before "exactly the same" isn't a thing anymore?

If "exactly the same on all browsers" is one of your goals, you are wrong. If your designer tells you that's what they want, they are wrong. If you ever tell a client that's what you're providing, you are wrong.

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 (announcing the radio buttons to them).

This is why there's so much complexity in libraries like Radix - accessibility in the real world usually requires a lot of Javascript.

> 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 you need a database? Aren't files enough? And so on.

Shadcn is a framework for developers who develop highly interactive web apps. If all you need is a static form that submits data to a web service, you probably don't need a framework (except when you need it - for example, selects are not yet fully styleable in all browsers).

Next objection usually is: do you need complex apps on the client? Can't they be reduced to a series of simple forms controlled by the server? Sometimes they can and sometimes they can't, but of course I will decide the shape, behaviour, complexity and look of the applications I build (or have others build for me), thank you very much.

That said, radio buttons have been styleable in all non-legacy browsers for at least 5-6 years, there's no excuse for rewriting them from scratch with svgs.

A lot of frontend developers today (my experience) does't even know where to look for CSS updates or what vast amount of HTML element exists, they just know to look for frameworks and that's how they see the world. Like <input> is foreign to them, they only know of <FrameworkTextComponent>.

Sometimes you do need a framework, but the question is being asked way too seldom.

Protip: the space between the UI control and the label should be done using padding (or achieved via label nesting) so that the entire area is clickable.

    [ x ]   some long label
         ꜛꜛꜛ
         padding here, not margins or gaps

Is this developed by these 10x developers I've heard about?

This interactivity definitely adds a wow effect.

Exactly this. OP fails to understand that there are reasons why it was done this way, and that someone who spent thousand of hours working on this might know something that they don't.

In 2020, radio buttons weren't easily stylable in all mainstream evergreen browsers. That's usually the case why some components are over engineered. Of course they should have simplified them when all browsers fell in line, but tech debt is hard.

Can you provide more details about the issues?

One midpoint is traditional css frameworks like https://getbootstrap.com/.

Not as powerful, and you don't get this sweet 3rd-party pluggable component catalog, but it's much simpler and it's stable: there's no constantly evolving ecosystem.

Shadcn ecosystem might have calmed down by now, but when I used it years ago, the layers on top of it were super unstable, and I was annoyed every time I have to work on those projects until I got Opus 4.5 to refactor out of them.

You don't want to build your own components but you also don't want to use pre-made components? At some point you have to pick one. If you really want a midpoint, it's literally Radix: behaviours are done, stylings are up to you

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

Claude Code can whip this stuff together quickly if you specify those constraints and are knowledgeable enough to know what’s possible with modern CSS, etc.

They never figured how the exclusive choice works in <input type="radio" name="group">

As someone who has never really dived into React etc., my main question is "where is the line?"

I'm sure you'll agree that React is overkill for some applications and, for the sake of this discussion, I'll agree that it's beneficial for applications beyond a certain complexity.

But where exactly (or even, roughly) does that line lie? A basic CRUD app? Surely not. A calculator? I'm guessing "no". Bluesky? Maybe/probably.

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:

    <input type="radio" name="beverage" value="coffee" />

I still don't understand why someone would choose to essentially clone some code vs import a library. Suddenly you increase your maintenance burden, lose updates, etc. I've had no problems at all with UI libraries like Mantine. If you follow this logic, why not just clone all your npm repos and build from source. Ultimate control, right? Please help me understand the benefits here, because I tried out shadcn and wasn't into it

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

I've been dabbling in backend and frontend stuff for about 25 years now, but for the past 15 years or so I haven't really had to do any webby stuff for work (and that's kind of how I like it).

Recently I've needed to put together a few things as "proof of concept" for things like internal directories and catalogues, and it's one of those "How Hard Can It Possibly Be" situations where we've had folk prevaricating for months with outline drawings and sketches and mockups.

So I knocked together a backend for it in Django, which worked okay, and then styled up the raw template with MinCSS[1], and then to do stuff like "find-as-you-type" and other "magical dynamic page" things I used HTMX[2] which has been discussed here endlessly.

No need for AI sloppiness. Just write some code, look at some examples, stick in some styles, and away you go.

[1] https://mincss.com/examples.html

[2] https://htmx.org/

I don't think it's hard, it's harder than people think it's going to be. So they get frustrated and start abstracting away, ignoring history and hoping their fresh approach will finally make this thing easy.

> it's clear from research that users prefer custom buttons if they provide more "features" than the defaults.

Hate to be asking for a "source", but what research? And what "features" can a radio button even have? You click it and it's selected. I suppose accessibility can be considered "features", but I'm strongly suspecting that the overcomplex button has worse accessibility.

> all UI controls, have tremendous inherent complexity

Well, this is true in a sense, but it's not exactly a good argument for re-implementing all that complexity in JS / HTML, instead of simply using the browser's implementation that's written in a real language.

Agree, this kind of complexity is there for a reason. I would rather have a complex component that handles all the cases within its usage in the codebase over having a bunch of little hacks/changes in the usage. It's far easier to maintain one complex component than many different usages of that component.

And you don't have to use such a complex component library if you don't need it. For small codebases it often is overkill. But for large codebases it's a massively worthwhile investment.

Yup, agents LOVE Tailwind+ShadCN. Even when I've explicitly told them not to use it, it still creeps in. There's a lot of prior art out on GitHub and LLMs can't help themselves. FWIW, the result does tend to look nice enough. For a POC I can't complain. If I'm really going to roll up my sleeves and get into the code though? I don't think I'd enjoy all of it.

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.

How do you implement this keyboard navigation with SSR (if you use buttons)?

https://www.radix-ui.com/primitives/docs/components/radio-gr...

Radio buttons are in html spec for over 30 years and they allow extensive CSS styling on every part of the element.

> So anybody building a web app...

... beyond a specific size. This important distinction might transform "anybody" into "10%" or "5%" or "0.001%"—who knows, I'm still trying to figure this out!

What is it about multiselect or radio buttons that you feel is lacking in the current Web platform?

Yep, radio buttons weren't easily stylable in all evergreen browsers back on 2020.

There's literally an example of that in the post.

> where you don’t hide the native appearance

What do you mean by this? Seems like an arbitrary requirement to set. Could you show an actual example of how this overengineered style is easier to customize?

> 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 everyone uses and don't question it. It's not uncommon for them to be unaware that the vanilla elements even exist at times, such is the pervasiveness of React bloat.

Another shoutout to Basecoat. Easy to use. Makes your website look nice. Works with any/no framework.

I'd never heard of basecoat but it looks great. IMO this is what Tailwind UI should have been. It was utter stupidity that they forced you to use their preferred shiny new JS framework of the week for UI components.

> I genuinely don’t understand how front-end developers accept this level of needless complexity.

I call it 'Shiny Object Syndrome' - Frontend devs tend to love the latest new JS frameworks for some reason. The idea of something being long running, tried and tested and stable for 5-10 years is totally foreign to many FE devs.

Despite its age JS and its ecosystem have just never matured into a stable set of reliable, repeatable frameworks and libraries.

This looks awesome.

Shadcn most likely contains a lot of LLM generated code. Isn't it owned by Vercel these days?