10 ms·

The Overcomplexity of the Shadcn Radio Button

528 points by dbushell 8mo ago

sceptic123 8mo ago
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.
- sam_lowry_ 8mo ago
  They never figured how the exclusive choice works in <input type="radio" name="group">
neya 8mo ago
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.
PunchTornado 8mo ago
and people complain about AI code?
- deleted 8mo ago
  [deleted]
- helloplanets 8mo ago
  Shadcn most likely contains a lot of LLM generated code. Isn't it owned by Vercel these days?
worldsayshi 8mo ago
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.
- scoot 8mo ago
  > 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.
  - worldsayshi 8mo ago
    Sure, that's true. I oversimplified.
  - chrysoprace 8mo ago
    Sure, but if you wanted to change it to just use a radio input you could. Shadcn gives you a baseline.
    - troupo 8mo ago
      native radio buttons gives you a baseline. You can only call Shadcn a "baseline" if it was a baseline of the last floor of the babel tower of abstractions.
- stevepotter 8mo ago
  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
  - sesm 8mo ago
    It's for projects that are design-first, where you'll have to implement your own component library that matches the design.
eddie1o 8mo ago
There has to be a reason for picking button instead of input type="radio", right?
- curtisblaine 8mo ago
  Yep, radio buttons weren't easily stylable in all evergreen browsers back on 2020.
mastermedo 8mo ago
The shadcn radio button in action: https://ui.shadcn.com/docs/components/radio-group https://ui.shadcn.com/docs/components/radio-group
- maelito 8mo ago
  This interactivity definitely adds a wow effect.
  - supriyo-biswas 8mo ago
    Is it sarcastic or does it appear only on high frame rate devices? To me it simply feels like another radio button.
    - hu3 8mo ago
      > Is it sarcastic or does it appear only on high frame rate devices? To me it simply feels like another radio button. You're absolutely right! Today I'm using a friends gaming computer. It's a 244hz monitor powered by a RTX 5070 TI and a screamingly fast AMD Ryzen 7 9800X3D CPU with 128GB of overclocked 6000MT/s RAM. Not only does the radio look mundane for such overcomplicated component, but it also misses clicks where I would expect it to register. Like slightly above or below it. For example, clicking where the pointer is in this image does NOT select the first radio button. It's not forgiving with regards to precision. https://i.imgur.com/PNoCJeL.png https://i.imgur.com/PNoCJeL.png
      - skrebbel 8mo ago
        It also doesn't catch clicks between the label and the radio button.
    - skibz 8mo ago
      I'm pretty sure it was a sarcastic comment. On a recent MBP, it's indistinguishable from a vanilla radio button.
  - deleted 8mo ago
xearl 8mo ago
Did they ask the original authors of Radix why it's the way it is?
- leoff 8mo ago
  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.
  - pftburger 8mo ago
    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
    - stephenr 8mo ago
      > a group of experts in simplicity and accessibility According to who? This alone is a pretty damning case against such a claim.
  - Alupis 8mo ago
    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 https://github.com/radix-ui/primitives/pull/121
    - chrismorgan 8mo ago
      Half of that complexity springs from the requirement of being able to put any element as the radio button. If you’re willing to say “you can only use anything that can be expressed with CSS applied to the <input type=radio>, including psuedoelements” (which is plenty for thing like shadcn), it melts away. The other half of it looks to come from an overloaded Label component which should probably have been split into two. There’s a reason that HTML has <fieldset> and <label> as different things. The implementation is also trivially incorrect: role=label isn’t a thing. Other parts of it are wrong or dubious too. In general, if the HTML way of expressing something isn’t permitted, the ARIA way of expressing the same thing is probably wrong too. And so it goes, through the entire system. They assume you might want something ridiculously complex, and so they complicate and make worse the normal case.
