21–30 of 351 posts
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.
https://www.radix-ui.com/primitives/docs/components/radio-gr...
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?
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.
It does seem the complexity was a deliberate decision.
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 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…
input[type="radio"] {
appearance: none;
margin: 0;
width: 25px;
height: 25px;
background: white;
border-radius: 50%;
display: inline-grid;
place-content: center;
box-shadow: 0 2px 10px color(display-p3 0 0 0/0.5);
&::before {
content: "";
width: 11px;
height: 11px;
border-radius: 50%;
}
&:checked::before {
background: color(display-p3 0.383 0.317 0.702);
}
}
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 us…
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.
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 inevita…
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.
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…
> - Make sure it looks the exact same across all browsers
> How doable is it with vanilla css?
"Make sure it looks the exact same across all browsers" is, and always has been, fundamentally at odds with how the web is intended to work.
How well does this shadcn crap render in arachne? ladybird? netsurf? links? dillo? netscape 3? The latest version of chrome with user styles applied?
When you say "exactly the same", I assume you mean that the design only uses black and white, because some people might have black and white monitors, right? But you're also going to use amber-on-black because some people might have amber screen monitors, right? How do you plan on ensuring it looks exactly the same on a braille terminal?
Maybe you think I'm being silly. Because nobody uses monochrome monitors in 2026, right? So it's safe to ignore that and put an asterisk next to "exactly the same" (And also just forget that e-ink is a thing that exists).
(Just like how it was safe in 2006 to assume people would always have 800x600 or bigger displays, and nobody would ever come along using a screen with, say, 480×320 resolution)
What measures have you taken to ensure that your colours appear exactly the same across a bunch of different types/brands of monitors that render colours differently? Or, perhaps we should just add another asterisk next to "exactly the same"?
I could go on.
How many asterisks is acceptable before "exactly the same" isn't a thing anymore?
If "exactly the same on all browsers" is one of your goals, you are wrong. If your designer tells you that's what they want, they are wrong. If you ever tell a client that's what you're providing, you are wrong.
This 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 us…
> 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.