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.
FWIW I've been writing UIs using plain JavaScript and the DOM API for like 15 years and at a certain scale, I always ended up building an ad-hoc framework or being disgruntled when I had to reach for any of the pre-React UI frameworks whose APIs and approaches I didn't like. React changes this, nowadays I either start with pure DOM and then rewrite to React or just start with React. I see a lot of hate online for React these days and I agree with probably 99 % of it, but the problem in my eyes is not React itself, but the ecosystem that spurred around it. If you stick to just React and take some care with your craft, React is a joy to use IME.
Not everything needs to be a SPA. I genuinely believe that the web would've been a much better place today on most important metrics (performance, simplicity, accessibility etc.) if this SPA shift would've never happened. The opportunity cost seems massive to me.
Personally, I like to look at the source for a page. And that, for anything React, winds up being useless (<go-suck-an-egg-because-EVERYTHYING-is-loaded-dynamically/>). I find React very hard to debug whenever anything doesn't work as expected.
I work on a React based web app in my Day Job and have genuinely enjoyed it.
That said, it always feels like so much boilerplate to get up and running for a greenfield project (and things like NextJS or even TanStack Start add a lot of things that might be overkill for a simple web app).
For some vibe coded side projects with Claude, I’ve been working with just using handlebars templates with Express and it has been pretty glorious!
I don’t think I’d recommend building a complex web app this way, but for some mild JS interactivity, form submission, etc, handlebars works.
Bonus: I find it much easier to get 100 across the board on Lighthouse scores this way.
Hard feelings here. I like react and have to work with it, still it is all insanely wrong.
The best approach I've found so far is egui , and I hope people are moving that direction. Draw whole frame, collect events, process, update internal state.
My initial objections were: (a) circa 2006 I was making very demanding RIAs such as knowledge graph editors and GIS decision support software and I've yet to see any modern framework that is as good as what I was using then (not in JS but rather GWT and Silverlight w/ the same async comms) and (b) the React model is not a 100% match for the form-based applications that we usually write with it (but boy do I love react-hook-form)
React is like the code in Graham's On Lisp [1] in that functional programming is used to create a sort of DSL. There are a lot of ways to implement reactivity that usually require a special interpreter (spreadsheets) or compiler (Svelte). React's system does show seams (you really need to be on top of identity and equality) but it is remarkably simple.
React shines, in my mind, for things that aren't form applications. For instance, VR applications with AFrame -- it's somewhere between VRML and Unity. I am working on a (mainly) heart rate variability biofeedback application [2] and it is so easy to make dashboards that display real-time metrics as well as Poincare sections and time series. That is, I can slap together a few data processing functions and widgets and make a new dashboard with new metrics and charts or new sensors. One goal is to get it working on a tablet in a two player version.
The disadvantage of React is that it does not work so well for highly dynamic layouts. In my case I have a library of functions to "fetch" the data stream and put them into the top of the component (may even package as hooks) and then put the layout together with JSX. I'd like to have a version where the user can drag and drop the components to make a custom layout and the system figures out the dependencies for the data fetching, preparation and processing like the things I made in 2006 and that kind of application with a dynamic layout (think programs like Photoshop with lots of different little widgets and property sheets) wants a different approach to reactivity.
[1] use of macros in that book is a red herring, the one example in it where you really need macros is when he is implementing cooperative multitasking, a feature that Python and Javascript already have -- most examples from that book as with Norvig's Lisp book can be coded up just fine with
[2] see https://github.com/paulhoule/VulpusVision it might "just work" if you npm install, npm run dev, and look at it in Chrome and connect with a Polar H10 or other BT monitor
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?
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.
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.
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>
> 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.
Managing state and syncing it to the DOM manually is much harder than React (or any other big framework) for any non-trivial web app. Reactive, inherently asynchronous, event driven applications get complex easily.
Right. I encourage young devs to build a complex app using vanilla js. Feel the pain of two way state management. Then you’ll gain an appreciation for react. And you’ll learn browser APIs and know when react is overkill because it has its own pain
It 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?
Hooks were fine, but their implementation in React was barkingly insane. Vue's notion of "composables" is very similar, but not dependent on order, so you can use them in conditional statements without breaking the world. I don't even want to think about doing a complex Vue app without the VueUse library.
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.
There is a difference between implementations getting more complicated vs. interfaces. It doesn’t matter if the mouse has a SoC if it still only exposes the same old USB HID protocol. The issue discussed in this thread is that the developer using the thing isn’t shielded from the increased implementation complexity and can’t just work with the abstraction.
React was built to satisfy the specific scaling and complexity needs of Facebook, and this CV-driven industry jumped on board with it pretending that what's good for Facebook is good for them. The incentives are completely misaligned: it's like nobody gains anything out of using the least amount of force and abstraction to solve a specific problem.
I did frontend before React, and it was a welcomed change. The core insight of UI being a function of state is a good one. It saves you a bunch of headaches from the jQuery days where you’d have multiple code paths per UI element (adding, removing, mutating). That said I think they lost the plot with hooks and things have gotten needlessly complex since then.
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?
Not the prettiest but absolutely amazing to use! I'm sure web devs are laughing at me right now, but I genuinely didn't realise websites with that many images etc could actually be that fast.
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.
As company size grows, managers want to settle on a "standardized" tech stack that doesn't get in the way when they want to hire and fire people at will.
Nobody was ever fired for choosing React (or IBM). But everyone can get fired when they're working on a React app.
One major reason for this, in my past experience, is that designers push for heavily customised components. If you go back to them with “why not use the default radio button with a bit of styling?”, I’ve yet to work with a designer that would relent, the specs are always for crazy UI work.
Its because everyone can see UI, and many have strong opinions on it. Its always the first tragedy of the commons. In a typical tech company built on compromise, fighting the complexity is a fools errand.
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.
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.
They hype-train on all of this stuff is unreal. React+NextJS+Tailwind+ShadCN is just a mess. It's complexity piled on deeper complexity - for little gain! But suggest any of that in many circles and you'll get the standard, "skill issu bro" comebacks. Say what you want about Remix/ReactRouter 7 (there are plenty of issues to talk about there) but at least those guys _tried_ to stay closer to existing web standards. I could go on and on about the disaster of NextJS caching. I could point out RSCs being one way to solve a problem that could already be solved by loaders in other frameworks....
Tailwind was my moment of saying, "Nope, I'm gonna sit this one out". I have a few trusted friends that assure me I'm missing out. I've told them to come back to me after they've done their first major refactor. If they tell me it was a pleasant experience, I'll have another look.
In general, Tailwind and React don't match well. Why use a soup of CSS classes when React has props? If someone needs an a11y-focused base for their component library, they can start with Radix UI directly, ignoring Tailwind and Shadcn.
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.
I'm finding it's better to use "javascript-less" UI frameworks [Pico.CSS, Skeleton, Bulma, Tailwind/daisyUI]. You get most of the benefits using good use of CSS. Anyone used these JS-free solutions and have recommendations?
My current choice is DaisyUI. It’s pretty good and because it’s based on tailwind you get the rest of the ecosystem benefits. Super easy to extend and change. Class bloat is much more manageable than raw tailwind.
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.
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.
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.
> - 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.
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.
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.
If you're not into web development, Hacker News discussions about React are really bad way to gain unbiased perspective - it's been really popular here for last few years to just hate React (usually they know nothing, e.g. anyone who claims hooks compose worse than class components). But there's a reason why React is still used the most (large ecosystem, fast development and backwards compatibility). Of course, it's easy for inexperienced developer to produce slow and buggy apps (maybe slightly easier than in other frameworks, but that's practically unquantifiable), to include unnecessary or even badly written dependencies, etc. - but it's not the tool's fault when it's being used incorrectly.
This library doesn't appear to be accessible. Just looking at two random components: The Drawer (https://daisyui.com/components/drawer/) doesn't trap focus inside itself (letting you tab to the page behind the drawer while it's open). The Accordion (https://daisyui.com/components/accordion/) first example is using radio buttons as a hack to avoid Javascript, which would be very confusing to screen reader users (announcing the radio buttons to them).
This is why there's so much complexity in libraries like Radix - accessibility in the real world usually requires a lot of Javascript.
> This is why there's so much complexity in libraries like Radix - accessibility in the real world usually requires a lot of Javascript.
I agree in many scenarios, but for the two you mentioned it seems like the <dialog> and <details> elements provide accessible solutions out of the box?
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.
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)
For some reason it's exceptionally slow for me on chromium. I click and I see it register half a second later. It also has no cursor:pointer which makes it look non-clickable. Is it expected or a bug?
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
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
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.
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?
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.
Author here: I tried to find answers in their docs but they don't provide any context. I expected to find an explanation of why to use their solution there but did not.
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?
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.
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:
One thing to keep in mind regarding a11y, the semantic web is accessible by default. It's once you break away from establish norms do things become harder or tricky, but if you can stick to using actual semantic elements and not div-soup you will cover 90% of your use cases (assuming your use case isn't relying on just the canvas element).
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
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.
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.
I still don't understand why someone would choose to essentially clone some code vs import a library. Suddenly you increase your maintenance burden, lose updates, etc. I've had no problems at all with UI libraries like Mantine. If you follow this logic, why not just clone all your npm repos and build from source. Ultimate control, right? Please help me understand the benefits here, because I tried out shadcn and wasn't into it
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.
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.
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.
But handling edge cases is a self-inflicted wound, because you have decided to re-implement something that already has an extremely well tested specification and implementation in the browser. This is almost always a mistake.
Author here. I've implemented all of these with the native radio button and CSS:
> Pixel perfect styling, animations, focus behaviors, interactions with external state, componentized branding to fit in with companies' ecosystems, etc.
Do you have a more specific example of something you've struggled with recently?
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 don't think it's hard, it's harder than people think it's going to be. So they get frustrated and start abstracting away, ignoring history and hoping their fresh approach will finally make this thing easy.
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.
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.
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.
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.
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.
2 pieces of UI in different parts of the page that depend on the same data - that's the line (also matches the initial goal of React - sync FB chat widgets).
React has sort of become the Java for front end -- ubiquitous and often implemented in a needlessly over-complex way with the type of ceremony devs need to express in order to assuage their own insecurities.
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.
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.
Yup, agents LOVE Tailwind+ShadCN. Even when I've explicitly told them not to use it, it still creeps in. There's a lot of prior art out on GitHub and LLMs can't help themselves. FWIW, the result does tend to look nice enough. For a POC I can't complain. If I'm really going to roll up my sleeves and get into the code though? I don't think I'd enjoy all of it.
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.
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
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.
I don’t see the “complexity” the author is yelling about. Maybe is the tailwind verbosity?
It seems they don’t understand the underlying requirements when building a reusable UI library. Yes in shadcn there are some opinionated choices , but the “i can do better/ i am smarter” attitude of this article is off putting.
We used shadcn in one project , and wrote a custom UI library for another (using the same “smart trick” for input elements). Shadcn wins for clarity, consistency, maintenanility and simplicity.
I evaluated a LOT of UI toolkits for React. The premise is always great - I want to save time by not having to build a UI toolkit for my application, so I'll use a great one off the shelf. But what I found was that the evaluation falls into three questions:
1. Does it look nice and professional?
2. Will it be here tomorrow?
3. How does it feel to work with - what does my instinct say?
The first question is easy. I either like it or not.
I can't answer the second one with certainty. Nobody can. I can only guess. Sometimes I'm wrong.
The third one is instinct driven. If the ergonomics feel off, my instinct will tell me. If something is not right, I'll feel it. I might not always be able to explain it, but I'll know it's a go or no go. ShadCDN came with big praise, but my instinct said a big Nope. It's stuff like that that make me think that, maybe, we add complexity because we get bored with the "boring" tech.
So? Did you open a PR for shadcdn or Radix? Did you throw out the shadcdn code rendering the radio button from your codebase? Did you ensure it doesn't come back the next version?
Otherwise you haven't engineered anything, you've barely outlined the concept of a plan.
Two lessons here: The complexity exists for a reason. Try to understand where it comes from.
Second: Thinking "it could be done this way, I think" is barely 1% of really outlining a solution, implementing it and convincing others to use it. The latter is the hard part, but actually changes things outside of your head..
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.
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.
Yes, several times. I've been specializing in front-end dev for over a decade.
I shared a simple example because Shadcn has a simple design.
You do often hide the native appearance if you need something complex, but doing that via CSS is still much simpler than a bunch of JS and a third party dependency.
If you have a specific design in mind I can show you how to do it.
I almost had the same reaction tbh! Like I remember inline-grid and place-content for example was not at all supported css, it would've been a nightmare to do, but modern browsers css support is way more powerful than my mental model of them still is. So it's time to update that mental model.
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.
For pure HTML pages I use Basecoat which is shadcn without React: https://basecoatui.com/
3 replies →
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.
3 replies →
I've started straight up being doubtful of every UI kit until I see in the docs a HTML or non-React example.
There is a Vue version as well.
Here it is: https://www.shadcn-vue.com/
FWIW I've been writing UIs using plain JavaScript and the DOM API for like 15 years and at a certain scale, I always ended up building an ad-hoc framework or being disgruntled when I had to reach for any of the pre-React UI frameworks whose APIs and approaches I didn't like. React changes this, nowadays I either start with pure DOM and then rewrite to React or just start with React. I see a lot of hate online for React these days and I agree with probably 99 % of it, but the problem in my eyes is not React itself, but the ecosystem that spurred around it. If you stick to just React and take some care with your craft, React is a joy to use IME.
Not everything needs to be a SPA. I genuinely believe that the web would've been a much better place today on most important metrics (performance, simplicity, accessibility etc.) if this SPA shift would've never happened. The opportunity cost seems massive to me.
9 replies →
Personally, I like to look at the source for a page. And that, for anything React, winds up being useless (<go-suck-an-egg-because-EVERYTHYING-is-loaded-dynamically/>). I find React very hard to debug whenever anything doesn't work as expected.
2 replies →
I work on a React based web app in my Day Job and have genuinely enjoyed it.
That said, it always feels like so much boilerplate to get up and running for a greenfield project (and things like NextJS or even TanStack Start add a lot of things that might be overkill for a simple web app).
For some vibe coded side projects with Claude, I’ve been working with just using handlebars templates with Express and it has been pretty glorious!
I don’t think I’d recommend building a complex web app this way, but for some mild JS interactivity, form submission, etc, handlebars works.
Bonus: I find it much easier to get 100 across the board on Lighthouse scores this way.
7 replies →
Hard feelings here. I like react and have to work with it, still it is all insanely wrong.
The best approach I've found so far is egui , and I hope people are moving that direction. Draw whole frame, collect events, process, update internal state.
I came to really appreciate React over time.
My initial objections were: (a) circa 2006 I was making very demanding RIAs such as knowledge graph editors and GIS decision support software and I've yet to see any modern framework that is as good as what I was using then (not in JS but rather GWT and Silverlight w/ the same async comms) and (b) the React model is not a 100% match for the form-based applications that we usually write with it (but boy do I love react-hook-form)
React is like the code in Graham's On Lisp [1] in that functional programming is used to create a sort of DSL. There are a lot of ways to implement reactivity that usually require a special interpreter (spreadsheets) or compiler (Svelte). React's system does show seams (you really need to be on top of identity and equality) but it is remarkably simple.
React shines, in my mind, for things that aren't form applications. For instance, VR applications with AFrame -- it's somewhere between VRML and Unity. I am working on a (mainly) heart rate variability biofeedback application [2] and it is so easy to make dashboards that display real-time metrics as well as Poincare sections and time series. That is, I can slap together a few data processing functions and widgets and make a new dashboard with new metrics and charts or new sensors. One goal is to get it working on a tablet in a two player version.
The disadvantage of React is that it does not work so well for highly dynamic layouts. In my case I have a library of functions to "fetch" the data stream and put them into the top of the component (may even package as hooks) and then put the layout together with JSX. I'd like to have a version where the user can drag and drop the components to make a custom layout and the system figures out the dependencies for the data fetching, preparation and processing like the things I made in 2006 and that kind of application with a dynamic layout (think programs like Photoshop with lots of different little widgets and property sheets) wants a different approach to reactivity.
[1] use of macros in that book is a red herring, the one example in it where you really need macros is when he is implementing cooperative multitasking, a feature that Python and Javascript already have -- most examples from that book as with Norvig's Lisp book can be coded up just fine with
[2] see https://github.com/paulhoule/VulpusVision it might "just work" if you npm install, npm run dev, and look at it in Chrome and connect with a Polar H10 or other BT monitor
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?
10 replies →
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.
> 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.
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.
1 reply →
The problem is also that every other year contracts/paradigms/... are broken, introducing bugs in libraries and documentation.
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.
> That’s the power of component abstraction.
Yes. But React isn’t the only way to do components. Unfortunately, to the inexperienced, it is.
1 reply →
So is a span or div element? What am I missing here?
5 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>
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 ?
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
8 replies →
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.
4 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?
15 replies →
Hooks were fine, but their implementation in React was barkingly insane. Vue's notion of "composables" is very similar, but not dependent on order, so you can use them in conditional statements without breaking the world. I don't even want to think about doing a complex Vue app without the VueUse library.
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?
There is a difference between implementations getting more complicated vs. interfaces. It doesn’t matter if the mouse has a SoC if it still only exposes the same old USB HID protocol. The issue discussed in this thread is that the developer using the thing isn’t shielded from the increased implementation complexity and can’t just work with the abstraction.
React was built to satisfy the specific scaling and complexity needs of Facebook, and this CV-driven industry jumped on board with it pretending that what's good for Facebook is good for them. The incentives are completely misaligned: it's like nobody gains anything out of using the least amount of force and abstraction to solve a specific problem.
I did frontend before React, and it was a welcomed change. The core insight of UI being a function of state is a good one. It saves you a bunch of headaches from the jQuery days where you’d have multiple code paths per UI element (adding, removing, mutating). That said I think they lost the plot with hooks and things have gotten needlessly complex since then.
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.
I've seen React components where div is used with click event for adding a normal link
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?
https://news.ycombinator.com/item?id=32976978
Not the prettiest but absolutely amazing to use! I'm sure web devs are laughing at me right now, but I genuinely didn't realise websites with that many images etc could actually be that fast.
I would recommend comparing to
https://next-faster.vercel.app/
NextFaster feels faster than McMaster IMHO
4 replies →
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.
> 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 →
As company size grows, managers want to settle on a "standardized" tech stack that doesn't get in the way when they want to hire and fire people at will.
Nobody was ever fired for choosing React (or IBM). But everyone can get fired when they're working on a React app.
> Nobody was ever fired for choosing React. But everyone can get fired when they're working on a React app.
Beautifully put.
One major reason for this, in my past experience, is that designers push for heavily customised components. If you go back to them with “why not use the default radio button with a bit of styling?”, I’ve yet to work with a designer that would relent, the specs are always for crazy UI work.
Its because everyone can see UI, and many have strong opinions on it. Its always the first tragedy of the commons. In a typical tech company built on compromise, fighting the complexity is a fools errand.
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.
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.
They hype-train on all of this stuff is unreal. React+NextJS+Tailwind+ShadCN is just a mess. It's complexity piled on deeper complexity - for little gain! But suggest any of that in many circles and you'll get the standard, "skill issu bro" comebacks. Say what you want about Remix/ReactRouter 7 (there are plenty of issues to talk about there) but at least those guys _tried_ to stay closer to existing web standards. I could go on and on about the disaster of NextJS caching. I could point out RSCs being one way to solve a problem that could already be solved by loaders in other frameworks....
Tailwind was my moment of saying, "Nope, I'm gonna sit this one out". I have a few trusted friends that assure me I'm missing out. I've told them to come back to me after they've done their first major refactor. If they tell me it was a pleasant experience, I'll have another look.
In general, Tailwind and React don't match well. Why use a soup of CSS classes when React has props? If someone needs an a11y-focused base for their component library, they can start with Radix UI directly, ignoring Tailwind and Shadcn.
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.
I'm finding it's better to use "javascript-less" UI frameworks [Pico.CSS, Skeleton, Bulma, Tailwind/daisyUI]. You get most of the benefits using good use of CSS. Anyone used these JS-free solutions and have recommendations?
My current choice is DaisyUI. It’s pretty good and because it’s based on tailwind you get the rest of the ecosystem benefits. Super easy to extend and change. Class bloat is much more manageable than raw tailwind.
If you like how shadcn looks, you might want to consider basecoat: https://basecoatui.com/
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 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.
3 replies →
And even select is fully customisable now if you're targeting modern browsers
3 replies →
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.
7 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 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
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.
7 replies →
> 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.
The case is made. That's awesome.
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
2 replies →
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.
3 replies →
Exactly the same when rendered by the evergreen mainstream browsers. That's perfectly doable.
Author here.
You can do pretty much any styling!
I did a basic example because that matches what Shadcn does (black/white circle) but you can customize it a lot more.
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?
It would. But even then, it would still bloat your html/JavaScript and tank your Lighthouse score
Bingo.
[flagged]
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.
5 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.
If you're not into web development, Hacker News discussions about React are really bad way to gain unbiased perspective - it's been really popular here for last few years to just hate React (usually they know nothing, e.g. anyone who claims hooks compose worse than class components). But there's a reason why React is still used the most (large ecosystem, fast development and backwards compatibility). Of course, it's easy for inexperienced developer to produce slow and buggy apps (maybe slightly easier than in other frameworks, but that's practically unquantifiable), to include unnecessary or even badly written dependencies, etc. - but it's not the tool's fault when it's being used incorrectly.
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
This library doesn't appear to be accessible. Just looking at two random components: The Drawer (https://daisyui.com/components/drawer/) doesn't trap focus inside itself (letting you tab to the page behind the drawer while it's open). The Accordion (https://daisyui.com/components/accordion/) first example is using radio buttons as a hack to avoid Javascript, which would be very confusing to screen reader users (announcing the radio buttons to them).
This is why there's so much complexity in libraries like Radix - accessibility in the real world usually requires a lot of Javascript.
> This is why there's so much complexity in libraries like Radix - accessibility in the real world usually requires a lot of Javascript.
I agree in many scenarios, but for the two you mentioned it seems like the <dialog> and <details> elements provide accessible solutions out of the box?
1 reply →
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.
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.
1 reply →
Is this developed by these 10x developers I've heard about?
For some reason it's exceptionally slow for me on chromium. I click and I see it register half a second later. It also has no cursor:pointer which makes it look non-clickable. Is it expected or a bug?
Straight up doesn't even register clicks or keyboard focus for me in firefox.
Same in chrome on Android. They work if I switch to Base UI tab and back.
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
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.
"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.
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
7 replies →
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 →
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 →
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?
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.
Author here: I tried to find answers in their docs but they don't provide any context. I expected to find an explanation of why to use their solution there but did not.
How would you suggest I reach out?
They probably don't know Chesterton's fence [1].
[1] https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...
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...
Meanwhile the Java landscape that was lampooning got a lot better, and is pretty nice to work in and get shit done.
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?
Native radios are notoriously hard to style consistently across browsers. You can do it with appearance: none, pseudo-elements, etc., but:
- You re-implement focus rings, checked states, hover, disabled, error states.
- You end up bloating your stylesheet incomprehensibly
- Cross-browser differences (especially Safari) still leak through.
- Controlled components, validation layers, animations/transitions, rich layouts are annoying and break accessibility
- Turning native radios into radio cards for example breaks accessibility and keyboard navigation
- Rows with icons, badges, subtext, etc. between the radio and label is a huge issue
Hence why everybody uses Shadcn instead.
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.
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!
https://react-aria.adobe.com is the new Radix, it provides unstyled components with a heavy focus on accessibility and quality. https://github.com/heroui-inc/heroui is the new Shadcn.
One thing to keep in mind regarding a11y, the semantic web is accessible by default. It's once you break away from establish norms do things become harder or tricky, but if you can stick to using actual semantic elements and not div-soup you will cover 90% of your use cases (assuming your use case isn't relying on just the canvas element).
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
I heard that a more modern alternative to radix is react-aria: https://react-aria.adobe.com/
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.
just discovered this link: https://designsystems.surf/design-systems
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 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.
I still don't understand why someone would choose to essentially clone some code vs import a library. Suddenly you increase your maintenance burden, lose updates, etc. I've had no problems at all with UI libraries like Mantine. If you follow this logic, why not just clone all your npm repos and build from source. Ultimate control, right? Please help me understand the benefits here, because I tried out shadcn and wasn't into it
It's for projects that are design-first, where you'll have to implement your own component library that matches the design.
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?
Not really, because I no longer remember. I only remember bugs and frustration. But I looked at my code quickly and found this:
;; Let's render radio buttons ourselves. Because of bugs in React and Chrome, radio buttons mysteriously stop working.
;; https://stackoverflow.com/questions/48423061/radio-buttons-n...
;; https://github.com/facebook/react/issues/3446
followed by my own implementation of radio buttons, followed by:
;; Original implementation, to be used when radio buttons actually work:
followed by an implementation using an input of type radio, commented out.
1 reply →
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.
> on your own basically
The base (Radix UI) was built by a team on WorkOS paycheck.
Not true. Radix was built by a team on a Modulz paycheck, then acquired and (more or less) abandoned by WorkOS.
Your (implicit) point that Shadcn didn't develop the underlying component library still stands.
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.
But handling edge cases is a self-inflicted wound, because you have decided to re-implement something that already has an extremely well tested specification and implementation in the browser. This is almost always a mistake.
Author here. I've implemented all of these with the native radio button and CSS:
> Pixel perfect styling, animations, focus behaviors, interactions with external state, componentized branding to fit in with companies' ecosystems, etc.
Do you have a more specific example of something you've struggled with recently?
> 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 don't think it's hard, it's harder than people think it's going to be. So they get frustrated and start abstracting away, ignoring history and hoping their fresh approach will finally make this thing easy.
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.
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.
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.
They never figured how the exclusive choice works in <input type="radio" name="group">
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.
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.
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.
2 pieces of UI in different parts of the page that depend on the same data - that's the line (also matches the initial goal of React - sync FB chat widgets).
React has sort of become the Java for front end -- ubiquitous and often implemented in a needlessly over-complex way with the type of ceremony devs need to express in order to assuage their own insecurities.
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 needs JS to be interactive unlike the native radio button
I use shadcn/ui for side projects, mostly coding with agents.
Good to have a base design system for building products.
Are there any alternatives? Coded systems, not just UI components.
I much prefer React Aria's components. Yes fuck Adobe but take their RadioGroup for example: https://react-aria.adobe.com/RadioGroup Much better than shadcn's in terms of deps and LOC, and it uses an input. All of their components are built for accessibility first.
Thanks, no love for Adobe but React Aria seems good. Saved, will look in to it.
Yup, agents LOVE Tailwind+ShadCN. Even when I've explicitly told them not to use it, it still creeps in. There's a lot of prior art out on GitHub and LLMs can't help themselves. FWIW, the result does tend to look nice enough. For a POC I can't complain. If I'm really going to roll up my sleeves and get into the code though? I don't think I'd enjoy all of it.
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.
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.
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
Yup. Unfortunately common I think - not just with UI components. Occam's razor is sometimes only for others.
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.
> Look at it. It's beautiful.
Quite right too … I’m choosing HTMX over React for just that.
I don’t see the “complexity” the author is yelling about. Maybe is the tailwind verbosity?
It seems they don’t understand the underlying requirements when building a reusable UI library. Yes in shadcn there are some opinionated choices , but the “i can do better/ i am smarter” attitude of this article is off putting.
We used shadcn in one project , and wrote a custom UI library for another (using the same “smart trick” for input elements). Shadcn wins for clarity, consistency, maintenanility and simplicity.
Shadcn is an anti-pattern.
I evaluated a LOT of UI toolkits for React. The premise is always great - I want to save time by not having to build a UI toolkit for my application, so I'll use a great one off the shelf. But what I found was that the evaluation falls into three questions:
1. Does it look nice and professional?
2. Will it be here tomorrow?
3. How does it feel to work with - what does my instinct say?
The first question is easy. I either like it or not. I can't answer the second one with certainty. Nobody can. I can only guess. Sometimes I'm wrong.
The third one is instinct driven. If the ergonomics feel off, my instinct will tell me. If something is not right, I'll feel it. I might not always be able to explain it, but I'll know it's a go or no go. ShadCDN came with big praise, but my instinct said a big Nope. It's stuff like that that make me think that, maybe, we add complexity because we get bored with the "boring" tech.
So? Did you open a PR for shadcdn or Radix? Did you throw out the shadcdn code rendering the radio button from your codebase? Did you ensure it doesn't come back the next version?
Otherwise you haven't engineered anything, you've barely outlined the concept of a plan.
Two lessons here: The complexity exists for a reason. Try to understand where it comes from.
Second: Thinking "it could be done this way, I think" is barely 1% of really outlining a solution, implementing it and convincing others to use it. The latter is the hard part, but actually changes things outside of your head..
That's why I never touch web frontend dev.
And then you realize this paradigm plagues even desktop applications through electron and the like. Enshittification knows no borders or limits.
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
[dead]
[dead]
[flagged]
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.
If all you have to contribute is being insulting, you don't have to comment.
What makes you think reading the code makes someone less curious than relying on someone else’s made up answer about it.
and people complain about AI code?
Shadcn most likely contains a lot of LLM generated code. Isn't it owned by Vercel these days?
> 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.
1 reply →
Yes, several times. I've been specializing in front-end dev for over a decade.
I shared a simple example because Shadcn has a simple design.
You do often hide the native appearance if you need something complex, but doing that via CSS is still much simpler than a bunch of JS and a third party dependency.
If you have a specific design in mind I can show you how to do it.
I almost had the same reaction tbh! Like I remember inline-grid and place-content for example was not at all supported css, it would've been a nightmare to do, but modern browsers css support is way more powerful than my mental model of them still is. So it's time to update that mental model.