parhamn 8mo ago
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-group 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.
- atoav 8mo ago
  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).
  - rustystump 8mo ago
    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.
    - stephenr 8mo ago
      > It is like fast food, not every cares about farm to table I mean, a "colorful fat choncker" website is literally the opposite of fast food - its slower to arrive, and focuses way too much on appearances. In this analogy, the website using these ridiculous abstractions is more like Salt Bae or whatever idiotic trend has replaced him. All glitz, zero substance, slower, and for no apparent reason. The fast food equivalent is stuff like the Google home page: it doesn't validate, is actively harmful to you, the community, and the planet but is immensely popular.
maelito 8mo ago
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.
- dchest 8mo ago
  How do you implement this keyboard navigation with SSR (if you use buttons)? https://www.radix-ui.com/primitives/docs/components/radio-group#keyboard-interactions https://www.radix-ui.com/primitives/docs/components/radio-gr...
  - DougBTX 8mo ago
    I can’t tell if this is sarcasm or not! Radio buttons support keyboard navigation without JS.
    - dchest 8mo ago
      That's what I mean: if you reimplement it, you need client-side JS to support keyboard navigation.
- paulhebert 8mo ago
  It needs JS to be interactive unlike the native radio button
shubhamjain 8mo ago
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/ https://basecoatui.com/
- discomrobertul8 8mo ago
  > 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.
  - rustystump 8mo ago
    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.
    - BigJ1211 8mo ago
      I don't really keep up with these Tech/Soft tubers, but watch a video on occasion. Can't really say I find something-imagen guilty of this, but like I said I watch the occasional video, not the stream. What I've watched from him is generally about what he agrees/disagrees with and he also tells you why he thinks that. Often reading articles/blogposts. Not to dismiss your opinion, but I would put him in the entertaining with substantive arguments category. IMO software education/tainment suffers much worse though. They teach you how to do X in only this specific way with these specific tools, generally sponsored. Not the admittedly far more boring basics to do it yourself, or how to actually use these tools in a broader sense.
benrutter 8mo ago
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?
- rustystump 8mo ago
  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.
- yellow_lead 8mo ago
  > does anyone have a good example of a large website built without all this bloat? How about this one?
  - teaearlgraycold 8mo ago
    Don’t think it counts
    - rrr_oh_man 8mo ago
      Why not?
      - 946789987649 8mo ago
        I'm assuming they're asking for large in terms of complexity, not in terms of popularity.
Surac 8mo ago
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
- curtisblaine 8mo ago
  > 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.
  - dreadnip 8mo ago
    Most web apps are a combination of static pages, simple forms and highly interactive content though. That's what makes the choice so hard.
    - christophilus 8mo ago
      That’s why I use React, though. It’s much nicer (as a developer— not necessarily UX) to have a single paradigm and approach to building your app vs using one approach for the simple pages and a different approach for the handful of highly interactive pages. Inevitably, your simple pages get complex interactive edge cases and you wish you’d written those in React from the start, etc. I know many will disagree with me and will point to livewire, etc as alternative approaches, and that’s valid. I’ve simply settled on React because it fits my mental model, I like functional programming, and I dislike that bifurcation problem.
deleted 8mo ago
[deleted]
demarq 8mo ago
[flagged]
- deleted 8mo ago
  [deleted]
- Dylan16807 8mo ago
  If all you have to contribute is being insulting, you don't have to comment.
- anonymous908213 8mo ago
  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.
- iammrpayments 8mo ago
  What makes you think reading the code makes someone less curious than relying on someone else’s made up answer about it.
joduplessis 8mo ago
Yup. Unfortunately common I think - not just with UI components. Occam's razor is sometimes only for others.
pembrook 8mo ago
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.
- mad182 8mo ago
  Radio buttons are in html spec for over 30 years and they allow extensive CSS styling on every part of the element.
- oneeyedpigeon 8mo ago
  > 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?
  - pembrook 8mo ago
    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.
jackfranklyn 8mo ago
[flagged]
- snowmobile 8mo ago
  [flagged]
- normie3000 8mo ago
  > 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?
  - adithyassekhar 8mo ago
    Bingo.
  - milutinovici 8mo ago
    It would. But even then, it would still bloat your html/JavaScript and tank your Lighthouse score
