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 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.
> 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.
my brain for whatever reason won't accept react it's just instant ejection. i was there in the before times all the way up till jquery became uncool and i just tuned out of front end entirely once react and all the stuff driven by facebook became so ubiquitous, my soul just does not want to dabble in any of it.
i think im mostly just appalled at what feels like over complexity that might've made sense over a decade ago but perhaps im waiting for a more satisfying paradigm to come along. i dunno. i had some sparks of joy tinkering with golang to build ssr stuff, i dont keep up with wasm at all but i hope its cruising along.
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.
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'm struggling to form a definitive statement about my thoughts here, but I'll give it a try:
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.
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
I know people love to make UIs stateless and functional. But they just aren’t. IMO UIs are fundamentally a bunch of state, graphically represented. So naturally all of the functional frameworks are full of escape hatches.
I’d rather have a honest framework than a chimera.
I have not followed SwiftUI recently but when it was introduced I quite liked to have the main composition in SwiftUI and then writing more complex 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 also have the same somewhat controversial opinion, the frontend community wasn't ready and (still isn't) to organise a functional codebase.
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 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].
React is not simple (preact is) and what's worse, it gets more and more overengineered in order to solve the problems they have themselves created (accidental complexity in your video).
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>
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.
I agree it's not just React - I think a lot of people simply do not know what CSS can do nowadays.
I do like Tailwind (I guess it fits with how I think). But to make good use of it you _do_ need to know how CSS works (for example, using variant selectors for picking out child elements, using container queries instead of global breakpoints etc).
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?
> 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.
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.
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
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.
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 inevitable that as a team size grows, someone introduces insanity? Do these tools solve an actual problem that I'm missing?
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.
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.
This is the kind of stuff we have to do because almost all browser <input> elements are terrible in terms of customisability. Especially radios and selects
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.
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!
It’s a lot easier now than it used to be. Radio buttons used to be nearly impossible to style, and I still think they require scripting to de-select— so none in a group are selected after one has been selected. I’ll bet most of the complexity in the article is some combination of keeping support for older browsers, technical debt, and nobody complaining about it because it works.
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 have absolutely no doubt that somehow all these projects and similar ones - started with good intentions - good looking UI, implement and forget. And then, one fine day you're sitting on top of 200+ lines of code for a radio button and 7 imports and it's too hard to go back now without tearing the whole codebase apart. This is how code rot starts.
The real cost of this complexity isn't the code itself - it's onboarding. Every new dev joining the project has to understand why a radio button needs 47 lines of JSX with Radix primitives, context providers, and styled variants.
I've watched teams spend weeks just getting comfortable with component library internals before they can be productive. Meanwhile the "simpler" vanilla approach might have taken an afternoon to build but takes 20 minutes to explain.
That said, if you're building something like Figma or Linear where you genuinely need the accessibility primitives and keyboard navigation that Radix provides, the complexity pays for itself. Most CRUD apps don't need it though.
Developers remember, you can always push back on design requirements instead of bringing in more bloat.
I was sitting next to one of the devs in a co-working space and he was trying to figure out some specific layout issue in react native. He spent 4 hours + installed a dependency to be able to do something completely tiny on a privacy policy screen. He asked me how I would do it, I told him to just ask if it can be laid out differently. He got it approved and implemented in 10 minutes. No bloat.
These comments don’t seem to have that much love for shadcn, which is unfortunate as I think it promotes good component file structure and reuse. The premise is that you could (and should) change the components yourself, as they are living in your code base and ”owned” by you, which is a radically different approach compared to other ui libraries.
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.
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).
Based on profits of many webapps, there is no line. What eng here forget is that they are oft not the targeted consumer. The hypothetically perfect website doesnt sell as well as a colorful fat choncker does. It is like fast food, not every cares about farm to table.
> - Make sure it looks the exact same across all browsers
> How doable is it with vanilla css?
It's not doable with your fancy frontend framework and your 20 imports and your ten thousand lines of typescript.
"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.
Displaying the same thing on every monitor to the degree that monitor allows is well-defined. The browser may not be able to show some colors and the browser may decide to display things differently on purpose, but it's perfectly reasonable to want to unambiguously express what you _want_ the browser to display.
Im not in web development. Reading this article makes me think: is it realy neccersary to use all those complex frameworks? Isn't html/css enough? People always say "every line not written can't be a bug" but moving those lines into a library was not the idea behind the words
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.
>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 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.
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.
Interestingly Radix has both `Radio Group` and `Radio` — The simple `Radio` input does use `<input type="radio">` but the `Radio Group` does not. Git history does not show _why_ though.
The biggest mistake I did in 2025 was picking shadcn because it was so hyped. Saw it importing from radix anytime you enter a command. First red flag.
Then I saw the radio component. Second red flag. You should see what they've done with the select component. But we were too far into the deadline for a project with running targets. So I just gave up and asked copilot to make the changes for me, and I'm not a fan of AI anything.
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.
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
(clicking between the control and the label does nothing now)
In a hilarious turn of fate, on iOS safari the first time one of the radio options is clicked after loading, the css focus style is applied, but a click is not always registered so the radio item ends up stuck in an invalid weird-looking state. I highly doubt the issue would occur if the built in radio were being used
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.
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
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:
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.
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.
Well, usually, the reasons are to support every single use-case. A great selling point, but ultimately why I don’t like using things like this and importing loads of other libraries. Most of the code your importing is for some other user and any one app will probably be using a slither of the functionality.
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.
"There are reasons" is a pretty bland defense of why something was done in a bad way. You'd have to show that the reasons are valid, which I highly doubt. Also, somebody spending thousands of hours on making a worse version of something existing, isn't a good justification either. That's on the level of counting lines of code as a measure of productivity.
Can here to say this exactly.
Not saying they don’t raise an interesting point but the complete lack of curiosity why a group of experts in simplicity and accessibility decided to take this path is jarring
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 mean, that much is obvious just based on casual reading of a few articles/discussions about "modern" front-end dev.
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.
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.
Incidentally, radio buttons are a (sadly) forgotten art and are neglected in modern browsers. There are many issues with them, which is why people reimplement them on their own.
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>
Well I want to give shadcn some credit, building a comprehensive open-source UI toolkit, on your own basically, isn't as easy as one would think. Yeah you can use native elements except for some tiny edge case with say Safari and then you go deeper into the rabbit hole, until you decide you'll just customize everything. But at this point you probably have lost a lot of time and sanity already.
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.
Ok, I'll bite. I've been coding for almost 25 years so have seen various things come and go, so hopefully have a bit of capital in the bank.
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.
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.
Bluesky absolutely yes, something like React makes sense.
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.
A html forms based radio button is worse than a complex - but standard - shadcn radio button many ways that matter in the real world.
Why does no one do the simpler thing? Because there’s no extra value to it, and it in fact has negative value because then the team has to write and understand it and the rationale for the departure from just using the same component library everywhere.
“Only a few kb of javascript” 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?
How's using a custom library any way close to "standard"? How about the actual HTML standards? The whole reason you'd use "shadcn" is that customizing the actual HTML radio button isn't enough for you. Otherwise, if you just want a default-looking button, here you go:
If your team can't understand that, how are they going to understand a few KB of JS? Or maybe they're not supposed to understand it, but how can you then guarantee to your customers there isn't a crypto miner or tracker or something in that? Or perhaps you care more about "making money" than protecting your customers from such things?
You should not look at the button in isolation. The library is likely used to do other things vanilla HTML cannot do, but instead of maintaining multiple code, they just use the library to implement everything.
The library has in essence became an interface for developers to build for.
I am pretty new to frontend development (but have 20 years of backend)
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..
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.
I've used HTMX-like approaches a lot for other apps and I've been pretty frontend-averse, but this time I'm doing something similar to a drawing program with lots of d3 and SVG etc, very much the "real usecase" for SPA. So I feel HTMX doesn't apply to this specific usecase.
Well Shadcn gives you more freedom to fix stuff like this and rewrite how you want the component to work and look, since everything lives in your own code base. In a regular component lib it would be less likely that you'd think about this complexity, since it would be "hidden" away in node_modules or even transpiled and minified.
in early react days, and slightly before, the fun part was bidirectional binding and computed reactive values... but i admit that now it's become a big jungle just to recreate everything, plus it's rarely stable, new ui libs pop every year (shadcn is now rebasing on top of base ui i believe) .. seems wasteful now
As I was reading this text, my hands started sweating, my head began to ache, and I felt the anguish and terror of reliving a traumatic experience all over again. I can’t even count how many times I’ve been stuck in a project that’s already behind schedule, where the client (I’m a freelancer, working directly with the person who has the requirement) throws in a ‘simple’ request like: change the style of that radio button so it matches this other one.
The problem isn’t that—because of reasons like the ones explained in the article—I end up spending hours and hours on what looks like a trivial task. The real nightmare is when the client asks me: ‘Why are you taking so long to do something so dumb?’
It’s a nightmare. That’s why I ran away from React, because of this and countless similar situations, and went back to WordPress, where the world is so much simpler, the clients are happy, and so am I.
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.
This is only "overcomplex" from a naive point of view.
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.
> 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.
>I suppose accessibility can be considered "features", but I'm strongly suspecting that the overcomplex button has worse accessibility.
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)
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.
This is the reason I absolutely hate shadcn. The number of dependencies and files you introduce for trivial components is insane. Even tiny little divs are their own component for no good reason. I genuinely don’t understand how front-end developers accept this level of needless complexity.
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.
> 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.
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'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.
Note on the fact that this would add JS that needs to be loaded to see the page. No, because similar smart people created server-side rendering, adding another layer of complexity.
It has to be this way because we (the collective we) refuse to agree on adding proper UI primitives to the web.
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?
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.
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?
The pseudo element solution alone is extremely limiting in its ability to be customised. For more complex customisation you will need to decorate with additional elements within a ref’ed label - and then you are effectively back to what radix does.
As it is, you've joined the ranks of multiple others commenters who sound like cargo cultists, attacking OP for not understanding frontend dev without actually pointing out any issues in their writing. If it's easy to point out, then surely you can show how easy it is.
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 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.
> 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.
my brain for whatever reason won't accept react it's just instant ejection. i was there in the before times all the way up till jquery became uncool and i just tuned out of front end entirely once react and all the stuff driven by facebook became so ubiquitous, my soul just does not want to dabble in any of it. i think im mostly just appalled at what feels like over complexity that might've made sense over a decade ago but perhaps im waiting for a more satisfying paradigm to come along. i dunno. i had some sparks of joy tinkering with golang to build ssr stuff, i dont keep up with wasm at all but i hope its cruising along.
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.
I've started straight up being doubtful of every UI kit until I see in the docs a HTML or non-React example.
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.
In case you did not notice, Dan Abramov is defending React on HN.
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'm struggling to form a definitive statement about my thoughts here, but I'll give it a try:
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.
> divergent complexity of today's abstractions
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.
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
I know people love to make UIs stateless and functional. But they just aren’t. IMO UIs are fundamentally a bunch of state, graphically represented. So naturally all of the functional frameworks are full of escape hatches.
I’d rather have a honest framework than a chimera.
I have not followed SwiftUI recently but when it was introduced I quite liked to have the main composition in SwiftUI and then writing more complex 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.
2 replies →
I also have the same somewhat controversial opinion, the frontend community wasn't ready and (still isn't) to organise a functional codebase.
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?
9 replies →
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...
React is not simple (preact is) and what's worse, it gets more and more overengineered in order to solve the problems they have themselves created (accidental complexity in your video).
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>
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.
I agree it's not just React - I think a lot of people simply do not know what CSS can do nowadays.
I do like Tailwind (I guess it fits with how I think). But to make good use of it you _do_ need to know how CSS works (for example, using variant selectors for picking out child elements, using container queries instead of global breakpoints etc).
One addition - I learnt a _lot_ about CSS by reading [Every Layout](https://every-layout.dev/).
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?
1 reply →
> 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'm just genuinely really confused by this take.
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 ?
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.
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
1 reply →
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.
What is cache in this context? useState? What do you mean by cache invalidation in react apps?
3 replies →
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.
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 inevitable that as a team size grows, someone introduces insanity? Do these tools solve an actual problem that I'm missing?
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://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?
Don’t think it counts
5 replies →
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.
This is the kind of stuff we have to do because almost all browser <input> elements are terrible in terms of customisability. Especially radios and selects
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.
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!
It’s a lot easier now than it used to be. Radio buttons used to be nearly impossible to style, and I still think they require scripting to de-select— so none in a group are selected after one has been selected. I’ll bet most of the complexity in the article is some combination of keeping support for older browsers, technical debt, and nobody complaining about it because it works.
> 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?
It doesn’t.
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.
4 replies →
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.
The date picker still sucks.
2 replies →
I have absolutely no doubt that somehow all these projects and similar ones - started with good intentions - good looking UI, implement and forget. And then, one fine day you're sitting on top of 200+ lines of code for a radio button and 7 imports and it's too hard to go back now without tearing the whole codebase apart. This is how code rot starts.
I recently tried out https://daisyui.com/ (CSS only components, depends on tailwind) and so far I really like it.
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
The real cost of this complexity isn't the code itself - it's onboarding. Every new dev joining the project has to understand why a radio button needs 47 lines of JSX with Radix primitives, context providers, and styled variants.
I've watched teams spend weeks just getting comfortable with component library internals before they can be productive. Meanwhile the "simpler" vanilla approach might have taken an afternoon to build but takes 20 minutes to explain.
That said, if you're building something like Figma or Linear where you genuinely need the accessibility primitives and keyboard navigation that Radix provides, the complexity pays for itself. Most CRUD apps don't need it though.
> 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?
Bingo.
[flagged]
Developers remember, you can always push back on design requirements instead of bringing in more bloat.
I was sitting next to one of the devs in a co-working space and he was trying to figure out some specific layout issue in react native. He spent 4 hours + installed a dependency to be able to do something completely tiny on a privacy policy screen. He asked me how I would do it, I told him to just ask if it can be laid out differently. He got it approved and implemented in 10 minutes. No bloat.
These comments don’t seem to have that much love for shadcn, which is unfortunate as I think it promotes good component file structure and reuse. The premise is that you could (and should) change the components yourself, as they are living in your code base and ”owned” by you, which is a radically different approach compared to other ui libraries.
I normally share the sentiments of the article. But I am also curious, if the goal was:
- 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.
You can get a lot closer with only small modifications:
Here's a link to a codepen so you can see what it looks like without rendering it yourself: https://codepen.io/erikaja/pen/RNRVMyB
> 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).
Based on profits of many webapps, there is no line. What eng here forget is that they are oft not the targeted consumer. The hypothetically perfect website doesnt sell as well as a colorful fat choncker does. It is like fast food, not every cares about farm to table.
3 replies →
It's not doable with your fancy frontend framework and your 20 imports and your ten thousand lines of typescript.
"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.
Particularly given that on a screen reader -- which yes is an example of a browser -- it doesn't "look like" anything at all
Displaying the same thing on every monitor to the degree that monitor allows is well-defined. The browser may not be able to show some colors and the browser may decide to display things differently on purpose, but it's perfectly reasonable to want to unambiguously express what you _want_ the browser to display.
1 reply →
Exactly the same when rendered by the evergreen mainstream browsers. That's perfectly doable.
Im not in web development. Reading this article makes me think: is it realy neccersary to use all those complex frameworks? Isn't html/css enough? People always say "every line not written can't be a bug" but moving those lines into a library was not the idea behind the words
> 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.
>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 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.
2 replies →
Most web apps are a combination of static pages, simple forms and highly interactive content though. That's what makes the choice so hard.
2 replies →
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.
Interestingly Radix has both `Radio Group` and `Radio` — The simple `Radio` input does use `<input type="radio">` but the `Radio Group` does not. Git history does not show _why_ though.
The biggest mistake I did in 2025 was picking shadcn because it was so hyped. Saw it importing from radix anytime you enter a command. First red flag. Then I saw the radio component. Second red flag. You should see what they've done with the select component. But we were too far into the deadline for a project with running targets. So I just gave up and asked copilot to make the changes for me, and I'm not a fan of AI anything.
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.
15 years ago, Enterprise FizzBuzz [1] was supposed to be satire. These days, it's not quite complex enough to capture "modern" web dev.
[1] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
The shadcn radio button in action: https://ui.shadcn.com/docs/components/radio-group
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.
(clicking between the control and the label does nothing now)
Calling this a "Protip" is generous.
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.
Is this developed by these 10x developers I've heard about?
This interactivity definitely adds a wow effect.
Is it sarcastic or does it appear only on high frame rate devices? To me it simply feels like another radio button.
3 replies →
In a hilarious turn of fate, on iOS safari the first time one of the radio options is clicked after loading, the css focus style is applied, but a click is not always registered so the radio item ends up stuck in an invalid weird-looking state. I highly doubt the issue would occur if the built in radio were being used
I see this with a bunch of python libraries too.
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.
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
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
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!
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.
Did they ask the original authors of Radix why it's the way it is?
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.
Well, usually, the reasons are to support every single use-case. A great selling point, but ultimately why I don’t like using things like this and importing loads of other libraries. Most of the code your importing is for some other user and any one app will probably be using a slither of the functionality.
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.
Perhaps this is the original PR for the Radio/RadioGroup[1].
It does seem the complexity was a deliberate decision.
[1] https://github.com/radix-ui/primitives/pull/121
1 reply →
"There are reasons" is a pretty bland defense of why something was done in a bad way. You'd have to show that the reasons are valid, which I highly doubt. Also, somebody spending thousands of hours on making a worse version of something existing, isn't a good justification either. That's on the level of counting lines of code as a measure of productivity.
Can here to say this exactly. Not saying they don’t raise an interesting point but the complete lack of curiosity why a group of experts in simplicity and accessibility decided to take this path is jarring
1 reply →
Okay, what exactly are those reasons?
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 mean, that much is obvious just based on casual reading of a few articles/discussions about "modern" front-end dev.
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.
1 reply →
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.
Incidentally, radio buttons are a (sadly) forgotten art and are neglected in modern browsers. There are many issues with them, which is why people reimplement them on their own.
Can you provide more details about the issues?
> Web development is hard.
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 think this is the equivalent of the radix demo (which has better styling than the shadcn one) in plain html/css: https://codepen.io/mcintyre94/pen/pvbPVrP
Copied styles from the radix docs: https://www.radix-ui.com/primitives/docs/components/radio-gr...
Well I want to give shadcn some credit, building a comprehensive open-source UI toolkit, on your own basically, isn't as easy as one would think. Yeah you can use native elements except for some tiny edge case with say Safari and then you go deeper into the rabbit hole, until you decide you'll just customize everything. But at this point you probably have lost a lot of time and sanity already.
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.
> Look at it. It's beautiful.
Quite right too … I’m choosing HTMX over React for just that.
Ok, I'll bite. I've been coding for almost 25 years so have seen various things come and go, so hopefully have a bit of capital in the bank.
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.
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.
Bluesky absolutely yes, something like React makes sense.
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.
A html forms based radio button is worse than a complex - but standard - shadcn radio button many ways that matter in the real world.
Why does no one do the simpler thing? Because there’s no extra value to it, and it in fact has negative value because then the team has to write and understand it and the rationale for the departure from just using the same component library everywhere.
“Only a few kb of javascript” 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?
How's using a custom library any way close to "standard"? How about the actual HTML standards? The whole reason you'd use "shadcn" is that customizing the actual HTML radio button isn't enough for you. Otherwise, if you just want a default-looking button, here you go:
If your team can't understand that, how are they going to understand a few KB of JS? Or maybe they're not supposed to understand it, but how can you then guarantee to your customers there isn't a crypto miner or tracker or something in that? Or perhaps you care more about "making money" than protecting your customers from such things?
You should not look at the button in isolation. The library is likely used to do other things vanilla HTML cannot do, but instead of maintaining multiple code, they just use the library to implement everything.
The library has in essence became an interface for developers to build for.
I am pretty new to frontend development (but have 20 years of backend)
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..
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've used HTMX-like approaches a lot for other apps and I've been pretty frontend-averse, but this time I'm doing something similar to a drawing program with lots of d3 and SVG etc, very much the "real usecase" for SPA. So I feel HTMX doesn't apply to this specific usecase.
Well Shadcn gives you more freedom to fix stuff like this and rewrite how you want the component to work and look, since everything lives in your own code base. In a regular component lib it would be less likely that you'd think about this complexity, since it would be "hidden" away in node_modules or even transpiled and minified.
> everything lives in your own code base
A common misconception.
In reality Shadcn is a thin wrapper around libraries such as Radix, recharts, etc. The article says as much.
Sure, but if you wanted to change it to just use a radio input you could. Shadcn gives you a baseline.
1 reply →
Sure, that's true. I oversimplified.
in early react days, and slightly before, the fun part was bidirectional binding and computed reactive values... but i admit that now it's become a big jungle just to recreate everything, plus it's rarely stable, new ui libs pop every year (shadcn is now rebasing on top of base ui i believe) .. seems wasteful now
Shadcn is an anti-pattern.
As I was reading this text, my hands started sweating, my head began to ache, and I felt the anguish and terror of reliving a traumatic experience all over again. I can’t even count how many times I’ve been stuck in a project that’s already behind schedule, where the client (I’m a freelancer, working directly with the person who has the requirement) throws in a ‘simple’ request like: change the style of that radio button so it matches this other one. The problem isn’t that—because of reasons like the ones explained in the article—I end up spending hours and hours on what looks like a trivial task. The real nightmare is when the client asks me: ‘Why are you taking so long to do something so dumb?’ It’s a nightmare. That’s why I ran away from React, because of this and countless similar situations, and went back to WordPress, where the world is so much simpler, the clients are happy, and so am I.
I use shadcn/ui for side projects, mostly coding with agents.
Good to have a base design system for building products.
Are there any alternatives? Coded systems, not just UI components.
I much prefer React Aria's components. Yes fuck Adobe but take their RadioGroup for example: https://react-aria.adobe.com/RadioGroup Much better than shadcn's in terms of deps and LOC, and it uses an input. All of their components are built for accessibility first.
This is only "overcomplex" from a naive point of view.
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.
> 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.
>I suppose accessibility can be considered "features", but I'm strongly suspecting that the overcomplex button has worse accessibility.
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)
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.
This is the reason I absolutely hate shadcn. The number of dependencies and files you introduce for trivial components is insane. Even tiny little divs are their own component for no good reason. I genuinely don’t understand how front-end developers accept this level of needless complexity.
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.
[1]: https://basecoatui.com/
> 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.
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.
1 reply →
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.
The dropdown systems are something else, I spent almost as much time on that as I did on the rest of the interface when I tried Shadcn.
That's why I never touch web frontend dev.
Note on the fact that this would add JS that needs to be loaded to see the page. No, because similar smart people created server-side rendering, adding another layer of complexity.
How do you implement this keyboard navigation with SSR (if you use buttons)?
https://www.radix-ui.com/primitives/docs/components/radio-gr...
I can’t tell if this is sarcasm or not! Radio buttons support keyboard navigation without JS.
1 reply →
It has to be this way because we (the collective we) refuse to agree on adding proper UI primitives to the web.
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.
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?
Yup. Unfortunately common I think - not just with UI components. Occam's razor is sometimes only for others.
There has to be a reason for picking button instead of input type="radio", right?
Yep, radio buttons weren't easily stylable in all evergreen browsers back on 2020.
> Why would you want to do this?
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.
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?
The pseudo element solution alone is extremely limiting in its ability to be customised. For more complex customisation you will need to decorate with additional elements within a ref’ed label - and then you are effectively back to what radix does.
we've new dev's been trained that this is normal - a.i putting out slop / trained on this cz its the default
yeah sad state of affairs
And then you realize this paradigm plagues even desktop applications through electron and the like. Enshittification knows no borders or limits.
[dead]
[flagged]
What makes you think reading the code makes someone less curious than relying on someone else’s made up answer about it.
If all you have to contribute is being insulting, you don't have to comment.
Go on, then. Point them out.
As it is, you've joined the ranks of multiple others commenters who sound like cargo cultists, attacking OP for not understanding frontend dev without actually pointing out any issues in their writing. If it's easy to point out, then surely you can show how easy it is.
and people complain about AI code?
Shadcn most likely contains a lot of LLM generated code. Isn't it owned by Vercel these days?