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.

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?

I was sitting next to one of the devs in a co-working space and he was trying to figure out some specific layout issue in react native. He spent 4 hours + installed a dependency to be able to do something completely tiny on a privacy policy screen. He asked me how I would do it, I told him to just ask if it can be laid out differently. He got it approved and implemented in 10 minutes. No bloat.

If you're one of those who think we should just use the default, bear in mind that the default radio button has poor usability for mobile users.

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.

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

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

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.

Would be nice to list them here so developers can know a midpoint between DIY <-> Shadcn/Radix

Copied styles from the radix docs: https://www.radix-ui.com/primitives/docs/components/radio-gr...

[1] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

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.

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.

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?

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

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 imagine for some usecase, they are valuable. However, when reading advice on the internet you get comments from people that tell you what technology they used without consideration of the overhead required to use this technology and the problem at hand.

Don't get me wrong, a HTML5 radio button is a beautiful thing, and sometimes React is a hammer and everything is a nail.

However, I think something that OP doesn't mention super explicitly in their post is the codebase they are working on is probably a React codebase. React is a great abstraction for building UIs. I've built a ton of them and the complexity only needs to go above a certain degree until you need a way more descriptive way of explaining your UI based upon other state, instead of trying to wire a load of DOM elements together.

If you are already using the React ecosystem, for things like form validation (again, possible with HTML5 but as soon as the complexity cranks or you can't use the server - you probably need a library), then using something like Radix is a great choice, OP even mentions how although it's not technically a visible radio button that is shipped to the DOM, it acts like one for a11y reasons, and this is due in part because it's very, very easy to write inaccessible HTML. And ShadCN is pre-made components on top of that, and they all work pretty well together.

Nothing is perfect, but even in my "old man yells at cloud" era, I personally don't think this one is worth yelling at the cloud for.

Good to have a base design system for building products.

Are there any alternatives? Coded systems, not just UI components.

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.

Quite right too … I’m choosing HTMX over React for just that.

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/

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.

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.

Otherwise you haven't engineered anything, you've barely outlined the concept of a plan.

Two lessons here: The complexity exists for a reason. Try to understand where it comes from.

Second: Thinking "it could be done this way, I think" is barely 1% of really outlining a solution, implementing it and convincing others to use it. The latter is the hard part, but actually changes things outside of your head..

yeah sad state of affairs

Have you tried completely customising a radio button with CSS? Feel free to demonstrate a heavily customised radio button style where you don’t hide the native appearance.