ehnto 8mo ago
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.
- teaearlgraycold 8mo ago
  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.
  - tiborsaas 8mo ago
    What is cache in this context? useState? What do you mean by cache invalidation in react apps?
    - azangru 8mo ago
      Stale closures, perhaps.
      - danabramov 8mo ago
        It never happens if you enable the lint rule.
        azangru 8mo ago
        I remember how react team's message, around the time hooks were introduced, was how hooks were going to save us from the tyranny of `this`, which people presumably found confusing. I often think back to that message, while adding things in a dependency array. Especially those things that I know won't change (e.g. the redux `dispatch` function pulled from the context), but the linter doesn't. Or while being admonished by the linter for reading from a ref, or writing to it.
deleted 8mo ago
[deleted]
dagss 8mo ago
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..
- ErroneousBosh 8mo ago
  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 https://mincss.com/examples.html [2] https://htmx.org/ https://htmx.org/
  - dagss 8mo ago
    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.
supermatt 8mo ago
> 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.
- snowmobile 8mo ago
  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?
  - supermatt 8mo ago
    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.
    - efilife 8mo ago
      > and then you are effectively back to what radix does I certainly won't need to import x elements from a library that imports y elements itself
- lyu07282 8mo ago
  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.
- paulhebert 8mo ago
  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.
interstice 8mo ago
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.
jwr 8mo ago
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.
- uxcolumbo 8mo ago
  Can you provide more details about the issues?
  - jwr 8mo ago
    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-need-to-click-twice-to-reflect-change https://stackoverflow.com/questions/48423061/radio-buttons-n... ;; https://github.com/facebook/react/issues/3446 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.
    - paulhebert 8mo ago
      Reading through the threads that sounds like a React bug not a browser bug
feverzsj 8mo ago
That's why I never touch web frontend dev.
ediatedia 8mo ago
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.
- oneeyedpigeon 8mo ago
  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.
  - rune-dev 8mo ago
    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.
caseyross 8mo ago
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.
- snowmobile 8mo ago
  > 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.
  - virtujoel 8mo ago
    >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/ 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 https://react-aria.adobe.com/blog/building-a-combobox (I haven't used Radix so I'm unsure how well they do a11y)
yen223 8mo ago
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.
- spiderfarmer 8mo ago
  > 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!
- ruszki 8mo ago
  The article explains how to style radio buttons with CSS however you want. What’s the problem with that?
  - supermatt 8mo ago
    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.
    - ifh-hn 8mo ago
      But is that still less complex than what the author found?
    - ruszki 8mo ago
      Can you give an example please? What kind of complexity are we talking about?
      - supermatt 8mo ago
        Any kind of nested markup: styled content, additional animation layers, etc.
mcintyre1994 8mo ago
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 https://codepen.io/mcintyre94/pen/pvbPVrP Copied styles from the radix docs: https://www.radix-ui.com/primitives/docs/components/radio-group https://www.radix-ui.com/primitives/docs/components/radio-gr...
jojobas 8mo ago
And then you realize this paradigm plagues even desktop applications through electron and the like. Enshittification knows no borders or limits.
janlucien 8mo ago
[dead]
kaizenb 8mo ago
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.
- dylmye 8mo ago
  I much prefer React Aria's components. Yes fuck Adobe but take their RadioGroup for example: https://react-aria.adobe.com/RadioGroup 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.
  - kaizenb 8mo ago
    Thanks, no love for Adobe but React Aria seems good. Saved, will look in to it.
- nobleach 8mo ago
  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.
gustavorg 8mo ago
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.
cadamsdotcom 8mo ago
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?
- snowmobile 8mo ago
  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: <input type="radio" name="beverage" value="coffee" /> 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?
  - vachina 8mo ago
    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.
