The Overcomplexity of the Shadcn Radio Button
paulmakeswebsites.com
paulmakeswebsites.com
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 someone knows is React or other frameworks, things get overengineered. They didn't realise it could be so much simpler if they just knocked it back a layer instead of climbing higher and higher.
I often think back to that message, while adding things in a dependency array. Especially those things that I know won't change (e.g. the redux `dispatch` function pulled from the context), but the linter doesn't. Or while being admonished by the linter for reading from a ref, or writing to it.
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.
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?
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 the frontend world and don't have much to judge by. But it's been such a relief to have most things simply included out of the box.
No two React projects are the same. Like, even the router has at least three different mainstream options to choose from. It's exhausting.
Indeed. I work mainly in Angular because while it's widely regarded as terrible and slow to adapt, it's predictable in this regard.
Also now with typed forms, signals and standalone components it's not half bad. I prefer Svelte, but when I need Boring Technology™, I have Angular.
90%+ of all web apps are just lists of stuff with some search/filtering anyway, where you can look up the details of a list entry and of course CRUD it via a form. No reason to overthink it.
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 enterprise and startups who want to scale alike.
I think people who are burned on on decision fatigue with things like React should give Angular another try, might be pleasantly surprised how capable it is out of the box, and no longer as painful to press against the edges.
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.
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.
> math tools or pdf generation
In this case the original scope of the library was “reactive rendering”, which sort of makes sense.
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.
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.
It didn't work as in if I were to ask for the router, state management, etc library, there would be a combinatorial explosion of react "frameworks", all sucking in different ways.
I am (and supposedly grandparent also) on the option that react leaves out way too much that would still be well in the scope of a 'UI framework', and while modularity can be a good thing in certain things, more modular, more moving parts does increase complexity.
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 components in pure UIKit. Both could be used what they are best suited for. But trying to shoehorn good interactivity into a SwiftUI component always ended in horrible code.
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.
React doesn't really contest that as-worded. It's just that, ideally, a nested component isn't the owner of important state.
Functional does not mean no state, just constraining state to inputs and outputs. Breaking that is a choice, and not good design.
Elm, for example, provides all of that with one escape hatch: ports. It is really well-defined and that not fall into any of the impossibilities you mention.
A great example of all-world-is-a-nail stance mixed with extreme hubris.
Perhaps those same people would have a slow complex mess in vanilla tools too though, so maybe React is a scapegoat like PHP was, and Javascript was.
React itself with nothing else is plenty fast. You would have to go way out of your way to see performance differences between different UI approaches, computers are just way too fast to notice whether this click resulting in the div's text changing to +1 is slow or fast, even if the implementation were crazy convoluted.
What makes react apps slow is using it badly, and having 10 other libraries getting in the picture loading fat UI elements, etc.
And frankly these would be much slower in your render everything anew approach.
> But for several years we've been able to style radio buttons however we want using a few CSS tools
proves how good the current state is, where a dev can think things will just be ok, for everyone, if you just ripped all that complexity and ship it (which should be the attitude for a good framework).
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.
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.
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.
i wonder if what im after is like some kinda dead simple easy to use declarative front end api that can be built from a backend, something like streamlit or nicegui that has great ergonomics and is easy to maintain but scales better and has better state mgmt than streamlit & puts all the power of a general purpose programming language right there with it. i love compiled things i hate setting up environments with runtimes and stuff.
Here it is: https://www.shadcn-vue.com/
Personally I also tend to hate on what React has made the modern web, and I say this as someone who's made money for the past 10 years making React apps, but reimplementing half of something poorly and declaring success because it looks kinda similar when you squint is just silly. Many (most?) "pure html frameworks" are like this unfortunately.
What is better than react? I started with direct dom manipulation and it was a nightmare for making a 'modern' experience.
Am I wrong?
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.
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/).
Did we go off semantic CSS and returned to setting properties on each element, or was I using it wrong?
And extra benefits.
Generally more concise on the common usecase, but more importantly you can combine and use media queries, which can't be done with inline styles alone.
Utility based CSS has been around as long as classes have, tailwind is just one iteration of that. GitHub use to have a utility css library as well before switching to their new design.
So 99% of the value can be achieved with strict linting and autocomplete plugins.
At least that's how I always seen it billed as, even when Adam was live streaming and saying as much in like 2018/2016.
If you're building a component-based UI, that need is less, because all your buttons are created in a specific Button component. That's also an easy place to attach styling. You don't even need a separate file anymore.
But that's a wash. It gets much more interesting if you have components that are used in different contexts. Unordered lists for example can be an unordered list in the running text, but also a navigation list in the footer, the menu, or as tabs. There's some semantic logic to having those things as lists, but they usually look completely different.
You'd use classes and descendent selectors to deal with those differences. The downside is that those leak very easily to instances that you don't want them in. Having normal lists inside tabs inside running text requires careful engineering of the selectors.
The larger and older your project grows, the harder it becomes to get that exactly right in a future-proof way. At some point changing something for one item somewhere, can completely mess up something on another part of your site.
Inline styling, or Tailwind-style utility classes, are useful in that situation. Every component gets to be responsible for the way it looks and no longer has to care what anything else does. HTML tags that are used in different contexts will have their context right there, next to the styling. All part of the component.
The few remaining things that you need for consistency between components (colors, sizes, fonts, etc.) can be handled with CSS variables.
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.
Yes. But React isn’t the only way to do components. Unfortunately, to the inexperienced, it is.
React with is so prevalent because it's a deep local optimum.
There’s nothing about React that requires you to overcomplicate your DOM (unlike many other UI frameworks).
Application code is not supposed to use the DOM as the source of truth for some boolean state that the checkbox is an input for.
You don't usually read a component's state from outside (here: the "checked" property).
Instead you define an API where data only flows top-down.
When your checkbox component follows this paradigm, it is "controlled", and if it contains a standard HTML input, that input's "checked" DOM object property is bound to the data passed into the component ("props"). Clicking it won't check it anymore until you add an "onClick" callback and pass a function into this callback that will make the "checked" prop change.
The checkbox is now "controlled" and it's state was "lifted up" (meaning that it is determined not by the checkbox component itself).
"controlled" means you tell React to always force the "checked" DOM property to be the same as the "checked" prop you pass into the component. You do this by assigning to the reflected "checked" HTML attribute in JSX.
When your components only use this "top-down" data flow, they're "pure" in React lingo. Because they look like pure functions: props => DOM fragment. The machinery behind the scenes means they're not actually that (something has to coordinate the rendering).
But if you don't use internal state (e.g. useState hook) or global stores, these "impure" parts are React internals only, and you can have a mental model that views the component like a pure function.
This makes it easier to connect it with other components in a tree.
For example:
HTMLInputElement.checked can be true without a "checked" attribute being in the markup.
If you want to have some text next to it that says "checked / not checked" you have to wire stuff, and this stuff depends on your markup.
If you have a "controlled" checkbox, you have a tree, not only for the markup, but also for the data: the boolean "checked" state can now be declared one level above both the info text and the checkbox. Then the info text doesn't care at all about events anymore.
And the checkbox component only uses a callback that is also independent from the exact markup structure (e.g. a selector for the HTML input element).
You don't need to read from the checkbox to update the text. You feed both with a boolean and both can be "pure" components. The checkbox gets a "onClick" callback and it's checked state is no longer internal, it's "controlled".
The wiring you have to do instead of the regular DOM events (which would read the input's state) is now to use your "onClick" callback to toggle your boolean.
Internally, in the component, you do whatever you need to read and write to the DOM. But usually that just means "what markup do I return".
Input elements and reflected attributes such as "checked" are already a relatively complex case.
And, you can escape the recommended top-down data flow by many means (refs, context, accessing centralized "stores" from within the component...), but that's often where it gets ugly. But you need to do it often when your app gets bigger (centralized data stores), or when you implement things like UI libraries (refs).
[0] https://m.youtube.com/watch?v=SxdOUGdseq4&pp=ygUQc2ltcGxlIG1...
Sadly, accidental complexity is a common theme among react devs, not just ui libs, but also react-router, redux, redux-form, even tanstack useQuery() is way over-engineered and the core idea can be implemented in <50 lines and then you own the code and can make project-specific changes.
Maybe that's the biggest issue after all, people being lazy, expecting to do npm install and being able to reuse everything in any situation. Except that it almost never work like that and a lot of damage is done in the name of it... </rant>
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.
It's a 100x easier to build products today than it was in the 1990's. (I don't think that's an exaggeration in the slightest)
It would be basically be impossible to build anything like Maps, Excaidraw, Chat GPT etc.
Arguably people are reaching for the tools without those interactive requirements ?
We had that before, it was called HATEOAS.
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 be faster and simpler without SPAs. But it wouldn't be anywhere near as capable, as interesting, and as loved.
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.
The web is where it is (literally everywhere) because it is capable and powerful, and it's because we didn't listen to retrogressive gate keepers insisting the web shouldnt really be for those uses cases.
The alternative to this is nothing. Is to not have had connected software. But we aspired to make great systems. That made some people very mad.
Yes actually dev teams did have a massive leap in capability with dynamic HTML & updating the page.
> Not sure how you even get to that conclusion, strange rant.
Not sure how you even can miss that shift, strange miss.
(So, uh, do you always have to be such a deorgatory shit that I have to turn your crap faced mean shit back around? Can you talk like not a flaming shit bag? I don't super love turning your shitty mean crap ass personally aggressive negative worded words back at you, but you just have no vision & are ongoingly a mean shit about everything & so personally shitty about how you phrase things? And you are in such obvious denial. In ways that make zero sense. I don't think anyone sees how the web would grow while meeting your ridiculous constraints and that just seems obvious. Whatever third way you are trying to advocate for is clear as mud. And you cover for saying nothing with aggression! But mostly just stop being such an aggressive ass & engage like you can get over yourself, pull your head out of your ass, stop being a belittling shit, and make a God damned case, rather than throwing endless more empty bile.)
That said, it always feels like so much boilerplate to get up and running for a greenfield project (and things like NextJS or even TanStack Start add a lot of things that might be overkill for a simple web app).
For some vibe coded side projects with Claude, I’ve been working with just using handlebars templates with Express and it has been pretty glorious!
I don’t think I’d recommend building a complex web app this way, but for some mild JS interactivity, form submission, etc, handlebars works.
Bonus: I find it much easier to get 100 across the board on Lighthouse scores this way.
This is why I love Bun + React. The setup is so easy I can do it off memory. I always hated boilerplate, templates etc. so this is a huge selling point for me.
People who haven't work with other frameworks like svelte, Vue - normally say they are enjoying React.
For what it’s worth, I’ve used Vue and don’t like it (stuff like custom directives that are nonstandard html, not as explicit about event handling and data flow, etc).
I’ve seen a lot of buzz (particularly on HN) about Svelte but have lacked the motivation to try it.
The best approach I've found so far is egui , and I hope people are moving that direction. Draw whole frame, collect events, process, update internal state.
My initial objections were: (a) circa 2006 I was making very demanding RIAs such as knowledge graph editors and GIS decision support software and I've yet to see any modern framework that is as good as what I was using then (not in JS but rather GWT and Silverlight w/ the same async comms) and (b) the React model is not a 100% match for the form-based applications that we usually write with it (but boy do I love react-hook-form)
React is like the code in Graham's On Lisp [1] in that functional programming is used to create a sort of DSL. There are a lot of ways to implement reactivity that usually require a special interpreter (spreadsheets) or compiler (Svelte). React's system does show seams (you really need to be on top of identity and equality) but it is remarkably simple.
React shines, in my mind, for things that aren't form applications. For instance, VR applications with AFrame -- it's somewhere between VRML and Unity. I am working on a (mainly) heart rate variability biofeedback application [2] and it is so easy to make dashboards that display real-time metrics as well as Poincare sections and time series. That is, I can slap together a few data processing functions and widgets and make a new dashboard with new metrics and charts or new sensors. One goal is to get it working on a tablet in a two player version.
The disadvantage of React is that it does not work so well for highly dynamic layouts. In my case I have a library of functions to "fetch" the data stream and put them into the top of the component (may even package as hooks) and then put the layout together with JSX. I'd like to have a version where the user can drag and drop the components to make a custom layout and the system figures out the dependencies for the data fetching, preparation and processing like the things I made in 2006 and that kind of application with a dynamic layout (think programs like Photoshop with lots of different little widgets and property sheets) wants a different approach to reactivity.
[1] use of macros in that book is a red herring, the one example in it where you really need macros is when he is implementing cooperative multitasking, a feature that Python and Javascript already have -- most examples from that book as with Norvig's Lisp book can be coded up just fine with
[2] see https://github.com/paulhoule/VulpusVision it might "just work" if you npm install, npm run dev, and look at it in Chrome and connect with a Polar H10 or other BT monitor
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 inevitable that as a team size grows, someone introduces insanity? Do these tools solve an actual problem that I'm missing?
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.
How about this one?
2022 post about it. 1400 points. ~500 comments:
https://next-faster.vercel.app/
NextFaster feels faster than McMaster IMHO
[0] https://github.com/ethanniser/NextFaster?tab=readme-ov-file#...
There's no complex, dynamic filter. And no special rendering per type of item.
It's a glorified tumbler since the only dynamic part looks like the shopping cart. Everything else is pre-rendered from what I saw in code.
For static content like that I would have used Astro which is the golden standard.
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.
Nobody was ever fired for choosing React (or IBM). But everyone can get fired when they're working on a React app.
Beautifully put.
Funny enough we did a POC for the same project before that without shadcn and looking back, it's so much leaner and easier.
I might just break one night and redo the whole ui library with vanilla html elements.
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.
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.
If you're one of those who think we should just use the default, 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!
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.
I'd be happy to implement an HTML + CSS only solution and share it with you.
Thanks
By using radix, the underlying behaviour is compliant and identical for each of those implementations - you just change the content. Radix isn't looking at it like an html radio element, it is looking at it as a completely unstyled unique item selector.
The pseudo-element styling approach limits you to 3 layers - the container, and the 2 pseudo elements, none of which you can provide with meaningful content besides plain text. The best you can do is provide a basic styles and set background image. For anything else you need to use labels to either wrap the radio (in which case you can access state via sibling selectors) and/or ref them with "for" (in which case you cant access the state).
Putting an adjacent label is also possible, but scales poorly due to needing unique ids.
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!
Then if you want something a little bit complicated you have to do it all yourself.
- What if I need a date range instead of a single date? - What if I have excluded dates? (Only weekdays/only in the future/blackout dates) - What if I want to show other metadata with each day? (Like in a calendar showing each day with some metadata next to it)
Beyond “give a whatever the system thinks is a good date picker that I have no control over” the input with type date isn’t very useful.
- Implement the radio as the designer sent in the figma file (e.g. something like the radix demo one they're commenting on: https://www.radix-ui.com/primitives/docs/components/radio-gr...)
- Make sure it looks the exact same across all browsers
How doable is it with vanilla css? The example they gave was rendered to a black/white circle, most teams wouldn't ship that.
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).
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 equivalent is stuff like the Google home page: it doesn't validate, is actively harmful to you, the community, and the planet but is immensely popular.
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.
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.
It takes far less effort to implement the bad way. I think people take their own skill for granted. Maybe you can but most others cannot. Maybe they will learn or maybe they are happy to put food on the table and go home at 5.
Everyone else following along and merely using it I blame less, but they shouldn't have picked such a bloated library.
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);
}
}
> - 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.
In this case the website will not appear the same on every browser. Most browsers have a zoom function that the user controls which is an accessability feature. This changes how the website renders on the page.
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.
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.
You can do pretty much any styling!
I did a basic example because that matches what Shadcn does (black/white circle) but you can customize it a lot more.
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.
I know many will disagree with me and will point to livewire, etc as alternative approaches, and that’s valid. I’ve simply settled on React because it fits my mental model, I like functional programming, and I dislike that bifurcation problem.
>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 developer tools, etc.) don't really need to be dynamic and frontend-rich. I don't care if submitting a form refreshes the page. Funnily enough, full page refresh with a full round trip with "old school websites" is often faster than dynamic SPA interaction.
I don't care that when I click "delete", the item may not disappear from the screen immediately. I don't want to see some in-between state descriptions like "Deleting..." because I know it's a lie in a distributed, eventually consistent system. Just tell me the truth: the request has been sent. I can then refresh the page and see the new current state, whatever it is.
I really don't understand this desire to make websites behave like local apps while in reality they aren't.
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.
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?
The disconnect here between tech people and non-tech people is that most users do care about stuff like this.
I run a popular website as a solo project so all the feedback/complaints are routed to me, and one thing I've learned is that users really don't want websites to "feel old". Sure, they want it to be fast, but they also want all the bells and whistles like loading indicators and animations.
If you show Hacker News to someone who's not a developer, especially if they're under 30-35, their reaction to the layout and functionality will be visceral disgust. I really can't stress enough how much modern users hate the traditional plain HTML look. If you're trying to convince users to use your site and it looks or functions anything like HN, they'll get angry and close the tab within seconds to look for an alternative. Even if you've made a SPA with plenty of bells and whistles, users will still get upset if anything feels "clunky", which is often user-speak for "this component needs animations and a transition state". They don't know or care that all the fancy stuff increases the complexity of the codebase.
Every software project hits a point where the super clean abstractions the developers came up with start to clash with the messy way it's used in the real world. This is the frontend version of that. We have no choice but to give users the UX they want.
Since the dawn of time, humans have sought to eliminate mushy laggy UIs, such as having to wait for a full page reload whenever you click a button. I don't like SPAs either, but dunno, I don't find it particularly hard to understand how we got here.
Sometimes you do need a framework, but the question is being asked way too seldom.
It also highlights how far browser have come with new features such as dialogs, which I always implemented with (a lot of) JavaScript in the past
This is why there's so much complexity in libraries like Radix - accessibility in the real world usually requires a lot of Javascript.
I agree in many scenarios, but for the two you mentioned it seems like the <dialog> and <details> elements provide accessible solutions out of the box?
Sounds harsh but maybe somethings SHOULDN'T be designed a certain way because it breaks a11y when there are other roads to be taken that can still look pleasant, be accessible, and way easier to maintain (less brittle JS to worry about).
You're absolutely right!
Today I'm using a friends gaming computer. It's a 244hz monitor powered by a RTX 5070 TI and a screamingly fast AMD Ryzen 7 9800X3D CPU with 128GB of overclocked 6000MT/s RAM.
Not only does the radio look mundane for such overcomplicated component, but it also misses clicks where I would expect it to register. Like slightly above or below it.
For example, clicking where the pointer is in this image does NOT select the first radio button. It's not forgiving with regards to precision.
On a recent MBP, it's indistinguishable from a vanilla radio button.
[ x ] some long label
ꜛꜛꜛ
padding here, not margins or gaps
That the combined element has any surface area that doesn't toggle the radio setting is a straight-up bug.
It is laughable for a component this heavily refined to have such a basic usability flaw.
According to who? This alone is a pretty damning case against such a claim.
It does seem the complexity was a deliberate decision.
The other half of it looks to come from an overloaded Label component which should probably have been split into two. There’s a reason that HTML has <fieldset> and <label> as different things. The implementation is also trivially incorrect: role=label isn’t a thing. Other parts of it are wrong or dubious too. In general, if the HTML way of expressing something isn’t permitted, the ARIA way of expressing the same thing is probably wrong too.
And so it goes, through the entire system. They assume you might want something ridiculously complex, and so they complicate and make worse the normal case.
For the "requirement of being able to put any element as the radio button.", Dan Abramov tells you that this is exactly the point of React, see his comment above:
> 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. [0]
As for “the point of React” being that you can just do such and such… there’s nothing special about React there, that’s what any of these component libraries achieve (React, Vue, Svelte, &c., even basic templating systems like Handlebars a lot of the time).
I was just quoting the React creator.
Thanks for sharing the PR. Frankly that raises more questions for me. Why do they want to wrap a label in a label? What is the actual goal here?
I am 100% convinced that "Modern" front end developers are in fact, afraid of CSS and HTML. Like, "it will steal my eyeballs and look back at my face with them" scared.
Nothing else explains things like this, tailwind, JSX components, etc. Nothing. There is no explanation besides absolute morbid fear of the underlying technology - because the browser support has improved immensely but apparently they're all deathly scared of using it.
Before you tell me that I don't know what challenges these problems solve: I was primarily doing front-end development.... 20ish years ago. One of my first jobs in the space was adapting the client side code for a J2EE app - mostly this meant removing an IKEA worth of tables and using CSS - in IE6 of all fucking things. Subsequently I created reusable UI frontend components (i.e. output some HTML, maybe this little bit of corresponding JS, you'll get a usable interactive components in a browser) for two different organisations.
I have said it before and I'll say it again. I think JavaScript developers heard about (or saw over someone's shoulder) how J2EE guys had ant/etc build toolchains, and had abstraction like FactoryFactoryImplementationFactoryBuilderFactory and said HEY THAT LOOKS COOL, and if it's harder to understand they can't fire me!!
It's like NIH syndrome but for an entire community of people whose primary goal is chasing the shiny, followed closely by resume padding.
Why does it need so much complexity to draw a radio button that doesn't look all that different to the normal one you'd get with a perfectly ordinary <input> field, except it takes around ten seconds to draw and then doesn't work properly?
I know if the lib is written well then you won’t be introducing unused code into your code base but you still often are left with an overly complex scaffold or other infrastructure to support all the stuff you’re not using. Just use a radio button for gods sake.
[1] https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...
How would you suggest I reach out?
[1] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
We’re like 20+ years into web apps being a big thing and there’s still nothing like what’s offered in OS-native frameworks like Swift.
So anybody building a web app has to recreate SwiftUI in the browser every time via various bloated hacks (basically what Shadcn is).
If we could just agree on adding non-terrible cross-browser primitives for multiselect, popovers, modals, proper radio buttons, tabs, etc to the HTML spec and allow extensive CSS styling on every part of the element we could avoid these massive UI frameworks.
... 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?
- You re-implement focus rings, checked states, hover, disabled, error states.
- You end up bloating your stylesheet incomprehensibly
- Cross-browser differences (especially Safari) still leak through.
- Controlled components, validation layers, animations/transitions, rich layouts are annoying and break accessibility
- Turning native radios into radio cards for example breaks accessibility and keyboard navigation
- Rows with icons, badges, subtext, etc. between the radio and label is a huge issue
Hence why everybody uses Shadcn instead.
Would be nice to list them here so developers can know a midpoint between DIY <-> Shadcn/Radix
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.
Copied styles from the radix docs: https://www.radix-ui.com/primitives/docs/components/radio-gr...
A common misconception.
In reality Shadcn is a thin wrapper around libraries such as Radix, recharts, etc. The article says as much.
You can only call Shadcn a "baseline" if it was a baseline of the last floor of the babel tower of abstractions.
;; Let's render radio buttons ourselves. Because of bugs in React and Chrome, radio buttons mysteriously stop working.
;; https://stackoverflow.com/questions/48423061/radio-buttons-n...
;; https://github.com/facebook/react/issues/3446
followed by my own implementation of radio buttons, followed by:
;; Original implementation, to be used when radio buttons actually work:
followed by an implementation using an input of type radio, commented out.
I'd put the blame on React and poor Web APIs in this case. Both are way too complicated for mere mortals to understand fully, and even simplest things like maintaining 100% container height through nested elements, can become a ridiculous time-sink for something completely unrelated to what is your main objective.
The base (Radix UI) was built by a team on WorkOS paycheck.
Your (implicit) point that Shadcn didn't develop the underlying component library still stands.
Radio buttons, as with all UI controls, have tremendous inherent complexity, which comes to light once requirements ask for something beyond the blessed happy path of the default browser button. Pixel perfect styling, animations, focus behaviors, interactions with external state, componentized branding to fit in with companies' ecosystems, etc.
The baseline <input> paradigm struggles to provide the tools needed to adequately handle this complexity, even today, after many decades of web development.
And of course --- you can also argue that we should all just use the default browser button and everything should be solved. But this is also suboptimal, as 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.
Accessibility is incredibly hard to get right, particularly managing screen reader announcements, focus management and form validation. I recently had to build a website that met WCAG 2.1 requirements and it was made significantly easier by using React Aria (https://react-aria.adobe.com/) which is a similarly complex headless component library. To get an idea of the work that goes into making an accessible component, see their blog post about making a combo box where they test 4 different screen readers x 4 different browsers: https://react-aria.adobe.com/blog/building-a-combobox
(I haven't used Radix so I'm unsure how well they do a11y)
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.
> Pixel perfect styling, animations, focus behaviors, interactions with external state, componentized branding to fit in with companies' ecosystems, etc.
Do you have a more specific example of something you've struggled with recently?
no it's not.
you all make it hard by bloating your sites with Jenga tower abstractions for styling, needlessly load content dynamically via Jenga tower javascript libraries that pulls complexity into frontend and most of the time puts unnecessary load on the content generator ("backend") too. I don't know a lof of sites where that actually makes sense, as web === text.
When html5 came about, along with CSS3, it was such a big leaf in terms of ease of use and accessibility. I argue that what most websites do to my taste nowadays can be achieved by early-stage html5+css3+ a few svg.
Nowadays on about 50% of websites it have to * enable 3rd-party JS just to get the text * enable massive amounts of 3rd-party JS to get the images * enable remote fonts just to grok your pathetic icon-only menu or even spot the 'search' feature (it's not even a 'button' most of the time) because you didn't care to use a proper <img> or <svg>
I assumed I would need to use one of these libraries at some point. But, perhaps since I am using Svelte instead of React, whenever I ask AI to do something, then since I don't already use a component lib it just spits out the HTML/CSS/TS to do the job from scratch (or, depending on how you look at it, output the mean component from its training data).
I have to point out it should organize the code and give the component a dedicated Svelte file (sure I could fix AGENTS md to do that).
I think with AI the usecase for these libraries is much lower. If there is anything complex you need AI can build it in some seconds specifically tailored for you, so..
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.
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?
<input type="radio" name="beverage" value="coffee" />
The library has in essence became an interface for developers to build for.
I imagine for some usecase, they are valuable. However, when reading advice on the internet you get comments from people that tell you what technology they used without consideration of the overhead required to use this technology and the problem at hand.
Don't get me wrong, a HTML5 radio button is a beautiful thing, and sometimes React is a hammer and everything is a nail.
However, I think something that OP doesn't mention super explicitly in their post is the codebase they are working on is probably a React codebase. React is a great abstraction for building UIs. I've built a ton of them and the complexity only needs to go above a certain degree until you need a way more descriptive way of explaining your UI based upon other state, instead of trying to wire a load of DOM elements together.
If you are already using the React ecosystem, for things like form validation (again, possible with HTML5 but as soon as the complexity cranks or you can't use the server - you probably need a library), then using something like Radix is a great choice, OP even mentions how although it's not technically a visible radio button that is shipped to the DOM, it acts like one for a11y reasons, and this is due in part because it's very, very easy to write inaccessible HTML. And ShadCN is pre-made components on top of that, and they all work pretty well together.
Nothing is perfect, but even in my "old man yells at cloud" era, I personally don't think this one is worth yelling at the cloud for.
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.
I think it depends on a few things but the two big ones in my mind are:
1) Interactivity. How rich do you need/want the interactivity to be? As this scales up the benefit of React also increases.
Of course you can get highly interactive vanilla HTML sites but it’s much easier to achieve with React.
2) Statefulness. The more UI state you have the more a tool like React helps you. Again, it’s not doing anything you cannot do with vanilla HTML/JS but the level of difficulty comparatively is night and day.
On top of that, React is widely adopted. The tooling is fantastic, the community is strong, the job prospects are very good, and if you’re hiring the talent pool for React is vast.
https://www.radix-ui.com/primitives/docs/components/radio-gr...
Good to have a base design system for building products.
Are there any alternatives? Coded systems, not just UI components.
Shoutout to Basecoat UI[1], so implementing the same components using Tailwind and minimal JS. That's what I am preferring to use these days.
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.
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.
> 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.
Quite right too … I’m choosing HTMX over React for just that.
It seems they don’t understand the underlying requirements when building a reusable UI library. Yes in shadcn there are some opinionated choices , but the “i can do better/ i am smarter” attitude of this article is off putting.
We used shadcn in one project , and wrote a custom UI library for another (using the same “smart trick” for input elements). Shadcn wins for clarity, consistency, maintenanility and simplicity.
1. Does it look nice and professional?
2. Will it be here tomorrow?
3. How does it feel to work with - what does my instinct say?
The first question is easy. I either like it or not. I can't answer the second one with certainty. Nobody can. I can only guess. Sometimes I'm wrong.
The third one is instinct driven. If the ergonomics feel off, my instinct will tell me. If something is not right, I'll feel it. I might not always be able to explain it, but I'll know it's a go or no go. ShadCDN came with big praise, but my instinct said a big Nope. It's stuff like that that make me think that, maybe, we add complexity because we get bored with the "boring" tech.
Otherwise you haven't engineered anything, you've barely outlined the concept of a plan.
Two lessons here: The complexity exists for a reason. Try to understand where it comes from.
Second: Thinking "it could be done this way, I think" is barely 1% of really outlining a solution, implementing it and convincing others to use it. The latter is the hard part, but actually changes things outside of your head..
yeah sad state of affairs
Have you tried completely customising a radio button with CSS? Feel free to demonstrate a heavily customised radio button style where you don’t hide the native appearance.
> 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 certainly won't need to import x elements from a library that imports y elements itself
I shared a simple example because Shadcn has a simple design.
You do often hide the native appearance if you need something complex, but doing that via CSS is still much simpler than a bunch of JS and a third party dependency.
If you have a specific design in mind I can show you how to do it.