CommonGuy 8mo ago
I recently tried out https://daisyui.com/ 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
- virtujoel 8mo ago
  This library doesn't appear to be accessible. Just looking at two random components: The Drawer (https://daisyui.com/components/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/ 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.
  - paulhebert 8mo ago
    > 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?
    - shimman 8mo ago
      They do, most issues that arise from making things accessible are self inflicted. Some people just want to redesign things for the sake of design while ignoring a core principle of design (accessibility) over aesthetics. Sounds harsh but maybe somethings SHOULDN'T be designed a certain way because it breaks a11y when there are other roads to be taken that can still look pleasant, be accessible, and way easier to maintain (less brittle JS to worry about).
tekkk 8mo ago
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.
- sesm 8mo ago
  > on your own basically The base (Radix UI) was built by a team on WorkOS paycheck.
  - scoot 8mo ago
    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.
tmvnty 8mo ago
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
- FrontAid 8mo ago
  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 https://frontaid.ch/web/ui/libraries.html
  - worble 8mo ago
    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!
- christophilus 8mo ago
  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.
- thiht 8mo ago
  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
- hombre_fatal 8mo ago
  One midpoint is traditional css frameworks like https://getbootstrap.com/ 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.
ponyous 8mo ago
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.
- jadbox 8mo ago
  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?
  - ponyous 8mo ago
    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.
  - beckler 8mo ago
    If you like how shadcn looks, you might want to consider basecoat: https://basecoatui.com/ https://basecoatui.com/
dzonga 8mo ago
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
agumonkey 8mo ago
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
adithyassekhar 8mo ago
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.
- nobleach 8mo ago
  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.
- sesm 8mo ago
  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.
notpushkin 8mo ago
Shadcn is an anti-pattern.
elias1233 8mo ago
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.
PlatoIsADisease 8mo ago
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.
librasteve 8mo ago
> Look at it. It's beautiful. Quite right too … I’m choosing HTMX over React for just that.
yalue 8mo ago
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/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
- mrguyorama 8mo ago
  Meanwhile the Java landscape that was lampooning got a lot better, and is pretty nice to work in and get shit done.
Piraty 8mo ago
> 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>
- stevepotter 8mo ago
  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.
draw_down 8mo ago
[dead]
bromuro 8mo ago
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.
harel 8mo ago
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.
game_the0ry 8mo ago
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.
knallfrosch 8mo ago
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..

528 points by dbushell 8mo ago

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.

sam_lowry_ 8mo ago
They never figured how the exclusive choice works in <input type="radio" name="group">

neya 8mo ago

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.

PunchTornado 8mo ago

and people complain about AI code?

deleted 8mo ago
[deleted]
helloplanets 8mo ago
Shadcn most likely contains a lot of LLM generated code. Isn't it owned by Vercel these days?

worldsayshi 8mo ago

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.

scoot 8mo ago
> 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.
- worldsayshi 8mo ago
  Sure, that's true. I oversimplified.
- chrysoprace 8mo ago
  Sure, but if you wanted to change it to just use a radio input you could. Shadcn gives you a baseline.
  - troupo 8mo ago
    native radio buttons gives you a baseline. You can only call Shadcn a "baseline" if it was a baseline of the last floor of the babel tower of abstractions.
stevepotter 8mo ago
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
- sesm 8mo ago
  It's for projects that are design-first, where you'll have to implement your own component library that matches the design.

eddie1o 8mo ago

There has to be a reason for picking button instead of input type="radio", right?

curtisblaine 8mo ago
Yep, radio buttons weren't easily stylable in all evergreen browsers back on 2020.

mastermedo 8mo ago

The shadcn radio button in action: https://ui.shadcn.com/docs/components/radio-group https://ui.shadcn.com/docs/components/radio-group

maelito 8mo ago
This interactivity definitely adds a wow effect.
- supriyo-biswas 8mo ago
  Is it sarcastic or does it appear only on high frame rate devices? To me it simply feels like another radio button.
  - hu3 8mo ago
    > Is it sarcastic or does it appear only on high frame rate devices? To me it simply feels like another radio button. You're absolutely right! Today I'm using a friends gaming computer. It's a 244hz monitor powered by a RTX 5070 TI and a screamingly fast AMD Ryzen 7 9800X3D CPU with 128GB of overclocked 6000MT/s RAM. Not only does the radio look mundane for such overcomplicated component, but it also misses clicks where I would expect it to register. Like slightly above or below it. For example, clicking where the pointer is in this image does NOT select the first radio button. It's not forgiving with regards to precision. https://i.imgur.com/PNoCJeL.png https://i.imgur.com/PNoCJeL.png
    - skrebbel 8mo ago
      It also doesn't catch clicks between the label and the radio button.
  - skibz 8mo ago
    I'm pretty sure it was a sarcastic comment. On a recent MBP, it's indistinguishable from a vanilla radio button.
- deleted 8mo ago

xearl 8mo ago

Did they ask the original authors of Radix why it's the way it is?

leoff 8mo ago
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.
- pftburger 8mo ago
  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
  - stephenr 8mo ago
    > a group of experts in simplicity and accessibility According to who? This alone is a pretty damning case against such a claim.
- Alupis 8mo ago
  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 https://github.com/radix-ui/primitives/pull/121
  - chrismorgan 8mo ago
    Half of that complexity springs from the requirement of being able to put any element as the radio button. If you’re willing to say “you can only use anything that can be expressed with CSS applied to the <input type=radio>, including psuedoelements” (which is plenty for thing like shadcn), it melts away. The other half of it looks to come from an overloaded Label component which should probably have been split into two. There’s a reason that HTML has <fieldset> and <label> as different things. The implementation is also trivially incorrect: role=label isn’t a thing. Other parts of it are wrong or dubious too. In general, if the HTML way of expressing something isn’t permitted, the ARIA way of expressing the same thing is probably wrong too. And so it goes, through the entire system. They assume you might want something ridiculously complex, and so they complicate and make worse the normal case.

parhamn 8mo ago

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

atoav 8mo ago
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).
- rustystump 8mo ago
  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.
  - stephenr 8mo ago
    > It is like fast food, not every cares about farm to table I mean, a "colorful fat choncker" website is literally the opposite of fast food - its slower to arrive, and focuses way too much on appearances. In this analogy, the website using these ridiculous abstractions is more like Salt Bae or whatever idiotic trend has replaced him. All glitz, zero substance, slower, and for no apparent reason. The fast food equivalent is stuff like the Google home page: it doesn't validate, is actively harmful to you, the community, and the planet but is immensely popular.

maelito 8mo ago

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.

dchest 8mo ago
How do you implement this keyboard navigation with SSR (if you use buttons)? https://www.radix-ui.com/primitives/docs/components/radio-group#keyboard-interactions https://www.radix-ui.com/primitives/docs/components/radio-gr...
- DougBTX 8mo ago
  I can’t tell if this is sarcasm or not! Radio buttons support keyboard navigation without JS.
  - dchest 8mo ago
    That's what I mean: if you reimplement it, you need client-side JS to support keyboard navigation.
paulhebert 8mo ago
It needs JS to be interactive unlike the native radio button

shubhamjain 8mo ago

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/ https://basecoatui.com/

discomrobertul8 8mo ago
> 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.
- rustystump 8mo ago
  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.
  - BigJ1211 8mo ago
    I don't really keep up with these Tech/Soft tubers, but watch a video on occasion. Can't really say I find something-imagen guilty of this, but like I said I watch the occasional video, not the stream. What I've watched from him is generally about what he agrees/disagrees with and he also tells you why he thinks that. Often reading articles/blogposts. Not to dismiss your opinion, but I would put him in the entertaining with substantive arguments category. IMO software education/tainment suffers much worse though. They teach you how to do X in only this specific way with these specific tools, generally sponsored. Not the admittedly far more boring basics to do it yourself, or how to actually use these tools in a broader sense.

benrutter 8mo ago

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?

rustystump 8mo ago
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.
yellow_lead 8mo ago
> does anyone have a good example of a large website built without all this bloat? How about this one?
- teaearlgraycold 8mo ago
  Don’t think it counts
  - rrr_oh_man 8mo ago
    Why not?
    - 946789987649 8mo ago
      I'm assuming they're asking for large in terms of complexity, not in terms of popularity.

Surac 8mo ago

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

curtisblaine 8mo ago
> 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.
- dreadnip 8mo ago
  Most web apps are a combination of static pages, simple forms and highly interactive content though. That's what makes the choice so hard.
  - christophilus 8mo ago
    That’s why I use React, though. It’s much nicer (as a developer— not necessarily UX) to have a single paradigm and approach to building your app vs using one approach for the simple pages and a different approach for the handful of highly interactive pages. Inevitably, your simple pages get complex interactive edge cases and you wish you’d written those in React from the start, etc. I know many will disagree with me and will point to livewire, etc as alternative approaches, and that’s valid. I’ve simply settled on React because it fits my mental model, I like functional programming, and I dislike that bifurcation problem.

deleted 8mo ago

[deleted]

demarq 8mo ago

[flagged]

deleted 8mo ago
[deleted]
Dylan16807 8mo ago
If all you have to contribute is being insulting, you don't have to comment.
anonymous908213 8mo ago
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.
iammrpayments 8mo ago
What makes you think reading the code makes someone less curious than relying on someone else’s made up answer about it.

joduplessis 8mo ago

Yup. Unfortunately common I think - not just with UI components. Occam's razor is sometimes only for others.

pembrook 8mo ago

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.

mad182 8mo ago
Radio buttons are in html spec for over 30 years and they allow extensive CSS styling on every part of the element.
oneeyedpigeon 8mo ago
> 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?
- pembrook 8mo ago
  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.

jackfranklyn 8mo ago

[flagged]

snowmobile 8mo ago
[flagged]
normie3000 8mo ago
> 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?
- adithyassekhar 8mo ago
  Bingo.
- milutinovici 8mo ago
  It would. But even then, it would still bloat your html/JavaScript and tank your Lighthouse score

ehnto 8mo ago

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.

teaearlgraycold 8mo ago
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.
- tiborsaas 8mo ago
  What is cache in this context? useState? What do you mean by cache invalidation in react apps?
  - azangru 8mo ago
    Stale closures, perhaps.
    - danabramov 8mo ago
      It never happens if you enable the lint rule.
      - azangru 8mo ago
        I remember how react team's message, around the time hooks were introduced, was how hooks were going to save us from the tyranny of `this`, which people presumably found confusing. I often think back to that message, while adding things in a dependency array. Especially those things that I know won't change (e.g. the redux `dispatch` function pulled from the context), but the linter doesn't. Or while being admonished by the linter for reading from a ref, or writing to it.

deleted 8mo ago

[deleted]

dagss 8mo ago

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

ErroneousBosh 8mo ago
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 https://mincss.com/examples.html [2] https://htmx.org/ https://htmx.org/
- dagss 8mo ago
  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.

supermatt 8mo ago

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

snowmobile 8mo ago
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?
- supermatt 8mo ago
  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.
  - efilife 8mo ago
    > and then you are effectively back to what radix does I certainly won't need to import x elements from a library that imports y elements itself
lyu07282 8mo ago
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.
paulhebert 8mo ago
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.

interstice 8mo ago

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.

jwr 8mo ago

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.

uxcolumbo 8mo ago
Can you provide more details about the issues?
- jwr 8mo ago
  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-need-to-click-twice-to-reflect-change https://stackoverflow.com/questions/48423061/radio-buttons-n... ;; https://github.com/facebook/react/issues/3446 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.
  - paulhebert 8mo ago
    Reading through the threads that sounds like a React bug not a browser bug

feverzsj 8mo ago

That's why I never touch web frontend dev.

ediatedia 8mo ago

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.

oneeyedpigeon 8mo ago
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.
- rune-dev 8mo ago
  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.

caseyross 8mo ago

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.

snowmobile 8mo ago
> 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.
- virtujoel 8mo ago
  >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/ 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 https://react-aria.adobe.com/blog/building-a-combobox (I haven't used Radix so I'm unsure how well they do a11y)

yen223 8mo ago

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.

spiderfarmer 8mo ago
> 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!
ruszki 8mo ago
The article explains how to style radio buttons with CSS however you want. What’s the problem with that?
- supermatt 8mo ago
  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.
  - ifh-hn 8mo ago
    But is that still less complex than what the author found?
  - ruszki 8mo ago
    Can you give an example please? What kind of complexity are we talking about?
    - supermatt 8mo ago
      Any kind of nested markup: styled content, additional animation layers, etc.

mcintyre1994 8mo ago

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 https://codepen.io/mcintyre94/pen/pvbPVrP Copied styles from the radix docs: https://www.radix-ui.com/primitives/docs/components/radio-group https://www.radix-ui.com/primitives/docs/components/radio-gr...

jojobas 8mo ago

And then you realize this paradigm plagues even desktop applications through electron and the like. Enshittification knows no borders or limits.

janlucien 8mo ago

[dead]

kaizenb 8mo ago

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.

dylmye 8mo ago
I much prefer React Aria's components. Yes fuck Adobe but take their RadioGroup for example: https://react-aria.adobe.com/RadioGroup 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.
- kaizenb 8mo ago
  Thanks, no love for Adobe but React Aria seems good. Saved, will look in to it.
nobleach 8mo ago
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.

gustavorg 8mo ago

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.

cadamsdotcom 8mo ago

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?

snowmobile 8mo ago
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: <input type="radio" name="beverage" value="coffee" /> 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?
- vachina 8mo ago
  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.

CommonGuy 8mo ago

I recently tried out https://daisyui.com/ 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

virtujoel 8mo ago
This library doesn't appear to be accessible. Just looking at two random components: The Drawer (https://daisyui.com/components/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/ 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.
- paulhebert 8mo ago
  > 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?
  - shimman 8mo ago
    They do, most issues that arise from making things accessible are self inflicted. Some people just want to redesign things for the sake of design while ignoring a core principle of design (accessibility) over aesthetics. Sounds harsh but maybe somethings SHOULDN'T be designed a certain way because it breaks a11y when there are other roads to be taken that can still look pleasant, be accessible, and way easier to maintain (less brittle JS to worry about).

tekkk 8mo ago

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.

sesm 8mo ago
> on your own basically The base (Radix UI) was built by a team on WorkOS paycheck.
- scoot 8mo ago
  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.

tmvnty 8mo ago

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

FrontAid 8mo ago
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 https://frontaid.ch/web/ui/libraries.html
- worble 8mo ago
  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!
christophilus 8mo ago
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.
thiht 8mo ago
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
hombre_fatal 8mo ago
One midpoint is traditional css frameworks like https://getbootstrap.com/ 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.

ponyous 8mo ago

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.

jadbox 8mo ago
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?
- ponyous 8mo ago
  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.
- beckler 8mo ago
  If you like how shadcn looks, you might want to consider basecoat: https://basecoatui.com/ https://basecoatui.com/

dzonga 8mo ago

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

agumonkey 8mo ago

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

adithyassekhar 8mo ago

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.

nobleach 8mo ago
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.
sesm 8mo ago
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.

notpushkin 8mo ago

Shadcn is an anti-pattern.

elias1233 8mo ago

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.

PlatoIsADisease 8mo ago

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.

librasteve 8mo ago

> Look at it. It's beautiful. Quite right too … I’m choosing HTMX over React for just that.

yalue 8mo ago

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/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

mrguyorama 8mo ago
Meanwhile the Java landscape that was lampooning got a lot better, and is pretty nice to work in and get shit done.

Piraty 8mo ago

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

stevepotter 8mo ago
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.

draw_down 8mo ago

[dead]

bromuro 8mo ago

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.

harel 8mo ago

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.

game_the0ry 8mo ago

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.

knallfrosch 8mo ago

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