I don't touch frontend very often anymore, but you could see the writing on the wall for complexity when React took over and newer devs were working exclusively in that abstraction.
Unlike other abstractions where things get tidied up and more simple, React is much more complex than the technology it's building on. Necessarily, to enable it's features, but none the less it is a consequence of this that when all someone knows is React or other frameworks, things get overengineered. They didn't realise it could be so much simpler if they just knocked it back a layer instead of climbing higher and higher.
> when all someone knows is React or other frameworks, things get overengineered
The next level annoyance is that everybody just assumes React to be the default for everything.
Check the Shadcn website. The landing page doesn’t mention that this is a React-only UI library at all. Same with Radix. The marketing sounds like a general-purpose UI lib. You gotta dig around a bit to realize that this is React-only.
Thanks, I did not know this existed and I find it awesome. How was the experience using it? I wonder if it's well maintained or if it has any annoying quirks.
But that's just classically styled library like bootstrap? How is it in any way similar to shadcn where you copy the component definitions to your code and restyle them with tailwind? It looks visually similar, but completely misses the point of why someone would use shadcn. Also many of the components have degraded functionality on firefox, I couldn't use this in an actual production application.
Personally I also tend to hate on what React has made the modern web, and I say this as someone who's made money for the past 10 years making React apps, but reimplementing half of something poorly and declaring success because it looks kinda similar when you squint is just silly. Many (most?) "pure html frameworks" are like this unfortunately.
my brain for whatever reason won't accept react it's just instant ejection. i was there in the before times all the way up till jquery became uncool and i just tuned out of front end entirely once react and all the stuff driven by facebook became so ubiquitous, my soul just does not want to dabble in any of it.
i think im mostly just appalled at what feels like over complexity that might've made sense over a decade ago but perhaps im waiting for a more satisfying paradigm to come along. i dunno. i had some sparks of joy tinkering with golang to build ssr stuff, i dont keep up with wasm at all but i hope its cruising along.
i wonder if what im after is like some kinda dead simple easy to use declarative front end api that can be built from a backend, something like streamlit or nicegui that has great ergonomics and is easy to maintain but scales better and has better state mgmt than streamlit & puts all the power of a general purpose programming language right there with it. i love compiled things i hate setting up environments with runtimes and stuff.
I get the feeling. From someone outside looking in (haven’t done web work since the heyday of Rails), React and the associated modern stack looks a whole lot like a Homermobile built on the frame and engine of a go-kart, all held together with duct tape and twine sourced from TEMU. The idea that this is the web’s “final form” is difficult to stomach.
FWIW I've been writing UIs using plain JavaScript and the DOM API for like 15 years and at a certain scale, I always ended up building an ad-hoc framework or being disgruntled when I had to reach for any of the pre-React UI frameworks whose APIs and approaches I didn't like. React changes this, nowadays I either start with pure DOM and then rewrite to React or just start with React. I see a lot of hate online for React these days and I agree with probably 99 % of it, but the problem in my eyes is not React itself, but the ecosystem that spurred around it. If you stick to just React and take some care with your craft, React is a joy to use IME.
Not everything needs to be a SPA. I genuinely believe that the web would've been a much better place today on most important metrics (performance, simplicity, accessibility etc.) if this SPA shift would've never happened. The opportunity cost seems massive to me.
Most software I've used could have been a few hundred lines of PHP. But then they'd be done in like a day, which is great if you're a business owner (and the reason Pieter Levels uses PHP, for example), but not so great if you need to get paid to keep churning the code indefinitely (i.e. most people's situation)... and ideally hire all your friends to help too ;)
There are indeed less user-centric metrics with surprising weight when it comes down to it. I've also noticed that "We read a FAANG blog post and got enchanted" is easily remembered as "Everything was bad and we had to change it all" ;).
I don't find litigating this to be useful or interesting. Debating what is needed could show us lots of things we could cut. But would that bring real gain?
SPA's have really nice performance characteristics. Code is all loaded. The page can transition between states rather than total redraw. A good SPA should offer the same capabilities too, ought have URL routing and good history support.
I do think the web would be faster and simpler without SPAs. But it wouldn't be anywhere near as capable, as interesting, and as loved.
> I don't find litigating this to be useful or interesting.
I think it is useful because our field is woefully inept at anything resembling backtracking, and it's having concrete detrimental effects all over the field by, for example, increasing mountains of bloat eating up hardware improvements.
> SPA's have really nice performance characteristics. [..] A good SPA should offer the same capabilities too
The problem is that not even large teams without any obvious lack of resources are also unable to prevent sluggishness from creeping in to SPAs. So I guess there's a theoretical SPA and a de facto one.
> But it wouldn't be anywhere near as capable, as interesting, and as loved.
Capable sure, if you're creating Google Earth style apps. But when you start using vague and extremely subjective adjectives like "interesting" and "loved" it should be a signal that something's off here.
What you say sounds like we ought have suffocated and starved the web. I feel like "vague" and "subjective" is actually just pretty fucking obvious, didn't need a ton of support for it: the web is the go-to platform for app development because its featureful and works everywhere and is connected by default and nothing else comes close.
The web is where it is (literally everywhere) because it is capable and powerful, and it's because we didn't listen to retrogressive gate keepers insisting the web shouldnt really be for those uses cases.
The alternative to this is nothing. Is to not have had connected software. But we aspired to make great systems. That made some people very mad.
Nothing of that requires SPA, and the alternative is certainly not “nothing”. Not sure how you even get to that conclusion, strange rant. The meaning of alternative cost is not standing still.
> Nothing of that requires SPA, and the alternative is certainly not “nothing”.
Yes actually dev teams did have a massive leap in capability with dynamic HTML & updating the page.
> Not sure how you even get to that conclusion, strange rant.
Not sure how you even can miss that shift, strange miss.
(So, uh, do you always have to be such a deorgatory shit that I have to turn your crap faced mean shit back around? Can you talk like not a flaming shit bag? I don't super love turning your shitty mean crap ass personally aggressive negative worded words back at you, but you just have no vision & are ongoingly a mean shit about everything & so personally shitty about how you phrase things? And you are in such obvious denial. In ways that make zero sense. I don't think anyone sees how the web would grow while meeting your ridiculous constraints and that just seems obvious. Whatever third way you are trying to advocate for is clear as mud. And you cover for saying nothing with aggression! But mostly just stop being such an aggressive ass & engage like you can get over yourself, pull your head out of your ass, stop being a belittling shit, and make a God damned case, rather than throwing endless more empty bile.)
Personally, I like to look at the source for a page. And that, for anything React, winds up being useless (<go-suck-an-egg-because-EVERYTHYING-is-loaded-dynamically/>). I find React very hard to debug whenever anything doesn't work as expected.
I work on a React based web app in my Day Job and have genuinely enjoyed it.
That said, it always feels like so much boilerplate to get up and running for a greenfield project (and things like NextJS or even TanStack Start add a lot of things that might be overkill for a simple web app).
For some vibe coded side projects with Claude, I’ve been working with just using handlebars templates with Express and it has been pretty glorious!
I don’t think I’d recommend building a complex web app this way, but for some mild JS interactivity, form submission, etc, handlebars works.
Bonus: I find it much easier to get 100 across the board on Lighthouse scores this way.
For what it’s worth, I’ve used Vue and don’t like it (stuff like custom directives that are nonstandard html, not as explicit about event handling and data flow, etc).
I’ve seen a lot of buzz (particularly on HN) about Svelte but have lacked the motivation to try it.
I wish more people would criticise Svelte but most people just don't care because it's irrelevant. It's like complaining about Backbone or something, not worth the effort.
I wanted to like Vue but when I tried it I didn't. For writing ordinary business applications I wish React reified lists more than it does, but what I like about React is that I know how to draw absolutely anything with it, including 3-d worlds, see
I've tried both and disliked both. Already before I did I was wary of patronizing-feeling statements like these, though. The Vue community in particular, or at least the vocal pockets of it I've come across online, seem like a web dev counterpart to the Rust evangelism strike force.
> it always feels like so much boilerplate to get up and running for a greenfield project
This is why I love Bun + React. The setup is so easy I can do it off memory. I always hated boilerplate, templates etc. so this is a huge selling point for me.
Hard feelings here. I like react and have to work with it, still it is all insanely wrong.
The best approach I've found so far is egui , and I hope people are moving that direction. Draw whole frame, collect events, process, update internal state.
My initial objections were: (a) circa 2006 I was making very demanding RIAs such as knowledge graph editors and GIS decision support software and I've yet to see any modern framework that is as good as what I was using then (not in JS but rather GWT and Silverlight w/ the same async comms) and (b) the React model is not a 100% match for the form-based applications that we usually write with it (but boy do I love react-hook-form)
React is like the code in Graham's On Lisp [1] in that functional programming is used to create a sort of DSL. There are a lot of ways to implement reactivity that usually require a special interpreter (spreadsheets) or compiler (Svelte). React's system does show seams (you really need to be on top of identity and equality) but it is remarkably simple.
React shines, in my mind, for things that aren't form applications. For instance, VR applications with AFrame -- it's somewhere between VRML and Unity. I am working on a (mainly) heart rate variability biofeedback application [2] and it is so easy to make dashboards that display real-time metrics as well as Poincare sections and time series. That is, I can slap together a few data processing functions and widgets and make a new dashboard with new metrics and charts or new sensors. One goal is to get it working on a tablet in a two player version.
The disadvantage of React is that it does not work so well for highly dynamic layouts. In my case I have a library of functions to "fetch" the data stream and put them into the top of the component (may even package as hooks) and then put the layout together with JSX. I'd like to have a version where the user can drag and drop the components to make a custom layout and the system figures out the dependencies for the data fetching, preparation and processing like the things I made in 2006 and that kind of application with a dynamic layout (think programs like Photoshop with lots of different little widgets and property sheets) wants a different approach to reactivity.
[1] use of macros in that book is a red herring, the one example in it where you really need macros is when he is implementing cooperative multitasking, a feature that Python and Javascript already have -- most examples from that book as with Norvig's Lisp book can be coded up just fine with
[2] see https://github.com/paulhoule/VulpusVision it might "just work" if you npm install, npm run dev, and look at it in Chrome and connect with a Polar H10 or other BT monitor
I don't think this is specifically a react problem. The problem is that people don't want to learn what modern CSS can do, or write it themselves (see Tailwind), and most new frameworks make it easy to just sidestep that with div soup.
Some of us _like_ CSS, and try to use as much of it when possible, but I feel like we are few and far between. I use react to manage the state of my app, but that doesn't mean I have to make a 27 div component to style an input.
The big problem is trying to convince the rest of the team that they should learn and use CSS.
I agree it's not just React - I think a lot of people simply do not know what CSS can do nowadays.
I do like Tailwind (I guess it fits with how I think). But to make good use of it you _do_ need to know how CSS works (for example, using variant selectors for picking out child elements, using container queries instead of global breakpoints etc).
I really don't understand Tailwind. I heard great things about it, and then I tried it and it seemed like setting style="" on all elements, but with extra steps.
Did we go off semantic CSS and returned to setting properties on each element, or was I using it wrong?
Plain CSS is very useful if all you have is an HTML page. Giving all buttons a consistent look is nice and easy if you can just specify that with a nice CSS selector. That's also the only place you can do it without changing all <button> tags.
If you're building a component-based UI, that need is less, because all your buttons are created in a specific Button component. That's also an easy place to attach styling. You don't even need a separate file anymore.
But that's a wash. It gets much more interesting if you have components that are used in different contexts. Unordered lists for example can be an unordered list in the running text, but also a navigation list in the footer, the menu, or as tabs. There's some semantic logic to having those things as lists, but they usually look completely different.
You'd use classes and descendent selectors to deal with those differences. The downside is that those leak very easily to instances that you don't want them in. Having normal lists inside tabs inside running text requires careful engineering of the selectors.
The larger and older your project grows, the harder it becomes to get that exactly right in a future-proof way. At some point changing something for one item somewhere, can completely mess up something on another part of your site.
Inline styling, or Tailwind-style utility classes, are useful in that situation. Every component gets to be responsible for the way it looks and no longer has to care what anything else does. HTML tags that are used in different contexts will have their context right there, next to the styling. All part of the component.
The few remaining things that you need for consistency between components (colors, sizes, fonts, etc.) can be handled with CSS variables.
Why not scope your styles in the component, using either a css in js approach, like Vue, Svelte, and surface do, or use the modern css @scope property?
You aren't using it wrong, the only thing tailwind does better than 99% of devs is having default values that both look nice and mesh together well.
Utility based CSS has been around as long as classes have, tailwind is just one iteration of that. GitHub use to have a utility css library as well before switching to their new design.
Yes? I don't think anyone has ever argued that tailwindcss has a moat on anything, it has always been championed as a library created by a designer + dev who care about good UI design.
At least that's how I always seen it billed as, even when Adam was live streaming and saying as much in like 2018/2016.
> and it seemed like setting style="" on all elements, but with extra steps.
And extra benefits.
Generally more concise on the common usecase, but more importantly you can combine and use media queries, which can't be done with inline styles alone.
CSS is a little too low level for most web app design, Tailwind is a bit higher level and more concise than its CSS equivalent. It also has a bunch of sensible defaults for colors, sizes, spacing, and type.
Encapsulation, e.g. utility classes (and Tailwind, by extension) solve for project management or organization level problems, not styling problems directly. The nice defaults are a bonus but the actual value is a common and agreed upon approach to avoiding a write-only stylesheet that grows forever and for not fucking up cascading styles that impact someone else's feature or page you didn't intend to and causing releases to grind to a halt while they sort out what you did. Everyone here who misses that point is basically broadcasting how they are the cause of long term problems in their project or at their organization.
You make a good point. From a philosophical point of view, abstractions should hide complexity and make things easier for the human user. It should be like a pyramid: the bottom layer should be the most complex, and each subsequent layer should be simpler. The problem is that many of today's abstractions are built on past technology, which was often much better designed and simpler due to the constraints of that time. Due to the divergent complexity of today's abstractions and unavoidable leaks, we have a plethora of "modern" frameworks and tools that are difficult to use and create mental strain for developers. In short, I always avoid using such frameworks and prefer the old, boring basics wherever possible.
I'm struggling to form a definitive statement about my thoughts here, but I'll give it a try:
Every (useful) abstraction that aims to make an action easier will have to be more complex inside than doing the action itself.
Would love for someone to challenge this or find better words. But honestly, if that's not the case, you end up with something like leftPad. Libraries also almost always cover more than one use case, which also leads to them being more complex than a simple tailored solution.
I think of it as: adding an abstraction relocates complexity away from what you want to make easy and moves it somewhere else. It does not eliminate complexity in total, it increases it. The best abstractions have a soft edge between using them and not using them. The worst are like black holes.
For what it’s worth, the point of React is that you can just fix that Radio component to be an input (if that makes sense) and it’ll just be an input.
React gives you boxes to put stuff into but you decide what to put into them. Then React ensures that you can change what’s in those boxes without breaking anything. That’s the power of component abstraction.
The point I wanted to emphasize is that even if you do overcomplicate your DOM, the component abstraction is what allows you to fix it in one place. Don't like what's in your component — add `return <input />`, bam! It's fixed across the entire app now.
And how is the surrounding JS code, like the event handlers, and the CSS of the component supposed to still work now? A radio input will need at the very least additional CSS to remove the native appearance. Unlikely that was set already --> it's not that easy.
The idea is that the component's API is not the DOM. Usually this means your data should flow in a certain way: top-down.
Application code is not supposed to use the DOM as the source of truth for some boolean state that the checkbox is an input for.
You don't usually read a component's state from outside (here: the "checked" property).
Instead you define an API where data only flows top-down.
When your checkbox component follows this paradigm, it is "controlled", and if it contains a standard HTML input, that input's "checked" DOM object property is bound to the data passed into the component ("props"). Clicking it won't check it anymore until you add an "onClick" callback and pass a function into this callback that will make the "checked" prop change.
The checkbox is now "controlled" and it's state was "lifted up" (meaning that it is determined not by the checkbox component itself).
"controlled" means you tell React to always force the "checked" DOM property to be the same as the "checked" prop you pass into the component. You do this by assigning to the reflected "checked" HTML attribute in JSX.
When your components only use this "top-down" data flow, they're "pure" in React lingo. Because they look like pure functions: props => DOM fragment. The machinery behind the scenes means they're not actually that (something has to coordinate the rendering).
But if you don't use internal state (e.g. useState hook) or global stores, these "impure" parts are React internals only, and you can have a mental model that views the component like a pure function.
This makes it easier to connect it with other components in a tree.
For example:
HTMLInputElement.checked can be true without a "checked" attribute being in the markup.
If you want to have some text next to it that says "checked / not checked" you have to wire stuff, and this stuff depends on your markup.
If you have a "controlled" checkbox, you have a tree, not only for the markup, but also for the data: the boolean "checked" state can now be declared one level above both the info text and the checkbox. Then the info text doesn't care at all about events anymore.
And the checkbox component only uses a callback that is also independent from the exact markup structure (e.g. a selector for the HTML input element).
You don't need to read from the checkbox to update the text. You feed both with a boolean and both can be "pure" components. The checkbox gets a "onClick" callback and it's checked state is no longer internal, it's "controlled".
The wiring you have to do instead of the regular DOM events (which would read the input's state) is now to use your "onClick" callback to toggle your boolean.
Internally, in the component, you do whatever you need to read and write to the DOM. But usually that just means "what markup do I return".
Input elements and reflected attributes such as "checked" are already a relatively complex case.
And, you can escape the recommended top-down data flow by many means (refs, context, accessing centralized "stores" from within the component...), but that's often where it gets ugly. But you need to do it often when your app gets bigger (centralized data stores), or when you implement things like UI libraries (refs).
I guess it depends on your definition of complexity. Being able to think about your UI as a function of state is a lot simpler than dealing with mutability, coordinating imperative updates all over the place, etc. React’s core idea is simpler than the paradigms it replaced. By simple, I mean as in “Simple Made Easy”[0].
React is not simple (preact is) and what's worse, it gets more and more overengineered in order to solve the problems they have themselves created (accidental complexity in your video).
Sadly, accidental complexity is a common theme among react devs, not just ui libs, but also react-router, redux, redux-form, even tanstack useQuery() is way over-engineered and the core idea can be implemented in <50 lines and then you own the code and can make project-specific changes.
Maybe that's the biggest issue after all, people being lazy, expecting to do npm install and being able to reuse everything in any situation. Except that it almost never work like that and a lot of damage is done in the name of it... </rant>
Well, to be fair, Preact is what I use. I use the name Preact annd React interchangeably when discussing tech, but I agree Preact is the simpler and preferable of the two. But, in the context of this thread, both provide a nearly identical way to model UI.
> React is much more complex than the technology it's building on. Necessarily, to enable it's features
React, just like most software today, is excessively complex for the tasks it performs.
The only reason React is used is that many use it as a framework to attempt to provide more interactivity on the page without page reloads. There are other frameworks to do this, but none are as well-used.
Webpage interactivity with data was accomplished with page reloads via cgi-bin in the 1990s. Everything that has been done since then was not strictly necessary to produce the websites we use today; it would just be a more choppy experience.
A smoother experience didn’t require the overwhelming complexity that was introduced primarily in the 2010s in a framework war that React basically won. That complexity is the reason why many web and full-stack developers in the 2010s (such as myself) lost their minds and quit or seem incredibly depressed, grumpy, and confused much of the time today, and why some have invented strange new frameworks to attempt to reduce this complexity.
Managing state and syncing it to the DOM manually is much harder than React (or any other big framework) for any non-trivial web app. Reactive, inherently asynchronous, event driven applications get complex easily.
Right. I encourage young devs to build a complex app using vanilla js. Feel the pain of two way state management. Then you’ll gain an appreciation for react. And you’ll learn browser APIs and know when react is overkill because it has its own pain
> But for several years we've been able to style radio buttons however we want using a few CSS tools
proves how good the current state is, where a dev can think things will just be ok, for everyone, if you just ripped all that complexity and ship it (which should be the attitude for a good framework).
i’ve tried this, and it almost almost works to just rebuild the Dom on every state change as a pure function of state without any react or anything. The resulting interface is actually way snappier than react – but preserving local state of elements like what text is highlighted, where the cursor is, which radio button is tabbed to etc turns into a nightmare.
With all due respect, I don't believe it is "more snappier than react".
React itself with nothing else is plenty fast. You would have to go way out of your way to see performance differences between different UI approaches, computers are just way too fast to notice whether this click resulting in the div's text changing to +1 is slow or fast, even if the implementation were crazy convoluted.
What makes react apps slow is using it badly, and having 10 other libraries getting in the picture loading fat UI elements, etc.
And frankly these would be much slower in your render everything anew approach.
This is where "react is a library, not a framework" kinda lets it have its cake and eat it too. preact is 4 kb, React + react dom is like 30 kb, but when I use it under commercial pressure to deliver it seems to climb into the megabytes. I'm working on a react native app right now that is a completely embarrassing 150 Mb. The experiment in no react, build UI from scratch every state change has stayed around 65 kb without much attention paid to bundle size, with 10 kB of that being a bunch of linear algebra and differential equation solving code and 50 kb of that a plotting library that's completely nonblocking for the rest of the app.
Based on your description it sounds like you were halfway into reimplementing the virtual dom that react uses (or use to use? unsure if they moved away from that with the implementation of a compiler).
It's not even the young devs. It looks like most of those complaining are back end developers who "rarely tinker with frontend" but think they can teach everyone else how to make it simple because "it should be static forms".
A great example of all-world-is-a-nail stance mixed with extreme hubris.
I did spend a serious amount of commercial time developing fronted UIs in React, Angular, and the before times in vanilla JS/css. I even wrote my own UI framework in Web Components, developed my own CSS framework used by an agency churning out projects for years. You get the idea, I did the thing, commercially, for over a decade. React and Angular are absolutely more complex in practice. That's fine, if you want the features go ham. But you don't need them, and most people mis-use the power and end up with a slow complex mess.
Perhaps those same people would have a slow complex mess in vanilla tools too though, so maybe React is a scapegoat like PHP was, and Javascript was.
It was fine when it started, it's the addition of useEffect and hooks that messed everything up. Although normaly I prefer functional, for react classes were 100 times better
I know people love to make UIs stateless and functional. But they just aren’t. IMO UIs are fundamentally a bunch of state, graphically represented. So naturally all of the functional frameworks are full of escape hatches.
I’d rather have a honest framework than a chimera.
I have not followed SwiftUI recently but when it was introduced I quite liked to have the main composition in SwiftUI and then writing more complex components in pure UIKit. Both could be used what they are best suited for. But trying to shoehorn good interactivity into a SwiftUI component always ended in horrible code.
What about Elm? I think most people could grasp the elm architecture in an afternoon. To me this MVU style is pretty much perfect for UI.
I think a lot of the time React appears complex and hacky is because we tried to solve world hunger with one component. I've worked on plenty of React projects that were very easy to scale, modify and iterate because they focused so heavily on small independent stateless components.
Elm is awesome until you try to use it in an actual app. The amount of pain we went through trying to make a basic web app with a sidebar and a few pages... I don't remember the specifics, it was a few years ago, but I don't think Elm has changed much since then (it was 0.18).
> I know people love to make UIs stateless and functional. But they just aren’t. IMO UIs are fundamentally a bunch of state, graphically represented. So naturally all of the functional frameworks are full of escape hatches.
Functional does not mean no state, just constraining state to inputs and outputs. Breaking that is a choice, and not good design.
Elm, for example, provides all of that with one escape hatch: ports. It is really well-defined and that not fall into any of the impossibilities you mention.
I also have the same somewhat controversial opinion, the frontend community wasn't ready and (still isn't) to organise a functional codebase.
The second problem is that React has a "draw the rest of the owl" mindset. Sure you have nice frontend components but now what about caching? data transfers? static rendering? bundle size & spliting? routing?
The reason for React’s “draw the rest of the owl” (which is a great way to describe it) mindset is that it’s born not as a framework but as a library, and to this day self-identifies as such. It by design tells you nothing about and is agnostic with respect to how you organise your code, where to put tests, what bundler to use, etc.
IIRC React itself doesn’t even know anything about the Web or DOM, as that integration is supplied by the pluggable reconciler, which lives in a separate library (ReactDOM).
One could argue that with the amount of batteries included perhaps it ought to undergo a grand status change, but until then it’s hard to blame on the authors of a library that they are not delivering a framework.
Did it not work? Many successful and complex sites and apps use React—whether directly or via a framework (Next, Astro, or something homegrown)—and indeed many frameworks are built on React.
> math tools or pdf generation
In this case the original scope of the library was “reactive rendering”, which sort of makes sense.
It worked as in react is the de facto frontend choice.
It didn't work as in if I were to ask for the router, state management, etc library, there would be a combinatorial explosion of react "frameworks", all sucking in different ways.
I am (and supposedly grandparent also) on the option that react leaves out way too much that would still be well in the scope of a 'UI framework', and while modularity can be a good thing in certain things, more modular, more moving parts does increase complexity.
I've been there since the early days of React and I haven't seen a single React codebase which isn't a pile of duck-taped random packages, often leading to poor user performance.
Maybe it can be done, maybe not, but the average front-end dev doesn't have the insights to fill the gaps that React has left.
Some codebases are better than others, more mature open-source projects tend to be more polished, closed enterprisey things can be nightmare fuel, but that’s all probably universal to a degree and not specific to whether you’re using React or not. (OK, dependency mess is at least somewhat specific to JS.)
My real development experience started with Django—arguably one of the best-documented proper frameworks out there even before it reached 1.x—and let me tell you: the kind of garbage I have seen once I started doing it professionally still makes me shudder[0].
I agree with you in the sense that the choice to forgo a framework and use only a bunch of libraries directly should be very carefully considered. Frameworks exist for a reason. The decision should be made with the full understanding that one would implicitly undertake a task to create a framework (even if it is a narrowly specialised one just for that project). A lot of what you do if you go with raw React will not actually be front-end development: prepare to be vetting dependencies for (or implementing yourself) very basic functionality, fighting bundlers, trying to get TS to use correct global typings for the context, managing version hell to get all of the above to interoperate, etc.
(By the way, any mistake you make will be on you. Picked a test runner that was discontinued? Some transitive dependency got hijacked? There is no one else to blame. There’s no BDFL and expert core dev team vetting things, knowing when and how to write from scratch if there’s no trustworthy third-party implementation, orchestrating working version combinations, or writing migration guides.)
[0] Indeed it would be hubris to claim I myself have never ever architected something I would later call a monster held together with bits of duct tape.
Yeah, as a solo dev quite new to frontend, that made me nope out of React almost immediately. Having to choose a bunch of critically important third-party dependencies right out of the gate? With how much of a mess frontend deps seem to be in general? No thanks.
I settled on Svelte with SvelteKit. Other than stumbling block that was the Svelte 4 -> 5 transition, it's been smooth sailing. Like I said, I'm new here in the frontend world and don't have much to judge by. But it's been such a relief to have most things simply included out of the box.
Even when it's the same router package, these things break backward compatibility so often that different versions of the same package will behave differently
That router thing seems crazy. I'm all for having options that are available. But not having, at the minimum, some blessed implementations for basic stuff like routers seems nuts. There is so much ecosystem power in having high-quality, blessed implementations of things. I'm coming from working primarily in Go, where you can use the stdlib for >80% of everything you do (ymmv), so I feel this difference very keenly.
> There is so much ecosystem power in having high-quality, blessed implementations of things.
Indeed. I work mainly in Angular because while it's widely regarded as terrible and slow to adapt, it's predictable in this regard.
Also now with typed forms, signals and standalone components it's not half bad. I prefer Svelte, but when I need Boring Technology™, I have Angular.
90%+ of all web apps are just lists of stuff with some search/filtering anyway, where you can look up the details of a list entry and of course CRUD it via a form. No reason to overthink it.
I know you are saying you do work mainly in Angular, but for others reading this, I don't think this is giving modern Angular the credit it deserves. Maybe that was the case in the late 20-teens, but the Angular team has been killing it lately, IMO. There is a negative perception due to the echo chamber that is social media but meanwhile, Angular "just works" for enterprise and startups who want to scale alike.
I think people who are burned on on decision fatigue with things like React should give Angular another try, might be pleasantly surprised how capable it is out of the box, and no longer as painful to press against the edges.
Strong disagree. Angular is cursed to the bone. It got a bit better recently but its still just making almost everything totally overcomplicated and bloated.
I'd say what you call bloated is in many cases basic functionality that I don't have to go looking for some third party package to fill. There is something to be said for having a straightforward and built-in way to do things, which leads to consistency between Angular projects and makes them easier to understand and onboard to.
IMO, it is only as complicated or simple as you want to make it these days, and claiming otherwise likely is due to focusing on legacy aspects rather than the current state of the framework.
FWIW, I'm not arguing that it's the "best" or that everyone should use it. Or that it doesn't still have flaws. Just that it is still firmly in the top set of 3-5 frameworks that are viable for making complex web apps and it shouldn't be dismissed out of hand.
Hooks were fine, but their implementation in React was barkingly insane. Vue's notion of "composables" is very similar, but not dependent on order, so you can use them in conditional statements without breaking the world. I don't even want to think about doing a complex Vue app without the VueUse library.
Is this the same with everything? In the past, a hard drive, a mouse, or a web camera was a dumb piece of hardware and a driver that ran on your PC. Now, IIUC, each of those has it's own computer (SoC) running an entire OS. Your phone probably has ~20+ SoC. One for USB, one for Wifi, One for Bluetooth, one for each of the 4 cameras, one for lidar, one for SSD, one for cellular, one for the secure enclave, one for audio, Each of them is an entire computer, more powerful than most 1980s general purpose computers, running an entire OS with multiple abstractions internally and all of that to make that device appear as yet another abstraction.
There is a difference between implementations getting more complicated vs. interfaces. It doesn’t matter if the mouse has a SoC if it still only exposes the same old USB HID protocol. The issue discussed in this thread is that the developer using the thing isn’t shielded from the increased implementation complexity and can’t just work with the abstraction.
React was built to satisfy the specific scaling and complexity needs of Facebook, and this CV-driven industry jumped on board with it pretending that what's good for Facebook is good for them. The incentives are completely misaligned: it's like nobody gains anything out of using the least amount of force and abstraction to solve a specific problem.
I did frontend before React, and it was a welcomed change. The core insight of UI being a function of state is a good one. It saves you a bunch of headaches from the jQuery days where you’d have multiple code paths per UI element (adding, removing, mutating). That said I think they lost the plot with hooks and things have gotten needlessly complex since then.
Worse still is the misunderstanding that React is simple. It’s an endless stream of cache invalidation bugs. Linters are getting better at catching these. But they also have false positives.
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.
The problem is app-document impedence mismatch. CSS makes stuff easier but for doc-like pages. In addition doc-like pages want some app-like niceness too.
If you need to be an app you usually need a framework to stay sane (evidence: most other native UI kits are frameworks of some sort) and thus React etc. But they want full contol. Thus 2 ways to do a radio etc.
This radio selection is brilliant silly, especially because the end result is indecipherable from a vanilla css rqdio button.
For some reason people keep going back to complex UI and interactivity frameworks though, does anyone have a good example of a large website built without all this bloat?
Asking because I've seen hundreds of small sites built with elegance and simplicity, and few large ones. Is it just inevitable that as a team size grows, someone introduces insanity? Do these tools solve an actual problem that I'm missing?
Not the prettiest but absolutely amazing to use! I'm sure web devs are laughing at me right now, but I genuinely didn't realise websites with that many images etc could actually be that fast.
We went out of business, but I made a web app for videographers to collaborate during production. Same things as frame.io. This was over 15 years ago. Frontend was pretty vanilla except relied heavily on jQuery. The main section of the app allowed you to commend on specific frames in a video. The code is split up amongst multiple files. Here is one: https://github.com/StevePotter/Takeoff/blob/main/Takeoff.Web...
Look at any of the sibling `app-productions-details*.js` files. Combined they formed a single interface. It was dicey. But damn the interface was snappy. I mean, instant. Code would have been much less these days but probably nowhere near as responsive.
As company size grows, managers want to settle on a "standardized" tech stack that doesn't get in the way when they want to hire and fire people at will.
Nobody was ever fired for choosing React (or IBM). But everyone can get fired when they're working on a React app.
One major reason for this, in my past experience, is that designers push for heavily customised components. If you go back to them with “why not use the default radio button with a bit of styling?”, I’ve yet to work with a designer that would relent, the specs are always for crazy UI work.
Its because everyone can see UI, and many have strong opinions on it. Its always the first tragedy of the commons. In a typical tech company built on compromise, fighting the complexity is a fools errand.
Cant speak for shady lib specifically but yes as you grow you do find that default styling doesnt work or you want something which doesn’t exist.
The crux tho is that this usually happens in what id call web apps and not websitess. Web apps are far more complex and powerful. It is a spectrum tho and sometimes websites grow into web apps which is why people oft over engineer early on.
Developers remember, you can always push back on design requirements instead of bringing in more bloat.
I was sitting next to one of the devs in a co-working space and he was trying to figure out some specific layout issue in react native. He spent 4 hours + installed a dependency to be able to do something completely tiny on a privacy policy screen. He asked me how I would do it, I told him to just ask if it can be laid out differently. He got it approved and implemented in 10 minutes. No bloat.
I'm finding it's better to use "javascript-less" UI frameworks [Pico.CSS, Skeleton, Bulma, Tailwind/daisyUI]. You get most of the benefits using good use of CSS. Anyone used these JS-free solutions and have recommendations?
My current choice is DaisyUI. It’s pretty good and because it’s based on tailwind you get the rest of the ecosystem benefits. Super easy to extend and change. Class bloat is much more manageable than raw tailwind.
This is the kind of stuff we have to do because almost all browser <input> elements are terrible in terms of customisability. Especially radios and selects
If you're one of those who think we should just use the default, bear in mind that the default radio button has poor usability for mobile users.
There are lots of ways to style these native controls, though, including ways to start from scratch and retain the accessibility affordances.
I'd be curious to know more about the usability issues you've found on mobile -- I've not had any personally when using radio buttons. I'll readily grant you that 'select' is awful everywhere though!
It’s a lot easier now than it used to be. Radio buttons used to be nearly impossible to style, and I still think they require scripting to de-select— so none in a group are selected after one has been selected. I’ll bet most of the complexity in the article is some combination of keeping support for older browsers, technical debt, and nobody complaining about it because it works.
The only <input> that is annoying to style is the “select” one because it’s hard to style the “options”. The rest seem reasonable and quite customizable in my experience.
I admit I haven’t had to use the date picker in a long time but I looked at the MDN for an example of the default implementation of it and it seemed fine on my iPhone. What issues have you encountered with it? I imagine it’s a different story on desktop browsers.
It’s been good on mobile for a while, and it’s a travesty on desktop.
Then if you want something a little bit complicated you have to do it all yourself.
- What if I need a date range instead of a single date?
- What if I have excluded dates? (Only weekdays/only in the future/blackout dates)
- What if I want to show other metadata with each day? (Like in a calendar showing each day with some metadata next to it)
Beyond “give a whatever the system thinks is a good date picker that I have no control over” the input with type date isn’t very useful.
Out of interest what's an example of styling that the radix/shadcn version enables that their approach doesn't? I was able to (AFAICT) replicate the radix docs example by just moving their styles around: https://codepen.io/mcintyre94/pen/pvbPVrP
In the example they are just using an empty <RadioGroup.Indicator/> for the pip as it is easy to target with a classname, but you can put any content in there instead for e.g. card-style radios (as used for complex selections, like a subscription tier).
By using radix, the underlying behaviour is compliant and identical for each of those implementations - you just change the content. Radix isn't looking at it like an html radio element, it is looking at it as a completely unstyled unique item selector.
The pseudo-element styling approach limits you to 3 layers - the container, and the 2 pseudo elements, none of which you can provide with meaningful content besides plain text. The best you can do is provide a basic styles and set background image. For anything else you need to use labels to either wrap the radio (in which case you can access state via sibling selectors) and/or ref them with "for" (in which case you cant access the state).
The biggest mistake I did in 2025 was picking shadcn because it was so hyped. Saw it importing from radix anytime you enter a command. First red flag.
Then I saw the radio component. Second red flag. You should see what they've done with the select component. But we were too far into the deadline for a project with running targets. So I just gave up and asked copilot to make the changes for me, and I'm not a fan of AI anything.
Funny enough we did a POC for the same project before that without shadcn and looking back, it's so much leaner and easier.
I might just break one night and redo the whole ui library with vanilla html elements.
They hype-train on all of this stuff is unreal. React+NextJS+Tailwind+ShadCN is just a mess. It's complexity piled on deeper complexity - for little gain! But suggest any of that in many circles and you'll get the standard, "skill issu bro" comebacks. Say what you want about Remix/ReactRouter 7 (there are plenty of issues to talk about there) but at least those guys _tried_ to stay closer to existing web standards. I could go on and on about the disaster of NextJS caching. I could point out RSCs being one way to solve a problem that could already be solved by loaders in other frameworks....
Tailwind was my moment of saying, "Nope, I'm gonna sit this one out". I have a few trusted friends that assure me I'm missing out. I've told them to come back to me after they've done their first major refactor. If they tell me it was a pleasant experience, I'll have another look.
In general, Tailwind and React don't match well. Why use a soup of CSS classes when React has props? If someone needs an a11y-focused base for their component library, they can start with Radix UI directly, ignoring Tailwind and Shadcn.
I have absolutely no doubt that somehow all these projects and similar ones - started with good intentions - good looking UI, implement and forget. And then, one fine day you're sitting on top of 200+ lines of code for a radio button and 7 imports and it's too hard to go back now without tearing the whole codebase apart. This is how code rot starts.
Where do you draw the line tho? How many kilobytes and how much future maintenance work is avoiding a potential slight visual inconsistency with a radio button worth? Is it worth to lose the x amount of people who have bad network connection?
Use this approach everywhere and the actual content of the page (you know: the stuff people came for) suffers.
All I can think about is a quote by world famous video artist Nam June Paik: When to perfect, Gott böse ("God gets mad when too perfect", the original isn't exactly a full sentence and mixes English and German).
Based on profits of many webapps, there is no line. What eng here forget is that they are oft not the targeted consumer. The hypothetically perfect website doesnt sell as well as a colorful fat choncker does. It is like fast food, not every cares about farm to table.
> 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.
Everyone always says slower and bloat and bad etc etc but it is all relative. Not everyone is an eng who scoffs at waiting another 100ms.
I do like your analogy tho. It is better. Most people want that trendy experience or fast food. Still, both exist because the market demands it be so despite how much it tilts a subset.
I worked in first level IT support and I think most people don't even consider it consciously like that. They read the news at that page. That page changes. A lot has to happen to piss them off enough to make them go. They habitually click away fifty windows a day without reading them anyways.
But people do notice if something just works on a subconscious level and that colors their perception of your project/brand/page or whatever. Even my totally tech-illiterate father actively complains about junk interfaces like the one at Temu. But he goes there for the sweet deals. I just wonder if it wouldn't work out better for them if the page was snappy and allowed a person to visit more product pages.
And one mistake you make is to think you need a megabyte of javascript to create a junk look. You can easily do that with HTML and CSS alone, including animations and all.
The way I see it the causal arrow points in the other way: successful sites tend to get bloaty, but they do no et successful because of it, but despite it.
And by bloaty I don't mean it as a problem if the page does a lot. Bloaty means you use a intricate Rube-Goldberg-machine to in the end do very basic things. Like displaying a popup, which can be done with a single line of Javascript, but is for some reason done using the amount of code that would result in a veritable, heavyweight book if printed.
This is objectively not true, if it were the path of least resistance would mean everyone uses the option that is fastest and best.
It takes far less effort to implement the bad way. I think people take their own skill for granted. Maybe you can but most others cannot. Maybe they will learn or maybe they are happy to put food on the table and go home at 5.
When I say "implement" I mean the big pile of code in the library. I do not believe making that entire custom mechanism was easier. There's so much to it.
Everyone else following along and merely using it I blame less, but they shouldn't have picked such a bloated library.
Everything in styles.css in that example maps to the vanilla input, so you just have to move them around a bit. Should work at least as well as theirs across browsers, because it's vanilla inputs and the same CSS.
Under all of the framework complexity that specific look is still achieved with CSS. In fact, you could rip out the CSS they use with very little modification and pair it with a ~five-line React component that doesn't require any third-party imports.
> - Make sure it looks the exact same across all browsers
> How doable is it with vanilla css?
It's not doable with your fancy frontend framework and your 20 imports and your ten thousand lines of typescript.
"Make sure it looks the exact same across all browsers" is, and always has been, fundamentally at odds with how the web is intended to work.
How well does this shadcn crap render in arachne? ladybird? netsurf? links? dillo? netscape 3? The latest version of chrome with user styles applied?
When you say "exactly the same", I assume you mean that the design only uses black and white, because some people might have black and white monitors, right? But you're also going to use amber-on-black because some people might have amber screen monitors, right? How do you plan on ensuring it looks exactly the same on a braille terminal?
Maybe you think I'm being silly. Because nobody uses monochrome monitors in 2026, right? So it's safe to ignore that and put an asterisk next to "exactly the same" (And also just forget that e-ink is a thing that exists).
(Just like how it was safe in 2006 to assume people would always have 800x600 or bigger displays, and nobody would ever come along using a screen with, say, 480×320 resolution)
What measures have you taken to ensure that your colours appear exactly the same across a bunch of different types/brands of monitors that render colours differently? Or, perhaps we should just add another asterisk next to "exactly the same"?
I could go on.
How many asterisks is acceptable before "exactly the same" isn't a thing anymore?
If "exactly the same on all browsers" is one of your goals, you are wrong. If your designer tells you that's what they want, they are wrong. If you ever tell a client that's what you're providing, you are wrong.
I think accessibility is one area where some of these components libraries can be helpful as they automatically include a11y features that might otherwise be ignored.
Displaying the same thing on every monitor to the degree that monitor allows is well-defined. The browser may not be able to show some colors and the browser may decide to display things differently on purpose, but it's perfectly reasonable to want to unambiguously express what you _want_ the browser to display.
> Displaying the same thing on every monitor to the degree that monitor allows is well-defined.
In this case the website will not appear the same on every browser. Most browsers have a zoom function that the user controls which is an accessability feature. This changes how the website renders on the page.
The real cost of this complexity isn't the code itself - it's onboarding. Every new dev joining the project has to understand why a radio button needs 47 lines of JSX with Radix primitives, context providers, and styled variants.
I've watched teams spend weeks just getting comfortable with component library internals before they can be productive. Meanwhile the "simpler" vanilla approach might have taken an afternoon to build but takes 20 minutes to explain.
That said, if you're building something like Figma or Linear where you genuinely need the accessibility primitives and keyboard navigation that Radix provides, the complexity pays for itself. Most CRUD apps don't need it though.
Im not in web development. Reading this article makes me think: is it realy neccersary to use all those complex frameworks? Isn't html/css enough? People always say "every line not written can't be a bug" but moving those lines into a library was not the idea behind the words
No, obviously. If you are writing complex web applications with state, local processing of data and asynchronous interactions it's not enough. You need javascript. If your javascript is especially complex and you desire it to be declarative, you probably need a framework. Do you need, I don't know, Tomcat in Java? Probably yes for a complex application and no for a simple proof of concept. Do you need a database? Aren't files enough? And so on.
Shadcn is a framework for developers who develop highly interactive web apps. If all you need is a static form that submits data to a web service, you probably don't need a framework (except when you need it - for example, selects are not yet fully styleable in all browsers).
Next objection usually is: do you need complex apps on the client? Can't they be reduced to a series of simple forms controlled by the server? Sometimes they can and sometimes they can't, but of course I will decide the shape, behaviour, complexity and look of the applications I build (or have others build for me), thank you very much.
That said, radio buttons have been styleable in all non-legacy browsers for at least 5-6 years, there's no excuse for rewriting them from scratch with svgs.
>If you are writing complex web applications with state, local processing of data and asynchronous interactions it's not enough.
>Next objection usually is: do you need complex apps on the client?
It's not even an objection, it's a question I ask and almost never hear a coherent answer to. The vast majority of web applications I use every day (online banking, github, forums, social media, admin interfaces of various developer tools, etc.) don't really need to be dynamic and frontend-rich. I don't care if submitting a form refreshes the page. Funnily enough, full page refresh with a full round trip with "old school websites" is often faster than dynamic SPA interaction.
I don't care that when I click "delete", the item may not disappear from the screen immediately. I don't want to see some in-between state descriptions like "Deleting..." because I know it's a lie in a distributed, eventually consistent system. Just tell me the truth: the request has been sent. I can then refresh the page and see the new current state, whatever it is.
I really don't understand this desire to make websites behave like local apps while in reality they aren't.
> it's a question I ask and almost never hear a coherent answer to.
There are a lot of coherent answers though.
One is that responding with HTML encumbers the server with brittle UI over the wire when it could instead be a simpler API server that any client can talk to.
Returning data instead of UI from the server is a clean separation of concerns.
That's the theory. In practice, if your UI is changing a lot, the data your UI needs is also changing a lot, meaning that your data API will either have a lot of churn or you'll allow a lot of flexibility in how untrusted clients can use it, which introduces it's own pile of issues.
> I don't care that when I click "delete", the item may not disappear from the screen immediately.
The disconnect here between tech people and non-tech people is that most users do care about stuff like this.
I run a popular website as a solo project so all the feedback/complaints are routed to me, and one thing I've learned is that users really don't want websites to "feel old". Sure, they want it to be fast, but they also want all the bells and whistles like loading indicators and animations.
If you show Hacker News to someone who's not a developer, especially if they're under 30-35, their reaction to the layout and functionality will be visceral disgust. I really can't stress enough how much modern users hate the traditional plain HTML look. If you're trying to convince users to use your site and it looks or functions anything like HN, they'll get angry and close the tab within seconds to look for an alternative. Even if you've made a SPA with plenty of bells and whistles, users will still get upset if anything feels "clunky", which is often user-speak for "this component needs animations and a transition state". They don't know or care that all the fancy stuff increases the complexity of the codebase.
Every software project hits a point where the super clean abstractions the developers came up with start to clash with the messy way it's used in the real world. This is the frontend version of that. We have no choice but to give users the UX they want.
> I really don't understand this desire to make websites behave like local apps while in reality they aren't.
Since the dawn of time, humans have sought to eliminate mushy laggy UIs, such as having to wait for a full page reload whenever you click a button. I don't like SPAs either, but dunno, I don't find it particularly hard to understand how we got here.
Immediate feedback informs the visual language in order to convey meaning in a easier way to a larger public. You may know what an eventually consistent system is, but many users don't, and they want visual information abstracted to something they can understand. It's reassuring.
Also, not everything can be reduced to static forms. Charts with knobs, drag and drop interfaces, interactive diagrams are all useful visual aids that you would like to erase because... they don't conform with your naive views on how things should look like?
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.
No, you're right. Livewire, Phoenix LiveView and all the others are a couple levels removed from the browser and you have to suffer the whole indirection chain when something goes wrong. React is a good compromise - it still has indirection, but not so much, and it's much easier to use at scale than state managing and direct DOM manipulation.
A lot of frontend developers today (my experience) does't even know where to look for CSS updates or what vast amount of HTML element exists, they just know to look for frameworks and that's how they see the world.
Like <input> is foreign to them, they only know of <FrameworkTextComponent>.
Sometimes you do need a framework, but the question is being asked way too seldom.
If you're not into web development, Hacker News discussions about React are really bad way to gain unbiased perspective - it's been really popular here for last few years to just hate React (usually they know nothing, e.g. anyone who claims hooks compose worse than class components). But there's a reason why React is still used the most (large ecosystem, fast development and backwards compatibility). Of course, it's easy for inexperienced developer to produce slow and buggy apps (maybe slightly easier than in other frameworks, but that's practically unquantifiable), to include unnecessary or even badly written dependencies, etc. - but it's not the tool's fault when it's being used incorrectly.
This library doesn't appear to be accessible. Just looking at two random components: The Drawer (https://daisyui.com/components/drawer/) doesn't trap focus inside itself (letting you tab to the page behind the drawer while it's open). The Accordion (https://daisyui.com/components/accordion/) first example is using radio buttons as a hack to avoid Javascript, which would be very confusing to screen reader users (announcing the radio buttons to them).
This is why there's so much complexity in libraries like Radix - accessibility in the real world usually requires a lot of Javascript.
> This is why there's so much complexity in libraries like Radix - accessibility in the real world usually requires a lot of Javascript.
I agree in many scenarios, but for the two you mentioned it seems like the <dialog> and <details> elements provide accessible solutions out of the box?
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).
These comments don’t seem to have that much love for shadcn, which is unfortunate as I think it promotes good component file structure and reuse. The premise is that you could (and should) change the components yourself, as they are living in your code base and ”owned” by you, which is a radically different approach compared to other ui libraries.
Protip: the space between the UI control and the label should be done using padding (or achieved via label nesting) so that the entire area is clickable.
[ x ] some long label
ꜛꜛꜛ
padding here, not margins or gaps
(clicking between the control and the label does nothing now)
For some reason it's exceptionally slow for me on chromium. I click and I see it register half a second later. It also has no cursor:pointer which makes it look non-clickable. Is it expected or a bug?
> 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.
In a hilarious turn of fate, on iOS safari the first time one of the radio options is clicked after loading, the css focus style is applied, but a click is not always registered so the radio item ends up stuck in an invalid weird-looking state. I highly doubt the issue would occur if the built in radio were being used
Exactly this. OP fails to understand that there are reasons why it was done this way, and that someone who spent thousand of hours working on this might know something that they don't.
Well, usually, the reasons are to support every single use-case. A great selling point, but ultimately why I don’t like using things like this and importing loads of other libraries. Most of the code your importing is for some other user and any one app will probably be using a slither of the functionality.
I know if the lib is written well then you won’t be introducing unused code into your code base but you still often are left with an overly complex scaffold or other infrastructure to support all the stuff you’re not using. Just use a radio button for gods sake.
"There are reasons" is a pretty bland defense of why something was done in a bad way. You'd have to show that the reasons are valid, which I highly doubt. Also, somebody spending thousands of hours on making a worse version of something existing, isn't a good justification either. That's on the level of counting lines of code as a measure of productivity.
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.
For the "requirement of being able to put any element as the radio button.", Dan Abramov tells you that this is exactly the point of React, see his comment above:
> For what it’s worth, the point of React is that you can just fix that Radio component to be an input (if that makes sense) and it’ll just be an input. [0]
You’re misunderstanding. This isn’t about React, it’s the Radix UI primitives library which is being overcomplicated by it allowing you to put any element as the visual part of the radio button.
As for “the point of React” being that you can just do such and such… there’s nothing special about React there, that’s what any of these component libraries achieve (React, Vue, Svelte, &c., even basic templating systems like Handlebars a lot of the time).
Radix UI Primitives has placed this requirement on itself. What you’re quoting amounts to “component abstractions allow you to easily throw Radix UI Primitives away” which is irrelevant.
Can here to say this exactly.
Not saying they don’t raise an interesting point but the complete lack of curiosity why a group of experts in simplicity and accessibility decided to take this path is jarring
I mean, that much is obvious just based on casual reading of a few articles/discussions about "modern" front-end dev.
I am 100% convinced that "Modern" front end developers are in fact, afraid of CSS and HTML. Like, "it will steal my eyeballs and look back at my face with them" scared.
Nothing else explains things like this, tailwind, JSX components, etc. Nothing. There is no explanation besides absolute morbid fear of the underlying technology - because the browser support has improved immensely but apparently they're all deathly scared of using it.
Before you tell me that I don't know what challenges these problems solve: I was primarily doing front-end development.... 20ish years ago. One of my first jobs in the space was adapting the client side code for a J2EE app - mostly this meant removing an IKEA worth of tables and using CSS - in IE6 of all fucking things. Subsequently I created reusable UI frontend components (i.e. output some HTML, maybe this little bit of corresponding JS, you'll get a usable interactive components in a browser) for two different organisations.
I have said it before and I'll say it again. I think JavaScript developers heard about (or saw over someone's shoulder) how J2EE guys had ant/etc build toolchains, and had abstraction like FactoryFactoryImplementationFactoryBuilderFactory and said HEY THAT LOOKS COOL, and if it's harder to understand they can't fire me!!
It's like NIH syndrome but for an entire community of people whose primary goal is chasing the shiny, followed closely by resume padding.
Why does it need so much complexity to draw a radio button that doesn't look all that different to the normal one you'd get with a perfectly ordinary <input> field, except it takes around ten seconds to draw and then doesn't work properly?
In 2020, radio buttons weren't easily stylable in all mainstream evergreen browsers. That's usually the case why some components are over engineered. Of course they should have simplified them when all browsers fell in line, but tech debt is hard.
Author here: I tried to find answers in their docs but they don't provide any context. I expected to find an explanation of why to use their solution there but did not.
So for a React developer who doesn't want to include Shadcn/Radix, but also doesn't have time to build every component/a11y/compat/edge cases from scratch, what are the better alternatives?
Would be nice to list them here so developers can know a midpoint between DIY <-> Shadcn/Radix
Not as powerful, and you don't get this sweet 3rd-party pluggable component catalog, but it's much simpler and it's stable: there's no constantly evolving ecosystem.
Shadcn ecosystem might have calmed down by now, but when I used it years ago, the layers on top of it were super unstable, and I was annoyed every time I have to work on those projects until I got Opus 4.5 to refactor out of them.
There are many options, each with their own pros and cons. Also, you may or may not like their default styling and/or styling options. There is no one size fits all. Having said that, we maintain an incomplete list of popular UI libraries here:
One thing to keep in mind regarding a11y, the semantic web is accessible by default. It's once you break away from establish norms do things become harder or tricky, but if you can stick to using actual semantic elements and not div-soup you will cover 90% of your use cases (assuming your use case isn't relying on just the canvas element).
You don't want to build your own components but you also don't want to use pre-made components? At some point you have to pick one. If you really want a midpoint, it's literally Radix: behaviours are done, stylings are up to you
Claude Code can whip this stuff together quickly if you specify those constraints and are knowledgeable enough to know what’s possible with modern CSS, etc.
It has to be this way because we (the collective we) refuse to agree on adding proper UI primitives to the web.
We’re like 20+ years into web apps being a big thing and there’s still nothing like what’s offered in OS-native frameworks like Swift.
So anybody building a web app has to recreate SwiftUI in the browser every time via various bloated hacks (basically what Shadcn is).
If we could just agree on adding non-terrible cross-browser primitives for multiselect, popovers, modals, proper radio buttons, tabs, etc to the HTML spec and allow extensive CSS styling on every part of the element we could avoid these massive UI frameworks.
... beyond a specific size. This important distinction might transform "anybody" into "10%" or "5%" or "0.001%"—who knows, I'm still trying to figure this out!
What is it about multiselect or radio buttons that you feel is lacking in the current Web platform?
Well Shadcn gives you more freedom to fix stuff like this and rewrite how you want the component to work and look, since everything lives in your own code base. In a regular component lib it would be less likely that you'd think about this complexity, since it would be "hidden" away in node_modules or even transpiled and minified.
I still don't understand why someone would choose to essentially clone some code vs import a library. Suddenly you increase your maintenance burden, lose updates, etc. I've had no problems at all with UI libraries like Mantine. If you follow this logic, why not just clone all your npm repos and build from source. Ultimate control, right? Please help me understand the benefits here, because I tried out shadcn and wasn't into it
Incidentally, radio buttons are a (sadly) forgotten art and are neglected in modern browsers. There are many issues with them, which is why people reimplement them on their own.
Well I want to give shadcn some credit, building a comprehensive open-source UI toolkit, on your own basically, isn't as easy as one would think. Yeah you can use native elements except for some tiny edge case with say Safari and then you go deeper into the rabbit hole, until you decide you'll just customize everything. But at this point you probably have lost a lot of time and sanity already.
I'd put the blame on React and poor Web APIs in this case. Both are way too complicated for mere mortals to understand fully, and even simplest things like maintaining 100% container height through nested elements, can become a ridiculous time-sink for something completely unrelated to what is your main objective.
This is only "overcomplex" from a naive point of view.
Radio buttons, as with all UI controls, have tremendous inherent complexity, which comes to light once requirements ask for something beyond the blessed happy path of the default browser button. Pixel perfect styling, animations, focus behaviors, interactions with external state, componentized branding to fit in with companies' ecosystems, etc.
The baseline <input> paradigm struggles to provide the tools needed to adequately handle this complexity, even today, after many decades of web development.
And of course --- you can also argue that we should all just use the default browser button and everything should be solved. But this is also suboptimal, as it's clear from research that users prefer custom buttons if they provide more "features" than the defaults.
> it's clear from research that users prefer custom buttons if they provide more "features" than the defaults.
Hate to be asking for a "source", but what research? And what "features" can a radio button even have? You click it and it's selected. I suppose accessibility can be considered "features", but I'm strongly suspecting that the overcomplex button has worse accessibility.
> all UI controls, have tremendous inherent complexity
Well, this is true in a sense, but it's not exactly a good argument for re-implementing all that complexity in JS / HTML, instead of simply using the browser's implementation that's written in a real language.
>I suppose accessibility can be considered "features", but I'm strongly suspecting that the overcomplex button has worse accessibility.
Accessibility is incredibly hard to get right, particularly managing screen reader announcements, focus management and form validation. I recently had to build a website that met WCAG 2.1 requirements and it was made significantly easier by using React Aria (https://react-aria.adobe.com/) which is a similarly complex headless component library. To get an idea of the work that goes into making an accessible component, see their blog post about making a combo box where they test 4 different screen readers x 4 different browsers: https://react-aria.adobe.com/blog/building-a-combobox
(I haven't used Radix so I'm unsure how well they do a11y)
Agree, this kind of complexity is there for a reason. I would rather have a complex component that handles all the cases within its usage in the codebase over having a bunch of little hacks/changes in the usage. It's far easier to maintain one complex component than many different usages of that component.
And you don't have to use such a complex component library if you don't need it. For small codebases it often is overkill. But for large codebases it's a massively worthwhile investment.
But handling edge cases is a self-inflicted wound, because you have decided to re-implement something that already has an extremely well tested specification and implementation in the browser. This is almost always a mistake.
Author here. I've implemented all of these with the native radio button and CSS:
> Pixel perfect styling, animations, focus behaviors, interactions with external state, componentized branding to fit in with companies' ecosystems, etc.
Do you have a more specific example of something you've struggled with recently?
I am pretty new to frontend development (but have 20 years of backend)
I assumed I would need to use one of these libraries at some point. But, perhaps since I am using Svelte instead of React, whenever I ask AI to do something, then since I don't already use a component lib it just spits out the HTML/CSS/TS to do the job from scratch (or, depending on how you look at it, output the mean component from its training data).
I have to point out it should organize the code and give the component a dedicated Svelte file (sure I could fix AGENTS
md to do that).
I think with AI the usecase for these libraries is much lower. If there is anything complex you need AI can build it in some seconds specifically tailored for you, so..
I've been dabbling in backend and frontend stuff for about 25 years now, but for the past 15 years or so I haven't really had to do any webby stuff for work (and that's kind of how I like it).
Recently I've needed to put together a few things as "proof of concept" for things like internal directories and catalogues, and it's one of those "How Hard Can It Possibly Be" situations where we've had folk prevaricating for months with outline drawings and sketches and mockups.
So I knocked together a backend for it in Django, which worked okay, and then styled up the raw template with MinCSS[1], and then to do stuff like "find-as-you-type" and other "magical dynamic page" things I used HTMX[2] which has been discussed here endlessly.
No need for AI sloppiness. Just write some code, look at some examples, stick in some styles, and away you go.
I've used HTMX-like approaches a lot for other apps and I've been pretty frontend-averse, but this time I'm doing something similar to a drawing program with lots of d3 and SVG etc, very much the "real usecase" for SPA. So I feel HTMX doesn't apply to this specific usecase.
A html forms based radio button is worse than a complex - but standard - shadcn radio button many ways that matter in the real world.
Why does no one do the simpler thing? Because there’s no extra value to it, and it in fact has negative value because then the team has to write and understand it and the rationale for the departure from just using the same component library everywhere.
“Only a few kb of javascript” may as well ZERO javascript, and because of that it’s not even close to the top thing to optimize on your favorite site.
So, you engineered a non-standard radio button that is different to the rest which all use shading?? Why weren’t you building features that you know.. make money?
How's using a custom library any way close to "standard"? How about the actual HTML standards? The whole reason you'd use "shadcn" is that customizing the actual HTML radio button isn't enough for you. Otherwise, if you just want a default-looking button, here you go:
If your team can't understand that, how are they going to understand a few KB of JS? Or maybe they're not supposed to understand it, but how can you then guarantee to your customers there isn't a crypto miner or tracker or something in that? Or perhaps you care more about "making money" than protecting your customers from such things?
You should not look at the button in isolation. The library is likely used to do other things vanilla HTML cannot do, but instead of maintaining multiple code, they just use the library to implement everything.
The library has in essence became an interface for developers to build for.
Interestingly Radix has both `Radio Group` and `Radio` — The simple `Radio` input does use `<input type="radio">` but the `Radio Group` does not. Git history does not show _why_ though.
you all make it hard by bloating your sites with Jenga tower abstractions for styling, needlessly load content dynamically via Jenga tower javascript libraries that pulls complexity into frontend and most of the time puts unnecessary load on the content generator ("backend") too.
I don't know a lof of sites where that actually makes sense, as web === text.
When html5 came about, along with CSS3, it was such a big leaf in terms of ease of use and accessibility. I argue that what most websites do to my taste nowadays can be achieved by early-stage html5+css3+ a few svg.
Nowadays on about 50% of websites it have to
* enable 3rd-party JS just to get the text
* enable massive amounts of 3rd-party JS to get the images
* enable remote fonts just to grok your pathetic icon-only menu or even spot the 'search' feature (it's not even a 'button' most of the time) because you didn't care to use a proper <img> or <svg>
I don't think it's hard, it's harder than people think it's going to be. So they get frustrated and start abstracting away, ignoring history and hoping their fresh approach will finally make this thing easy.
I 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.
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.
Ok, I'll bite. I've been coding for almost 25 years so have seen various things come and go, so hopefully have a bit of capital in the bank.
Don't get me wrong, a HTML5 radio button is a beautiful thing, and sometimes React is a hammer and everything is a nail.
However, I think something that OP doesn't mention super explicitly in their post is the codebase they are working on is probably a React codebase. React is a great abstraction for building UIs. I've built a ton of them and the complexity only needs to go above a certain degree until you need a way more descriptive way of explaining your UI based upon other state, instead of trying to wire a load of DOM elements together.
If you are already using the React ecosystem, for things like form validation (again, possible with HTML5 but as soon as the complexity cranks or you can't use the server - you probably need a library), then using something like Radix is a great choice, OP even mentions how although it's not technically a visible radio button that is shipped to the DOM, it acts like one for a11y reasons, and this is due in part because it's very, very easy to write inaccessible HTML. And ShadCN is pre-made components on top of that, and they all work pretty well together.
Nothing is perfect, but even in my "old man yells at cloud" era, I personally don't think this one is worth yelling at the cloud for.
As someone who has never really dived into React etc., my main question is "where is the line?"
I'm sure you'll agree that React is overkill for some applications and, for the sake of this discussion, I'll agree that it's beneficial for applications beyond a certain complexity.
But where exactly (or even, roughly) does that line lie? A basic CRUD app? Surely not. A calculator? I'm guessing "no". Bluesky? Maybe/probably.
Bluesky absolutely yes, something like React makes sense.
I think it depends on a few things but the two big ones in my mind are:
1) Interactivity. How rich do you need/want the interactivity to be? As this scales up the benefit of React also increases.
Of course you can get highly interactive vanilla HTML sites but it’s much easier to achieve with React.
2) Statefulness. The more UI state you have the more a tool like React helps you.
Again, it’s not doing anything you cannot do with vanilla HTML/JS but the level of difficulty comparatively is night and day.
On top of that, React is widely adopted. The tooling is fantastic, the community is strong, the job prospects are very good, and if you’re hiring the talent pool for React is vast.
2 pieces of UI in different parts of the page that depend on the same data - that's the line (also matches the initial goal of React - sync FB chat widgets).
Note on the fact that this would add JS that needs to be loaded to see the page. No, because similar smart people created server-side rendering, adding another layer of complexity.
I much prefer React Aria's components. Yes fuck Adobe but take their RadioGroup for example: https://react-aria.adobe.com/RadioGroup Much better than shadcn's in terms of deps and LOC, and it uses an input. All of their components are built for accessibility first.
Yup, agents LOVE Tailwind+ShadCN. Even when I've explicitly told them not to use it, it still creeps in. There's a lot of prior art out on GitHub and LLMs can't help themselves. FWIW, the result does tend to look nice enough. For a POC I can't complain. If I'm really going to roll up my sleeves and get into the code though? I don't think I'd enjoy all of it.
As I was reading this text, my hands started sweating, my head began to ache, and I felt the anguish and terror of reliving a traumatic experience all over again. I can’t even count how many times I’ve been stuck in a project that’s already behind schedule, where the client (I’m a freelancer, working directly with the person who has the requirement) throws in a ‘simple’ request like: change the style of that radio button so it matches this other one.
The problem isn’t that—because of reasons like the ones explained in the article—I end up spending hours and hours on what looks like a trivial task. The real nightmare is when the client asks me: ‘Why are you taking so long to do something so dumb?’
It’s a nightmare. That’s why I ran away from React, because of this and countless similar situations, and went back to WordPress, where the world is so much simpler, the clients are happy, and so am I.
in early react days, and slightly before, the fun part was bidirectional binding and computed reactive values... but i admit that now it's become a big jungle just to recreate everything, plus it's rarely stable, new ui libs pop every year (shadcn is now rebasing on top of base ui i believe) .. seems wasteful now
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.
This is the reason I absolutely hate shadcn. The number of dependencies and files you introduce for trivial components is insane. Even tiny little divs are their own component for no good reason. I genuinely don’t understand how front-end developers accept this level of needless complexity.
Shoutout to Basecoat UI[1], so implementing the same components using Tailwind and minimal JS. That's what I am preferring to use these days.
> I genuinely don’t understand how front-end developers accept this level of needless complexity.
in my anecdotal experience as a bit of an old fogey with a greying beard, the enthusiastic juniors come along, watch a video by some YouTube guru (who makes videos about code for a living instead of making actual software) proselytizing about whatever the trendy new library is, and they assume that it's just what everyone uses and don't question it. It's not uncommon for them to be unaware that the vanilla elements even exist at times, such is the pervasiveness of React bloat.
Please name some names of these performative developer/engineers. I want to know how many are on my bingo card. Ill start, something imegen and tnumber geegee.
I 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.
I'd never heard of basecoat but it looks great. IMO this is what Tailwind UI should have been. It was utter stupidity that they forced you to use their preferred shiny new JS framework of the week for UI components.
> I genuinely don’t understand how front-end developers accept this level of needless complexity.
I call it 'Shiny Object Syndrome' - Frontend devs tend to love the latest new JS frameworks for some reason. The idea of something being long running, tried and tested and stable for 5-10 years is totally foreign to many FE devs.
Despite its age JS and its ecosystem have just never matured into a stable set of reliable, repeatable frameworks and libraries.
I evaluated a LOT of UI toolkits for React. The premise is always great - I want to save time by not having to build a UI toolkit for my application, so I'll use a great one off the shelf. But what I found was that the evaluation falls into three questions:
1. Does it look nice and professional?
2. Will it be here tomorrow?
3. How does it feel to work with - what does my instinct say?
The first question is easy. I either like it or not.
I can't answer the second one with certainty. Nobody can. I can only guess. Sometimes I'm wrong.
The third one is instinct driven. If the ergonomics feel off, my instinct will tell me. If something is not right, I'll feel it. I might not always be able to explain it, but I'll know it's a go or no go. ShadCDN came with big praise, but my instinct said a big Nope. It's stuff like that that make me think that, maybe, we add complexity because we get bored with the "boring" tech.
So? Did you open a PR for shadcdn or Radix? Did you throw out the shadcdn code rendering the radio button from your codebase? Did you ensure it doesn't come back the next version?
Otherwise you haven't engineered anything, you've barely outlined the concept of a plan.
Two lessons here: The complexity exists for a reason. Try to understand where it comes from.
Second: Thinking "it could be done this way, I think" is barely 1% of really outlining a solution, implementing it and convincing others to use it. The latter is the hard part, but actually changes things outside of your head..
As it is, you've joined the ranks of multiple others commenters who sound like cargo cultists, attacking OP for not understanding frontend dev without actually pointing out any issues in their writing. If it's easy to point out, then surely you can show how easy it is.
Have you tried completely customising a radio button with CSS? Feel free to demonstrate a heavily customised radio button style where you don’t hide the native appearance.
What do you mean by this? Seems like an arbitrary requirement to set. Could you show an actual example of how this overengineered style is easier to customize?
The pseudo element solution alone is extremely limiting in its ability to be customised. For more complex customisation you will need to decorate with additional elements within a ref’ed label - and then you are effectively back to what radix does.
Yes, several times. I've been specializing in front-end dev for over a decade.
I shared a simple example because Shadcn has a simple design.
You do often hide the native appearance if you need something complex, but doing that via CSS is still much simpler than a bunch of JS and a third party dependency.
If you have a specific design in mind I can show you how to do it.
I almost had the same reaction tbh! Like I remember inline-grid and place-content for example was not at all supported css, it would've been a nightmare to do, but modern browsers css support is way more powerful than my mental model of them still is. So it's time to update that mental model.
I don't touch frontend very often anymore, but you could see the writing on the wall for complexity when React took over and newer devs were working exclusively in that abstraction.
Unlike other abstractions where things get tidied up and more simple, React is much more complex than the technology it's building on. Necessarily, to enable it's features, but none the less it is a consequence of this that when all someone knows is React or other frameworks, things get overengineered. They didn't realise it could be so much simpler if they just knocked it back a layer instead of climbing higher and higher.
> when all someone knows is React or other frameworks, things get overengineered
The next level annoyance is that everybody just assumes React to be the default for everything.
Check the Shadcn website. The landing page doesn’t mention that this is a React-only UI library at all. Same with Radix. The marketing sounds like a general-purpose UI lib. You gotta dig around a bit to realize that this is React-only.
For pure HTML pages I use Basecoat which is shadcn without React: https://basecoatui.com/
Thanks, I did not know this existed and I find it awesome. How was the experience using it? I wonder if it's well maintained or if it has any annoying quirks.
But that's just classically styled library like bootstrap? How is it in any way similar to shadcn where you copy the component definitions to your code and restyle them with tailwind? It looks visually similar, but completely misses the point of why someone would use shadcn. Also many of the components have degraded functionality on firefox, I couldn't use this in an actual production application.
Personally I also tend to hate on what React has made the modern web, and I say this as someone who's made money for the past 10 years making React apps, but reimplementing half of something poorly and declaring success because it looks kinda similar when you squint is just silly. Many (most?) "pure html frameworks" are like this unfortunately.
New to webdev, coming from graphics:
What is better than react? I started with direct dom manipulation and it was a nightmare for making a 'modern' experience.
my brain for whatever reason won't accept react it's just instant ejection. i was there in the before times all the way up till jquery became uncool and i just tuned out of front end entirely once react and all the stuff driven by facebook became so ubiquitous, my soul just does not want to dabble in any of it. i think im mostly just appalled at what feels like over complexity that might've made sense over a decade ago but perhaps im waiting for a more satisfying paradigm to come along. i dunno. i had some sparks of joy tinkering with golang to build ssr stuff, i dont keep up with wasm at all but i hope its cruising along.
i wonder if what im after is like some kinda dead simple easy to use declarative front end api that can be built from a backend, something like streamlit or nicegui that has great ergonomics and is easy to maintain but scales better and has better state mgmt than streamlit & puts all the power of a general purpose programming language right there with it. i love compiled things i hate setting up environments with runtimes and stuff.
I get the feeling. From someone outside looking in (haven’t done web work since the heyday of Rails), React and the associated modern stack looks a whole lot like a Homermobile built on the frame and engine of a go-kart, all held together with duct tape and twine sourced from TEMU. The idea that this is the web’s “final form” is difficult to stomach.
Obligatory "you should try Svelte"
I've started straight up being doubtful of every UI kit until I see in the docs a HTML or non-React example.
There is a Vue version as well.
Here it is: https://www.shadcn-vue.com/
FWIW I've been writing UIs using plain JavaScript and the DOM API for like 15 years and at a certain scale, I always ended up building an ad-hoc framework or being disgruntled when I had to reach for any of the pre-React UI frameworks whose APIs and approaches I didn't like. React changes this, nowadays I either start with pure DOM and then rewrite to React or just start with React. I see a lot of hate online for React these days and I agree with probably 99 % of it, but the problem in my eyes is not React itself, but the ecosystem that spurred around it. If you stick to just React and take some care with your craft, React is a joy to use IME.
Not everything needs to be a SPA. I genuinely believe that the web would've been a much better place today on most important metrics (performance, simplicity, accessibility etc.) if this SPA shift would've never happened. The opportunity cost seems massive to me.
Most software I've used could have been a few hundred lines of PHP. But then they'd be done in like a day, which is great if you're a business owner (and the reason Pieter Levels uses PHP, for example), but not so great if you need to get paid to keep churning the code indefinitely (i.e. most people's situation)... and ideally hire all your friends to help too ;)
There are indeed less user-centric metrics with surprising weight when it comes down to it. I've also noticed that "We read a FAANG blog post and got enchanted" is easily remembered as "Everything was bad and we had to change it all" ;).
I don't find litigating this to be useful or interesting. Debating what is needed could show us lots of things we could cut. But would that bring real gain?
SPA's have really nice performance characteristics. Code is all loaded. The page can transition between states rather than total redraw. A good SPA should offer the same capabilities too, ought have URL routing and good history support.
I do think the web would be faster and simpler without SPAs. But it wouldn't be anywhere near as capable, as interesting, and as loved.
> I don't find litigating this to be useful or interesting.
I think it is useful because our field is woefully inept at anything resembling backtracking, and it's having concrete detrimental effects all over the field by, for example, increasing mountains of bloat eating up hardware improvements.
> SPA's have really nice performance characteristics. [..] A good SPA should offer the same capabilities too
The problem is that not even large teams without any obvious lack of resources are also unable to prevent sluggishness from creeping in to SPAs. So I guess there's a theoretical SPA and a de facto one.
> But it wouldn't be anywhere near as capable, as interesting, and as loved.
Capable sure, if you're creating Google Earth style apps. But when you start using vague and extremely subjective adjectives like "interesting" and "loved" it should be a signal that something's off here.
What you say sounds like we ought have suffocated and starved the web. I feel like "vague" and "subjective" is actually just pretty fucking obvious, didn't need a ton of support for it: the web is the go-to platform for app development because its featureful and works everywhere and is connected by default and nothing else comes close.
The web is where it is (literally everywhere) because it is capable and powerful, and it's because we didn't listen to retrogressive gate keepers insisting the web shouldnt really be for those uses cases.
The alternative to this is nothing. Is to not have had connected software. But we aspired to make great systems. That made some people very mad.
Nothing of that requires SPA, and the alternative is certainly not “nothing”. Not sure how you even get to that conclusion, strange rant. The meaning of alternative cost is not standing still.
> Nothing of that requires SPA, and the alternative is certainly not “nothing”.
Yes actually dev teams did have a massive leap in capability with dynamic HTML & updating the page.
> Not sure how you even get to that conclusion, strange rant.
Not sure how you even can miss that shift, strange miss.
(So, uh, do you always have to be such a deorgatory shit that I have to turn your crap faced mean shit back around? Can you talk like not a flaming shit bag? I don't super love turning your shitty mean crap ass personally aggressive negative worded words back at you, but you just have no vision & are ongoingly a mean shit about everything & so personally shitty about how you phrase things? And you are in such obvious denial. In ways that make zero sense. I don't think anyone sees how the web would grow while meeting your ridiculous constraints and that just seems obvious. Whatever third way you are trying to advocate for is clear as mud. And you cover for saying nothing with aggression! But mostly just stop being such an aggressive ass & engage like you can get over yourself, pull your head out of your ass, stop being a belittling shit, and make a God damned case, rather than throwing endless more empty bile.)
My god, another HN village idiot.
Personally, I like to look at the source for a page. And that, for anything React, winds up being useless (<go-suck-an-egg-because-EVERYTHYING-is-loaded-dynamically/>). I find React very hard to debug whenever anything doesn't work as expected.
The react dev tools browser extensions deal with this pretty well. Not sure what the issue is. You can even inspect all the props.
I agree with this and consider this to be a massive downside to React.
I work on a React based web app in my Day Job and have genuinely enjoyed it.
That said, it always feels like so much boilerplate to get up and running for a greenfield project (and things like NextJS or even TanStack Start add a lot of things that might be overkill for a simple web app).
For some vibe coded side projects with Claude, I’ve been working with just using handlebars templates with Express and it has been pretty glorious!
I don’t think I’d recommend building a complex web app this way, but for some mild JS interactivity, form submission, etc, handlebars works.
Bonus: I find it much easier to get 100 across the board on Lighthouse scores this way.
> and have genuinely enjoyed it.
People who haven't work with other frameworks like svelte, Vue - normally say they are enjoying React.
This is a bit reductive.
For what it’s worth, I’ve used Vue and don’t like it (stuff like custom directives that are nonstandard html, not as explicit about event handling and data flow, etc).
I’ve seen a lot of buzz (particularly on HN) about Svelte but have lacked the motivation to try it.
I wish more people would criticise Svelte but most people just don't care because it's irrelevant. It's like complaining about Backbone or something, not worth the effort.
I wanted to like Vue but when I tried it I didn't. For writing ordinary business applications I wish React reified lists more than it does, but what I like about React is that I know how to draw absolutely anything with it, including 3-d worlds, see
https://aframe.io/
I've tried both and disliked both. Already before I did I was wary of patronizing-feeling statements like these, though. The Vue community in particular, or at least the vocal pockets of it I've come across online, seem like a web dev counterpart to the Rust evangelism strike force.
Vue and Svelte both introduce too much mystery-symbol syntax for my taste, and two way data binding has felt bad since Angular 1.
> it always feels like so much boilerplate to get up and running for a greenfield project
This is why I love Bun + React. The setup is so easy I can do it off memory. I always hated boilerplate, templates etc. so this is a huge selling point for me.
Hard feelings here. I like react and have to work with it, still it is all insanely wrong.
The best approach I've found so far is egui , and I hope people are moving that direction. Draw whole frame, collect events, process, update internal state.
I came to really appreciate React over time.
My initial objections were: (a) circa 2006 I was making very demanding RIAs such as knowledge graph editors and GIS decision support software and I've yet to see any modern framework that is as good as what I was using then (not in JS but rather GWT and Silverlight w/ the same async comms) and (b) the React model is not a 100% match for the form-based applications that we usually write with it (but boy do I love react-hook-form)
React is like the code in Graham's On Lisp [1] in that functional programming is used to create a sort of DSL. There are a lot of ways to implement reactivity that usually require a special interpreter (spreadsheets) or compiler (Svelte). React's system does show seams (you really need to be on top of identity and equality) but it is remarkably simple.
React shines, in my mind, for things that aren't form applications. For instance, VR applications with AFrame -- it's somewhere between VRML and Unity. I am working on a (mainly) heart rate variability biofeedback application [2] and it is so easy to make dashboards that display real-time metrics as well as Poincare sections and time series. That is, I can slap together a few data processing functions and widgets and make a new dashboard with new metrics and charts or new sensors. One goal is to get it working on a tablet in a two player version.
The disadvantage of React is that it does not work so well for highly dynamic layouts. In my case I have a library of functions to "fetch" the data stream and put them into the top of the component (may even package as hooks) and then put the layout together with JSX. I'd like to have a version where the user can drag and drop the components to make a custom layout and the system figures out the dependencies for the data fetching, preparation and processing like the things I made in 2006 and that kind of application with a dynamic layout (think programs like Photoshop with lots of different little widgets and property sheets) wants a different approach to reactivity.
[1] use of macros in that book is a red herring, the one example in it where you really need macros is when he is implementing cooperative multitasking, a feature that Python and Javascript already have -- most examples from that book as with Norvig's Lisp book can be coded up just fine with
[2] see https://github.com/paulhoule/VulpusVision it might "just work" if you npm install, npm run dev, and look at it in Chrome and connect with a Polar H10 or other BT monitor
I don't think this is specifically a react problem. The problem is that people don't want to learn what modern CSS can do, or write it themselves (see Tailwind), and most new frameworks make it easy to just sidestep that with div soup.
Some of us _like_ CSS, and try to use as much of it when possible, but I feel like we are few and far between. I use react to manage the state of my app, but that doesn't mean I have to make a 27 div component to style an input.
The big problem is trying to convince the rest of the team that they should learn and use CSS.
I agree it's not just React - I think a lot of people simply do not know what CSS can do nowadays.
I do like Tailwind (I guess it fits with how I think). But to make good use of it you _do_ need to know how CSS works (for example, using variant selectors for picking out child elements, using container queries instead of global breakpoints etc).
One addition - I learnt a _lot_ about CSS by reading [Every Layout](https://every-layout.dev/).
I really don't understand Tailwind. I heard great things about it, and then I tried it and it seemed like setting style="" on all elements, but with extra steps.
Did we go off semantic CSS and returned to setting properties on each element, or was I using it wrong?
Plain CSS is very useful if all you have is an HTML page. Giving all buttons a consistent look is nice and easy if you can just specify that with a nice CSS selector. That's also the only place you can do it without changing all <button> tags.
If you're building a component-based UI, that need is less, because all your buttons are created in a specific Button component. That's also an easy place to attach styling. You don't even need a separate file anymore.
But that's a wash. It gets much more interesting if you have components that are used in different contexts. Unordered lists for example can be an unordered list in the running text, but also a navigation list in the footer, the menu, or as tabs. There's some semantic logic to having those things as lists, but they usually look completely different.
You'd use classes and descendent selectors to deal with those differences. The downside is that those leak very easily to instances that you don't want them in. Having normal lists inside tabs inside running text requires careful engineering of the selectors.
The larger and older your project grows, the harder it becomes to get that exactly right in a future-proof way. At some point changing something for one item somewhere, can completely mess up something on another part of your site.
Inline styling, or Tailwind-style utility classes, are useful in that situation. Every component gets to be responsible for the way it looks and no longer has to care what anything else does. HTML tags that are used in different contexts will have their context right there, next to the styling. All part of the component.
The few remaining things that you need for consistency between components (colors, sizes, fonts, etc.) can be handled with CSS variables.
Why not scope your styles in the component, using either a css in js approach, like Vue, Svelte, and surface do, or use the modern css @scope property?
That's interesting context, thank you.
You aren't using it wrong, the only thing tailwind does better than 99% of devs is having default values that both look nice and mesh together well.
Utility based CSS has been around as long as classes have, tailwind is just one iteration of that. GitHub use to have a utility css library as well before switching to their new design.
> having default values that both look nice and mesh together well.
So 99% of the value can be achieved with strict linting and autocomplete plugins.
Yes? I don't think anyone has ever argued that tailwindcss has a moat on anything, it has always been championed as a library created by a designer + dev who care about good UI design.
At least that's how I always seen it billed as, even when Adam was live streaming and saying as much in like 2018/2016.
If you're experienced with or like the way CSS works, and you didn't like Tailwind, then you were probably using it correctly.
> and it seemed like setting style="" on all elements, but with extra steps.
And extra benefits.
Generally more concise on the common usecase, but more importantly you can combine and use media queries, which can't be done with inline styles alone.
CSS is a little too low level for most web app design, Tailwind is a bit higher level and more concise than its CSS equivalent. It also has a bunch of sensible defaults for colors, sizes, spacing, and type.
Encapsulation, e.g. utility classes (and Tailwind, by extension) solve for project management or organization level problems, not styling problems directly. The nice defaults are a bonus but the actual value is a common and agreed upon approach to avoiding a write-only stylesheet that grows forever and for not fucking up cascading styles that impact someone else's feature or page you didn't intend to and causing releases to grind to a halt while they sort out what you did. Everyone here who misses that point is basically broadcasting how they are the cause of long term problems in their project or at their organization.
You make a good point. From a philosophical point of view, abstractions should hide complexity and make things easier for the human user. It should be like a pyramid: the bottom layer should be the most complex, and each subsequent layer should be simpler. The problem is that many of today's abstractions are built on past technology, which was often much better designed and simpler due to the constraints of that time. Due to the divergent complexity of today's abstractions and unavoidable leaks, we have a plethora of "modern" frameworks and tools that are difficult to use and create mental strain for developers. In short, I always avoid using such frameworks and prefer the old, boring basics wherever possible.
> divergent complexity of today's abstractions
The vast majority of websites and apps do not have complex divergent abstraction needs.
Some developers however require complex divergent abstractions in order to baffle brains and collect paycheck.
I'm struggling to form a definitive statement about my thoughts here, but I'll give it a try:
Every (useful) abstraction that aims to make an action easier will have to be more complex inside than doing the action itself.
Would love for someone to challenge this or find better words. But honestly, if that's not the case, you end up with something like leftPad. Libraries also almost always cover more than one use case, which also leads to them being more complex than a simple tailored solution.
I think of it as: adding an abstraction relocates complexity away from what you want to make easy and moves it somewhere else. It does not eliminate complexity in total, it increases it. The best abstractions have a soft edge between using them and not using them. The worst are like black holes.
The problem is also that every other year contracts/paradigms/... are broken, introducing bugs in libraries and documentation.
For what it’s worth, the point of React is that you can just fix that Radio component to be an input (if that makes sense) and it’ll just be an input.
React gives you boxes to put stuff into but you decide what to put into them. Then React ensures that you can change what’s in those boxes without breaking anything. That’s the power of component abstraction.
> That’s the power of component abstraction.
Yes. But React isn’t the only way to do components. Unfortunately, to the inexperienced, it is.
What are some much better ways to do components?
React with is so prevalent because it's a deep local optimum.
So is a span or div element? What am I missing here?
The parent comment is seemingly blaming React for the decisions of Shadcn for some reason.
There’s nothing about React that requires you to overcomplicate your DOM (unlike many other UI frameworks).
The point I wanted to emphasize is that even if you do overcomplicate your DOM, the component abstraction is what allows you to fix it in one place. Don't like what's in your component — add `return <input />`, bam! It's fixed across the entire app now.
And how is the surrounding JS code, like the event handlers, and the CSS of the component supposed to still work now? A radio input will need at the very least additional CSS to remove the native appearance. Unlikely that was set already --> it's not that easy.
The idea is that the component's API is not the DOM. Usually this means your data should flow in a certain way: top-down.
Application code is not supposed to use the DOM as the source of truth for some boolean state that the checkbox is an input for.
You don't usually read a component's state from outside (here: the "checked" property).
Instead you define an API where data only flows top-down.
When your checkbox component follows this paradigm, it is "controlled", and if it contains a standard HTML input, that input's "checked" DOM object property is bound to the data passed into the component ("props"). Clicking it won't check it anymore until you add an "onClick" callback and pass a function into this callback that will make the "checked" prop change.
The checkbox is now "controlled" and it's state was "lifted up" (meaning that it is determined not by the checkbox component itself).
"controlled" means you tell React to always force the "checked" DOM property to be the same as the "checked" prop you pass into the component. You do this by assigning to the reflected "checked" HTML attribute in JSX.
When your components only use this "top-down" data flow, they're "pure" in React lingo. Because they look like pure functions: props => DOM fragment. The machinery behind the scenes means they're not actually that (something has to coordinate the rendering).
But if you don't use internal state (e.g. useState hook) or global stores, these "impure" parts are React internals only, and you can have a mental model that views the component like a pure function.
This makes it easier to connect it with other components in a tree.
For example:
HTMLInputElement.checked can be true without a "checked" attribute being in the markup.
If you want to have some text next to it that says "checked / not checked" you have to wire stuff, and this stuff depends on your markup.
If you have a "controlled" checkbox, you have a tree, not only for the markup, but also for the data: the boolean "checked" state can now be declared one level above both the info text and the checkbox. Then the info text doesn't care at all about events anymore.
And the checkbox component only uses a callback that is also independent from the exact markup structure (e.g. a selector for the HTML input element).
You don't need to read from the checkbox to update the text. You feed both with a boolean and both can be "pure" components. The checkbox gets a "onClick" callback and it's checked state is no longer internal, it's "controlled".
The wiring you have to do instead of the regular DOM events (which would read the input's state) is now to use your "onClick" callback to toggle your boolean.
Internally, in the component, you do whatever you need to read and write to the DOM. But usually that just means "what markup do I return".
Input elements and reflected attributes such as "checked" are already a relatively complex case.
And, you can escape the recommended top-down data flow by many means (refs, context, accessing centralized "stores" from within the component...), but that's often where it gets ugly. But you need to do it often when your app gets bigger (centralized data stores), or when you implement things like UI libraries (refs).
Which also allows to create an overcomplicated jack-of-all-trades component? After all, it's fun and can be justified via the "write once" argument.
I guess it depends on your definition of complexity. Being able to think about your UI as a function of state is a lot simpler than dealing with mutability, coordinating imperative updates all over the place, etc. React’s core idea is simpler than the paradigms it replaced. By simple, I mean as in “Simple Made Easy”[0].
[0] https://m.youtube.com/watch?v=SxdOUGdseq4&pp=ygUQc2ltcGxlIG1...
React is not simple (preact is) and what's worse, it gets more and more overengineered in order to solve the problems they have themselves created (accidental complexity in your video).
Sadly, accidental complexity is a common theme among react devs, not just ui libs, but also react-router, redux, redux-form, even tanstack useQuery() is way over-engineered and the core idea can be implemented in <50 lines and then you own the code and can make project-specific changes.
Maybe that's the biggest issue after all, people being lazy, expecting to do npm install and being able to reuse everything in any situation. Except that it almost never work like that and a lot of damage is done in the name of it... </rant>
Well, to be fair, Preact is what I use. I use the name Preact annd React interchangeably when discussing tech, but I agree Preact is the simpler and preferable of the two. But, in the context of this thread, both provide a nearly identical way to model UI.
> React is much more complex than the technology it's building on. Necessarily, to enable it's features
React, just like most software today, is excessively complex for the tasks it performs.
The only reason React is used is that many use it as a framework to attempt to provide more interactivity on the page without page reloads. There are other frameworks to do this, but none are as well-used.
Webpage interactivity with data was accomplished with page reloads via cgi-bin in the 1990s. Everything that has been done since then was not strictly necessary to produce the websites we use today; it would just be a more choppy experience.
A smoother experience didn’t require the overwhelming complexity that was introduced primarily in the 2010s in a framework war that React basically won. That complexity is the reason why many web and full-stack developers in the 2010s (such as myself) lost their minds and quit or seem incredibly depressed, grumpy, and confused much of the time today, and why some have invented strange new frameworks to attempt to reduce this complexity.
I'm just genuinely really confused by this take.
It's a 100x easier to build products today than it was in the 1990's. (I don't think that's an exaggeration in the slightest)
It would be basically be impossible to build anything like Maps, Excaidraw, Chat GPT etc.
Arguably people are reaching for the tools without those interactive requirements ?
Managing state and syncing it to the DOM manually is much harder than React (or any other big framework) for any non-trivial web app. Reactive, inherently asynchronous, event driven applications get complex easily.
Right. I encourage young devs to build a complex app using vanilla js. Feel the pain of two way state management. Then you’ll gain an appreciation for react. And you’ll learn browser APIs and know when react is overkill because it has its own pain
And, you'll know why this statement
> But for several years we've been able to style radio buttons however we want using a few CSS tools
proves how good the current state is, where a dev can think things will just be ok, for everyone, if you just ripped all that complexity and ship it (which should be the attitude for a good framework).
i’ve tried this, and it almost almost works to just rebuild the Dom on every state change as a pure function of state without any react or anything. The resulting interface is actually way snappier than react – but preserving local state of elements like what text is highlighted, where the cursor is, which radio button is tabbed to etc turns into a nightmare.
With all due respect, I don't believe it is "more snappier than react".
React itself with nothing else is plenty fast. You would have to go way out of your way to see performance differences between different UI approaches, computers are just way too fast to notice whether this click resulting in the div's text changing to +1 is slow or fast, even if the implementation were crazy convoluted.
What makes react apps slow is using it badly, and having 10 other libraries getting in the picture loading fat UI elements, etc.
And frankly these would be much slower in your render everything anew approach.
This is where "react is a library, not a framework" kinda lets it have its cake and eat it too. preact is 4 kb, React + react dom is like 30 kb, but when I use it under commercial pressure to deliver it seems to climb into the megabytes. I'm working on a react native app right now that is a completely embarrassing 150 Mb. The experiment in no react, build UI from scratch every state change has stayed around 65 kb without much attention paid to bundle size, with 10 kB of that being a bunch of linear algebra and differential equation solving code and 50 kb of that a plotting library that's completely nonblocking for the rest of the app.
Based on your description it sounds like you were halfway into reimplementing the virtual dom that react uses (or use to use? unsure if they moved away from that with the implementation of a compiler).
Yep. The “I’m sick and tired of of X (re-implements X)” cycle haunts me- I think I’m the wrong mix of picky, whiny and industrious
It's not even the young devs. It looks like most of those complaining are back end developers who "rarely tinker with frontend" but think they can teach everyone else how to make it simple because "it should be static forms".
A great example of all-world-is-a-nail stance mixed with extreme hubris.
I did spend a serious amount of commercial time developing fronted UIs in React, Angular, and the before times in vanilla JS/css. I even wrote my own UI framework in Web Components, developed my own CSS framework used by an agency churning out projects for years. You get the idea, I did the thing, commercially, for over a decade. React and Angular are absolutely more complex in practice. That's fine, if you want the features go ham. But you don't need them, and most people mis-use the power and end up with a slow complex mess.
Perhaps those same people would have a slow complex mess in vanilla tools too though, so maybe React is a scapegoat like PHP was, and Javascript was.
It was fine when it started, it's the addition of useEffect and hooks that messed everything up. Although normaly I prefer functional, for react classes were 100 times better
I know people love to make UIs stateless and functional. But they just aren’t. IMO UIs are fundamentally a bunch of state, graphically represented. So naturally all of the functional frameworks are full of escape hatches.
I’d rather have a honest framework than a chimera.
I have not followed SwiftUI recently but when it was introduced I quite liked to have the main composition in SwiftUI and then writing more complex components in pure UIKit. Both could be used what they are best suited for. But trying to shoehorn good interactivity into a SwiftUI component always ended in horrible code.
What about Elm? I think most people could grasp the elm architecture in an afternoon. To me this MVU style is pretty much perfect for UI.
I think a lot of the time React appears complex and hacky is because we tried to solve world hunger with one component. I've worked on plenty of React projects that were very easy to scale, modify and iterate because they focused so heavily on small independent stateless components.
Elm is awesome until you try to use it in an actual app. The amount of pain we went through trying to make a basic web app with a sidebar and a few pages... I don't remember the specifics, it was a few years ago, but I don't think Elm has changed much since then (it was 0.18).
> I know people love to make UIs stateless and functional. But they just aren’t. IMO UIs are fundamentally a bunch of state, graphically represented. So naturally all of the functional frameworks are full of escape hatches.
Functional does not mean no state, just constraining state to inputs and outputs. Breaking that is a choice, and not good design.
Elm, for example, provides all of that with one escape hatch: ports. It is really well-defined and that not fall into any of the impossibilities you mention.
> UIs are fundamentally a bunch of state
React doesn't really contest that as-worded. It's just that, ideally, a nested component isn't the owner of important state.
I also have the same somewhat controversial opinion, the frontend community wasn't ready and (still isn't) to organise a functional codebase.
The second problem is that React has a "draw the rest of the owl" mindset. Sure you have nice frontend components but now what about caching? data transfers? static rendering? bundle size & spliting? routing?
The reason for React’s “draw the rest of the owl” (which is a great way to describe it) mindset is that it’s born not as a framework but as a library, and to this day self-identifies as such. It by design tells you nothing about and is agnostic with respect to how you organise your code, where to put tests, what bundler to use, etc.
IIRC React itself doesn’t even know anything about the Web or DOM, as that integration is supplied by the pluggable reconciler, which lives in a separate library (ReactDOM).
One could argue that with the amount of batteries included perhaps it ought to undergo a grand status change, but until then it’s hard to blame on the authors of a library that they are not delivering a framework.
Indeed but while being a library is okay for math tools or pdf generation, it evidently didn't work well for building UI components.
Did it not work? Many successful and complex sites and apps use React—whether directly or via a framework (Next, Astro, or something homegrown)—and indeed many frameworks are built on React.
> math tools or pdf generation
In this case the original scope of the library was “reactive rendering”, which sort of makes sense.
It worked as in react is the de facto frontend choice.
It didn't work as in if I were to ask for the router, state management, etc library, there would be a combinatorial explosion of react "frameworks", all sucking in different ways.
I am (and supposedly grandparent also) on the option that react leaves out way too much that would still be well in the scope of a 'UI framework', and while modularity can be a good thing in certain things, more modular, more moving parts does increase complexity.
I've been there since the early days of React and I haven't seen a single React codebase which isn't a pile of duck-taped random packages, often leading to poor user performance.
Maybe it can be done, maybe not, but the average front-end dev doesn't have the insights to fill the gaps that React has left.
Some codebases are better than others, more mature open-source projects tend to be more polished, closed enterprisey things can be nightmare fuel, but that’s all probably universal to a degree and not specific to whether you’re using React or not. (OK, dependency mess is at least somewhat specific to JS.)
My real development experience started with Django—arguably one of the best-documented proper frameworks out there even before it reached 1.x—and let me tell you: the kind of garbage I have seen once I started doing it professionally still makes me shudder[0].
I agree with you in the sense that the choice to forgo a framework and use only a bunch of libraries directly should be very carefully considered. Frameworks exist for a reason. The decision should be made with the full understanding that one would implicitly undertake a task to create a framework (even if it is a narrowly specialised one just for that project). A lot of what you do if you go with raw React will not actually be front-end development: prepare to be vetting dependencies for (or implementing yourself) very basic functionality, fighting bundlers, trying to get TS to use correct global typings for the context, managing version hell to get all of the above to interoperate, etc.
(By the way, any mistake you make will be on you. Picked a test runner that was discontinued? Some transitive dependency got hijacked? There is no one else to blame. There’s no BDFL and expert core dev team vetting things, knowing when and how to write from scratch if there’s no trustworthy third-party implementation, orchestrating working version combinations, or writing migration guides.)
[0] Indeed it would be hubris to claim I myself have never ever architected something I would later call a monster held together with bits of duct tape.
Yeah, as a solo dev quite new to frontend, that made me nope out of React almost immediately. Having to choose a bunch of critically important third-party dependencies right out of the gate? With how much of a mess frontend deps seem to be in general? No thanks.
I settled on Svelte with SvelteKit. Other than stumbling block that was the Svelte 4 -> 5 transition, it's been smooth sailing. Like I said, I'm new here in the frontend world and don't have much to judge by. But it's been such a relief to have most things simply included out of the box.
I've been doing frontend since 2012 and I still don't understand why React became so popular.
No two React projects are the same. Like, even the router has at least three different mainstream options to choose from. It's exhausting.
Even when it's the same router package, these things break backward compatibility so often that different versions of the same package will behave differently
That router thing seems crazy. I'm all for having options that are available. But not having, at the minimum, some blessed implementations for basic stuff like routers seems nuts. There is so much ecosystem power in having high-quality, blessed implementations of things. I'm coming from working primarily in Go, where you can use the stdlib for >80% of everything you do (ymmv), so I feel this difference very keenly.
> There is so much ecosystem power in having high-quality, blessed implementations of things.
Indeed. I work mainly in Angular because while it's widely regarded as terrible and slow to adapt, it's predictable in this regard.
Also now with typed forms, signals and standalone components it's not half bad. I prefer Svelte, but when I need Boring Technology™, I have Angular.
90%+ of all web apps are just lists of stuff with some search/filtering anyway, where you can look up the details of a list entry and of course CRUD it via a form. No reason to overthink it.
> widely regarded as terrible and slow to adapt
I know you are saying you do work mainly in Angular, but for others reading this, I don't think this is giving modern Angular the credit it deserves. Maybe that was the case in the late 20-teens, but the Angular team has been killing it lately, IMO. There is a negative perception due to the echo chamber that is social media but meanwhile, Angular "just works" for enterprise and startups who want to scale alike.
I think people who are burned on on decision fatigue with things like React should give Angular another try, might be pleasantly surprised how capable it is out of the box, and no longer as painful to press against the edges.
Strong disagree. Angular is cursed to the bone. It got a bit better recently but its still just making almost everything totally overcomplicated and bloated.
I'd say what you call bloated is in many cases basic functionality that I don't have to go looking for some third party package to fill. There is something to be said for having a straightforward and built-in way to do things, which leads to consistency between Angular projects and makes them easier to understand and onboard to.
IMO, it is only as complicated or simple as you want to make it these days, and claiming otherwise likely is due to focusing on legacy aspects rather than the current state of the framework.
FWIW, I'm not arguing that it's the "best" or that everyone should use it. Or that it doesn't still have flaws. Just that it is still firmly in the top set of 3-5 frameworks that are viable for making complex web apps and it shouldn't be dismissed out of hand.
Hooks were fine, but their implementation in React was barkingly insane. Vue's notion of "composables" is very similar, but not dependent on order, so you can use them in conditional statements without breaking the world. I don't even want to think about doing a complex Vue app without the VueUse library.
Is this the same with everything? In the past, a hard drive, a mouse, or a web camera was a dumb piece of hardware and a driver that ran on your PC. Now, IIUC, each of those has it's own computer (SoC) running an entire OS. Your phone probably has ~20+ SoC. One for USB, one for Wifi, One for Bluetooth, one for each of the 4 cameras, one for lidar, one for SSD, one for cellular, one for the secure enclave, one for audio, Each of them is an entire computer, more powerful than most 1980s general purpose computers, running an entire OS with multiple abstractions internally and all of that to make that device appear as yet another abstraction.
Am I wrong?
There is a difference between implementations getting more complicated vs. interfaces. It doesn’t matter if the mouse has a SoC if it still only exposes the same old USB HID protocol. The issue discussed in this thread is that the developer using the thing isn’t shielded from the increased implementation complexity and can’t just work with the abstraction.
React was built to satisfy the specific scaling and complexity needs of Facebook, and this CV-driven industry jumped on board with it pretending that what's good for Facebook is good for them. The incentives are completely misaligned: it's like nobody gains anything out of using the least amount of force and abstraction to solve a specific problem.
I did frontend before React, and it was a welcomed change. The core insight of UI being a function of state is a good one. It saves you a bunch of headaches from the jQuery days where you’d have multiple code paths per UI element (adding, removing, mutating). That said I think they lost the plot with hooks and things have gotten needlessly complex since then.
> The core insight of UI being a function of state is a good one.
We had that before, it was called HATEOAS.
Worse still is the misunderstanding that React is simple. It’s an endless stream of cache invalidation bugs. Linters are getting better at catching these. But they also have false positives.
What is cache in this context? useState? What do you mean by cache invalidation in react apps?
Stale closures, perhaps.
It never happens if you enable the lint rule.
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.
I've seen React components where div is used with click event for adding a normal link
The problem is app-document impedence mismatch. CSS makes stuff easier but for doc-like pages. In addition doc-like pages want some app-like niceness too.
If you need to be an app you usually need a framework to stay sane (evidence: most other native UI kits are frameworks of some sort) and thus React etc. But they want full contol. Thus 2 ways to do a radio etc.
This radio selection is brilliant silly, especially because the end result is indecipherable from a vanilla css rqdio button.
For some reason people keep going back to complex UI and interactivity frameworks though, does anyone have a good example of a large website built without all this bloat?
Asking because I've seen hundreds of small sites built with elegance and simplicity, and few large ones. Is it just inevitable that as a team size grows, someone introduces insanity? Do these tools solve an actual problem that I'm missing?
https://www.mcmaster.com
2022 post about it. 1400 points. ~500 comments:
https://news.ycombinator.com/item?id=32976978
Not the prettiest but absolutely amazing to use! I'm sure web devs are laughing at me right now, but I genuinely didn't realise websites with that many images etc could actually be that fast.
I would recommend comparing to
https://next-faster.vercel.app/
NextFaster feels faster than McMaster IMHO
Can't agree. That website is much simpler. Just a static list of images and text.
There's no complex, dynamic filter. And no special rendering per type of item.
It's a glorified tumbler since the only dynamic part looks like the shopping cart. Everything else is pre-rendered from what I saw in code.
For static content like that I would have used Astro which is the golden standard.
~$500 for hosting that site feels insane to me [0]. I feel like a single $10 VPS could handle that load.
[0] https://github.com/ethanniser/NextFaster?tab=readme-ov-file#...
The extra 490 saved isnt worth the optimization. headache
We went out of business, but I made a web app for videographers to collaborate during production. Same things as frame.io. This was over 15 years ago. Frontend was pretty vanilla except relied heavily on jQuery. The main section of the app allowed you to commend on specific frames in a video. The code is split up amongst multiple files. Here is one: https://github.com/StevePotter/Takeoff/blob/main/Takeoff.Web...
Look at any of the sibling `app-productions-details*.js` files. Combined they formed a single interface. It was dicey. But damn the interface was snappy. I mean, instant. Code would have been much less these days but probably nowhere near as responsive.
> does anyone have a good example of a large website built without all this bloat?
How about this one?
Don’t think it counts
Why not?
Because this site is only "large" in the context of userbase. It could be developed by a single guy in what, a week? Two tops?
With LLM? More like within Day(s).
I'm assuming they're asking for large in terms of complexity, not in terms of popularity.
As company size grows, managers want to settle on a "standardized" tech stack that doesn't get in the way when they want to hire and fire people at will.
Nobody was ever fired for choosing React (or IBM). But everyone can get fired when they're working on a React app.
One major reason for this, in my past experience, is that designers push for heavily customised components. If you go back to them with “why not use the default radio button with a bit of styling?”, I’ve yet to work with a designer that would relent, the specs are always for crazy UI work.
Its because everyone can see UI, and many have strong opinions on it. Its always the first tragedy of the commons. In a typical tech company built on compromise, fighting the complexity is a fools errand.
photopea.com is entirely written in JavaScript and as far as I know, it doesn't use any fancy JS framework.
Cant speak for shady lib specifically but yes as you grow you do find that default styling doesnt work or you want something which doesn’t exist.
The crux tho is that this usually happens in what id call web apps and not websitess. Web apps are far more complex and powerful. It is a spectrum tho and sometimes websites grow into web apps which is why people oft over engineer early on.
Developers remember, you can always push back on design requirements instead of bringing in more bloat.
I was sitting next to one of the devs in a co-working space and he was trying to figure out some specific layout issue in react native. He spent 4 hours + installed a dependency to be able to do something completely tiny on a privacy policy screen. He asked me how I would do it, I told him to just ask if it can be laid out differently. He got it approved and implemented in 10 minutes. No bloat.
I'm finding it's better to use "javascript-less" UI frameworks [Pico.CSS, Skeleton, Bulma, Tailwind/daisyUI]. You get most of the benefits using good use of CSS. Anyone used these JS-free solutions and have recommendations?
My current choice is DaisyUI. It’s pretty good and because it’s based on tailwind you get the rest of the ecosystem benefits. Super easy to extend and change. Class bloat is much more manageable than raw tailwind.
If you like how shadcn looks, you might want to consider basecoat: https://basecoatui.com/
This is the kind of stuff we have to do because almost all browser <input> elements are terrible in terms of customisability. Especially radios and selects
If you're one of those who think we should just use the default, bear in mind that the default radio button has poor usability for mobile users.
> 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!
There are lots of ways to style these native controls, though, including ways to start from scratch and retain the accessibility affordances.
I'd be curious to know more about the usability issues you've found on mobile -- I've not had any personally when using radio buttons. I'll readily grant you that 'select' is awful everywhere though!
It’s a lot easier now than it used to be. Radio buttons used to be nearly impossible to style, and I still think they require scripting to de-select— so none in a group are selected after one has been selected. I’ll bet most of the complexity in the article is some combination of keeping support for older browsers, technical debt, and nobody complaining about it because it works.
The only <input> that is annoying to style is the “select” one because it’s hard to style the “options”. The rest seem reasonable and quite customizable in my experience.
The date picker still sucks.
I admit I haven’t had to use the date picker in a long time but I looked at the MDN for an example of the default implementation of it and it seemed fine on my iPhone. What issues have you encountered with it? I imagine it’s a different story on desktop browsers.
It’s been good on mobile for a while, and it’s a travesty on desktop.
Then if you want something a little bit complicated you have to do it all yourself.
- What if I need a date range instead of a single date? - What if I have excluded dates? (Only weekdays/only in the future/blackout dates) - What if I want to show other metadata with each day? (Like in a calendar showing each day with some metadata next to it)
Beyond “give a whatever the system thinks is a good date picker that I have no control over” the input with type date isn’t very useful.
Not on mobile. Most internet access these days is mobile.
And even select is fully customisable now if you're targeting modern browsers
really? how?
The article says browser support is limited, but good docs: https://developer.mozilla.org/en-US/docs/Learn_web_developme...
Appearance: base-select
https://developer.chrome.com/blog/a-customizable-select
The article explains how to style radio buttons with CSS however you want. What’s the problem with that?
It doesn’t.
It gives a very naive approach that doesn’t support any complex styling.
For that you need to wrap the input and additional styling elements in a ref’ed label.
Out of interest what's an example of styling that the radix/shadcn version enables that their approach doesn't? I was able to (AFAICT) replicate the radix docs example by just moving their styles around: https://codepen.io/mcintyre94/pen/pvbPVrP
In the example they are just using an empty <RadioGroup.Indicator/> for the pip as it is easy to target with a classname, but you can put any content in there instead for e.g. card-style radios (as used for complex selections, like a subscription tier).
By using radix, the underlying behaviour is compliant and identical for each of those implementations - you just change the content. Radix isn't looking at it like an html radio element, it is looking at it as a completely unstyled unique item selector.
The pseudo-element styling approach limits you to 3 layers - the container, and the 2 pseudo elements, none of which you can provide with meaningful content besides plain text. The best you can do is provide a basic styles and set background image. For anything else you need to use labels to either wrap the radio (in which case you can access state via sibling selectors) and/or ref them with "for" (in which case you cant access the state).
Wrapping it in a label is the idiomatic and correct way, and should be done even when not styling. Perhaps especially when not styling.
Putting an adjacent label is also possible, but scales poorly due to needing unique ids.
Can you give an example please? What kind of complexity are we talking about?
Any kind of nested markup: styled content, additional animation layers, etc.
Author here. Can you provide a screenshot or more detail?
I'd be happy to implement an HTML + CSS only solution and share it with you.
Thanks
But is that still less complex than what the author found?
The biggest mistake I did in 2025 was picking shadcn because it was so hyped. Saw it importing from radix anytime you enter a command. First red flag. Then I saw the radio component. Second red flag. You should see what they've done with the select component. But we were too far into the deadline for a project with running targets. So I just gave up and asked copilot to make the changes for me, and I'm not a fan of AI anything.
Funny enough we did a POC for the same project before that without shadcn and looking back, it's so much leaner and easier.
I might just break one night and redo the whole ui library with vanilla html elements.
They hype-train on all of this stuff is unreal. React+NextJS+Tailwind+ShadCN is just a mess. It's complexity piled on deeper complexity - for little gain! But suggest any of that in many circles and you'll get the standard, "skill issu bro" comebacks. Say what you want about Remix/ReactRouter 7 (there are plenty of issues to talk about there) but at least those guys _tried_ to stay closer to existing web standards. I could go on and on about the disaster of NextJS caching. I could point out RSCs being one way to solve a problem that could already be solved by loaders in other frameworks....
Tailwind was my moment of saying, "Nope, I'm gonna sit this one out". I have a few trusted friends that assure me I'm missing out. I've told them to come back to me after they've done their first major refactor. If they tell me it was a pleasant experience, I'll have another look.
In general, Tailwind and React don't match well. Why use a soup of CSS classes when React has props? If someone needs an a11y-focused base for their component library, they can start with Radix UI directly, ignoring Tailwind and Shadcn.
I have absolutely no doubt that somehow all these projects and similar ones - started with good intentions - good looking UI, implement and forget. And then, one fine day you're sitting on top of 200+ lines of code for a radio button and 7 imports and it's too hard to go back now without tearing the whole codebase apart. This is how code rot starts.
I normally share the sentiments of the article. But I am also curious, if the goal was:
- Implement the radio as the designer sent in the figma file (e.g. something like the radix demo one they're commenting on: https://www.radix-ui.com/primitives/docs/components/radio-gr...)
- Make sure it looks the exact same across all browsers
How doable is it with vanilla css? The example they gave was rendered to a black/white circle, most teams wouldn't ship that.
You can get a lot closer with only small modifications:
Here's a link to a codepen so you can see what it looks like without rendering it yourself: https://codepen.io/erikaja/pen/RNRVMyBWhere do you draw the line tho? How many kilobytes and how much future maintenance work is avoiding a potential slight visual inconsistency with a radio button worth? Is it worth to lose the x amount of people who have bad network connection?
Use this approach everywhere and the actual content of the page (you know: the stuff people came for) suffers.
All I can think about is a quote by world famous video artist Nam June Paik: When to perfect, Gott böse ("God gets mad when too perfect", the original isn't exactly a full sentence and mixes English and German).
Based on profits of many webapps, there is no line. What eng here forget is that they are oft not the targeted consumer. The hypothetically perfect website doesnt sell as well as a colorful fat choncker does. It is like fast food, not every cares about farm to table.
> 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.
Everyone always says slower and bloat and bad etc etc but it is all relative. Not everyone is an eng who scoffs at waiting another 100ms.
I do like your analogy tho. It is better. Most people want that trendy experience or fast food. Still, both exist because the market demands it be so despite how much it tilts a subset.
I worked in first level IT support and I think most people don't even consider it consciously like that. They read the news at that page. That page changes. A lot has to happen to piss them off enough to make them go. They habitually click away fifty windows a day without reading them anyways.
But people do notice if something just works on a subconscious level and that colors their perception of your project/brand/page or whatever. Even my totally tech-illiterate father actively complains about junk interfaces like the one at Temu. But he goes there for the sweet deals. I just wonder if it wouldn't work out better for them if the page was snappy and allowed a person to visit more product pages.
And one mistake you make is to think you need a megabyte of javascript to create a junk look. You can easily do that with HTML and CSS alone, including animations and all.
The way I see it the causal arrow points in the other way: successful sites tend to get bloaty, but they do no et successful because of it, but despite it.
And by bloaty I don't mean it as a problem if the page does a lot. Bloaty means you use a intricate Rube-Goldberg-machine to in the end do very basic things. Like displaying a popup, which can be done with a single line of Javascript, but is for some reason done using the amount of code that would result in a veritable, heavyweight book if printed.
Except the correct way can be just as colorful, and it takes more effort to implement the bad way.
This is objectively not true, if it were the path of least resistance would mean everyone uses the option that is fastest and best.
It takes far less effort to implement the bad way. I think people take their own skill for granted. Maybe you can but most others cannot. Maybe they will learn or maybe they are happy to put food on the table and go home at 5.
When I say "implement" I mean the big pile of code in the library. I do not believe making that entire custom mechanism was easier. There's so much to it.
Everyone else following along and merely using it I blame less, but they shouldn't have picked such a bloated library.
The bad ways effort was already paid by someone else, though.
Fun exercise! https://codepen.io/mcintyre94/pen/pvbPVrP
Everything in styles.css in that example maps to the vanilla input, so you just have to move them around a bit. Should work at least as well as theirs across browsers, because it's vanilla inputs and the same CSS.
The case is made. That's awesome.
> How doable is it with vanilla css?
Under all of the framework complexity that specific look is still achieved with CSS. In fact, you could rip out the CSS they use with very little modification and pair it with a ~five-line React component that doesn't require any third-party imports.
"Make sure it looks the exact same across all browsers" is, and always has been, fundamentally at odds with how the web is intended to work.
How well does this shadcn crap render in arachne? ladybird? netsurf? links? dillo? netscape 3? The latest version of chrome with user styles applied?
When you say "exactly the same", I assume you mean that the design only uses black and white, because some people might have black and white monitors, right? But you're also going to use amber-on-black because some people might have amber screen monitors, right? How do you plan on ensuring it looks exactly the same on a braille terminal?
Maybe you think I'm being silly. Because nobody uses monochrome monitors in 2026, right? So it's safe to ignore that and put an asterisk next to "exactly the same" (And also just forget that e-ink is a thing that exists).
(Just like how it was safe in 2006 to assume people would always have 800x600 or bigger displays, and nobody would ever come along using a screen with, say, 480×320 resolution)
What measures have you taken to ensure that your colours appear exactly the same across a bunch of different types/brands of monitors that render colours differently? Or, perhaps we should just add another asterisk next to "exactly the same"?
I could go on.
How many asterisks is acceptable before "exactly the same" isn't a thing anymore?
If "exactly the same on all browsers" is one of your goals, you are wrong. If your designer tells you that's what they want, they are wrong. If you ever tell a client that's what you're providing, you are wrong.
Particularly given that on a screen reader -- which yes is an example of a browser -- it doesn't "look like" anything at all
I think accessibility is one area where some of these components libraries can be helpful as they automatically include a11y features that might otherwise be ignored.
Displaying the same thing on every monitor to the degree that monitor allows is well-defined. The browser may not be able to show some colors and the browser may decide to display things differently on purpose, but it's perfectly reasonable to want to unambiguously express what you _want_ the browser to display.
> Displaying the same thing on every monitor to the degree that monitor allows is well-defined.
In this case the website will not appear the same on every browser. Most browsers have a zoom function that the user controls which is an accessability feature. This changes how the website renders on the page.
That falls under displaying things differently on purpose
you misspelled "asterisk"
Exactly the same when rendered by the evergreen mainstream browsers. That's perfectly doable.
Author here.
You can do pretty much any styling!
I did a basic example because that matches what Shadcn does (black/white circle) but you can customize it a lot more.
The real cost of this complexity isn't the code itself - it's onboarding. Every new dev joining the project has to understand why a radio button needs 47 lines of JSX with Radix primitives, context providers, and styled variants.
I've watched teams spend weeks just getting comfortable with component library internals before they can be productive. Meanwhile the "simpler" vanilla approach might have taken an afternoon to build but takes 20 minutes to explain.
That said, if you're building something like Figma or Linear where you genuinely need the accessibility primitives and keyboard navigation that Radix provides, the complexity pays for itself. Most CRUD apps don't need it though.
> I've watched teams spend weeks just getting comfortable with component library internals
Would a good library allow developers to ignore internals and get on with higher-level stuff?
It would. But even then, it would still bloat your html/JavaScript and tank your Lighthouse score
Bingo.
[flagged]
Im not in web development. Reading this article makes me think: is it realy neccersary to use all those complex frameworks? Isn't html/css enough? People always say "every line not written can't be a bug" but moving those lines into a library was not the idea behind the words
> Isn't html/css enough?
No, obviously. If you are writing complex web applications with state, local processing of data and asynchronous interactions it's not enough. You need javascript. If your javascript is especially complex and you desire it to be declarative, you probably need a framework. Do you need, I don't know, Tomcat in Java? Probably yes for a complex application and no for a simple proof of concept. Do you need a database? Aren't files enough? And so on.
Shadcn is a framework for developers who develop highly interactive web apps. If all you need is a static form that submits data to a web service, you probably don't need a framework (except when you need it - for example, selects are not yet fully styleable in all browsers).
Next objection usually is: do you need complex apps on the client? Can't they be reduced to a series of simple forms controlled by the server? Sometimes they can and sometimes they can't, but of course I will decide the shape, behaviour, complexity and look of the applications I build (or have others build for me), thank you very much.
That said, radio buttons have been styleable in all non-legacy browsers for at least 5-6 years, there's no excuse for rewriting them from scratch with svgs.
>If you are writing complex web applications with state, local processing of data and asynchronous interactions it's not enough.
>Next objection usually is: do you need complex apps on the client?
It's not even an objection, it's a question I ask and almost never hear a coherent answer to. The vast majority of web applications I use every day (online banking, github, forums, social media, admin interfaces of various developer tools, etc.) don't really need to be dynamic and frontend-rich. I don't care if submitting a form refreshes the page. Funnily enough, full page refresh with a full round trip with "old school websites" is often faster than dynamic SPA interaction.
I don't care that when I click "delete", the item may not disappear from the screen immediately. I don't want to see some in-between state descriptions like "Deleting..." because I know it's a lie in a distributed, eventually consistent system. Just tell me the truth: the request has been sent. I can then refresh the page and see the new current state, whatever it is.
I really don't understand this desire to make websites behave like local apps while in reality they aren't.
> it's a question I ask and almost never hear a coherent answer to.
There are a lot of coherent answers though.
One is that responding with HTML encumbers the server with brittle UI over the wire when it could instead be a simpler API server that any client can talk to.
Returning data instead of UI from the server is a clean separation of concerns.
There's nothing incoherent about that.
That's the theory. In practice, if your UI is changing a lot, the data your UI needs is also changing a lot, meaning that your data API will either have a lot of churn or you'll allow a lot of flexibility in how untrusted clients can use it, which introduces it's own pile of issues.
> I don't care that when I click "delete", the item may not disappear from the screen immediately.
The disconnect here between tech people and non-tech people is that most users do care about stuff like this.
I run a popular website as a solo project so all the feedback/complaints are routed to me, and one thing I've learned is that users really don't want websites to "feel old". Sure, they want it to be fast, but they also want all the bells and whistles like loading indicators and animations.
If you show Hacker News to someone who's not a developer, especially if they're under 30-35, their reaction to the layout and functionality will be visceral disgust. I really can't stress enough how much modern users hate the traditional plain HTML look. If you're trying to convince users to use your site and it looks or functions anything like HN, they'll get angry and close the tab within seconds to look for an alternative. Even if you've made a SPA with plenty of bells and whistles, users will still get upset if anything feels "clunky", which is often user-speak for "this component needs animations and a transition state". They don't know or care that all the fancy stuff increases the complexity of the codebase.
Every software project hits a point where the super clean abstractions the developers came up with start to clash with the messy way it's used in the real world. This is the frontend version of that. We have no choice but to give users the UX they want.
> I really don't understand this desire to make websites behave like local apps while in reality they aren't.
Since the dawn of time, humans have sought to eliminate mushy laggy UIs, such as having to wait for a full page reload whenever you click a button. I don't like SPAs either, but dunno, I don't find it particularly hard to understand how we got here.
Immediate feedback informs the visual language in order to convey meaning in a easier way to a larger public. You may know what an eventually consistent system is, but many users don't, and they want visual information abstracted to something they can understand. It's reassuring.
Also, not everything can be reduced to static forms. Charts with knobs, drag and drop interfaces, interactive diagrams are all useful visual aids that you would like to erase because... they don't conform with your naive views on how things should look like?
Most web apps are a combination of static pages, simple forms and highly interactive content though. That's what makes the choice so hard.
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.
No, you're right. Livewire, Phoenix LiveView and all the others are a couple levels removed from the browser and you have to suffer the whole indirection chain when something goes wrong. React is a good compromise - it still has indirection, but not so much, and it's much easier to use at scale than state managing and direct DOM manipulation.
A lot of frontend developers today (my experience) does't even know where to look for CSS updates or what vast amount of HTML element exists, they just know to look for frameworks and that's how they see the world. Like <input> is foreign to them, they only know of <FrameworkTextComponent>.
Sometimes you do need a framework, but the question is being asked way too seldom.
If you're not into web development, Hacker News discussions about React are really bad way to gain unbiased perspective - it's been really popular here for last few years to just hate React (usually they know nothing, e.g. anyone who claims hooks compose worse than class components). But there's a reason why React is still used the most (large ecosystem, fast development and backwards compatibility). Of course, it's easy for inexperienced developer to produce slow and buggy apps (maybe slightly easier than in other frameworks, but that's practically unquantifiable), to include unnecessary or even badly written dependencies, etc. - but it's not the tool's fault when it's being used incorrectly.
I recently tried out https://daisyui.com/ (CSS only components, depends on tailwind) and so far I really like it.
It also highlights how far browser have come with new features such as dialogs, which I always implemented with (a lot of) JavaScript in the past
This library doesn't appear to be accessible. Just looking at two random components: The Drawer (https://daisyui.com/components/drawer/) doesn't trap focus inside itself (letting you tab to the page behind the drawer while it's open). The Accordion (https://daisyui.com/components/accordion/) first example is using radio buttons as a hack to avoid Javascript, which would be very confusing to screen reader users (announcing the radio buttons to them).
This is why there's so much complexity in libraries like Radix - accessibility in the real world usually requires a lot of Javascript.
> This is why there's so much complexity in libraries like Radix - accessibility in the real world usually requires a lot of Javascript.
I agree in many scenarios, but for the two you mentioned it seems like the <dialog> and <details> elements provide accessible solutions out of the box?
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).
These comments don’t seem to have that much love for shadcn, which is unfortunate as I think it promotes good component file structure and reuse. The premise is that you could (and should) change the components yourself, as they are living in your code base and ”owned” by you, which is a radically different approach compared to other ui libraries.
The shadcn radio button in action: https://ui.shadcn.com/docs/components/radio-group
Protip: the space between the UI control and the label should be done using padding (or achieved via label nesting) so that the entire area is clickable.
(clicking between the control and the label does nothing now)Calling this a "Protip" is generous.
That the combined element has any surface area that doesn't toggle the radio setting is a straight-up bug.
It is laughable for a component this heavily refined to have such a basic usability flaw.
I'm thinking protip was sarcasm :)
Is this developed by these 10x developers I've heard about?
For some reason it's exceptionally slow for me on chromium. I click and I see it register half a second later. It also has no cursor:pointer which makes it look non-clickable. Is it expected or a bug?
Straight up doesn't even register clicks or keyboard focus for me in firefox.
Same in chrome on Android. They work if I switch to Base UI tab and back.
This interactivity definitely adds a wow effect.
Is it sarcastic or does it appear only on high frame rate devices? To me it simply feels like another radio button.
> 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
It also doesn't catch clicks between the label and the radio button.
I'm pretty sure it was a sarcastic comment.
On a recent MBP, it's indistinguishable from a vanilla radio button.
In a hilarious turn of fate, on iOS safari the first time one of the radio options is clicked after loading, the css focus style is applied, but a click is not always registered so the radio item ends up stuck in an invalid weird-looking state. I highly doubt the issue would occur if the built in radio were being used
Did they ask the original authors of Radix why it's the way it is?
Exactly this. OP fails to understand that there are reasons why it was done this way, and that someone who spent thousand of hours working on this might know something that they don't.
Well, usually, the reasons are to support every single use-case. A great selling point, but ultimately why I don’t like using things like this and importing loads of other libraries. Most of the code your importing is for some other user and any one app will probably be using a slither of the functionality.
I know if the lib is written well then you won’t be introducing unused code into your code base but you still often are left with an overly complex scaffold or other infrastructure to support all the stuff you’re not using. Just use a radio button for gods sake.
"There are reasons" is a pretty bland defense of why something was done in a bad way. You'd have to show that the reasons are valid, which I highly doubt. Also, somebody spending thousands of hours on making a worse version of something existing, isn't a good justification either. That's on the level of counting lines of code as a measure of productivity.
Perhaps this is the original PR for the Radio/RadioGroup[1].
It does seem the complexity was a deliberate decision.
[1] https://github.com/radix-ui/primitives/pull/121
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.
Bingo!
For the "requirement of being able to put any element as the radio button.", Dan Abramov tells you that this is exactly the point of React, see his comment above:
> For what it’s worth, the point of React is that you can just fix that Radio component to be an input (if that makes sense) and it’ll just be an input. [0]
[0] https://news.ycombinator.com/item?id=46690762
You’re misunderstanding. This isn’t about React, it’s the Radix UI primitives library which is being overcomplicated by it allowing you to put any element as the visual part of the radio button.
As for “the point of React” being that you can just do such and such… there’s nothing special about React there, that’s what any of these component libraries achieve (React, Vue, Svelte, &c., even basic templating systems like Handlebars a lot of the time).
Am I?
I was just quoting the React creator.
Radix UI Primitives has placed this requirement on itself. What you’re quoting amounts to “component abstractions allow you to easily throw Radix UI Primitives away” which is irrelevant.
Quite an ironic use of the word "fix" there.
Author here.
Thanks for sharing the PR. Frankly that raises more questions for me. Why do they want to wrap a label in a label? What is the actual goal here?
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
> a group of experts in simplicity and accessibility
According to who? This alone is a pretty damning case against such a claim.
I mean, that much is obvious just based on casual reading of a few articles/discussions about "modern" front-end dev.
I am 100% convinced that "Modern" front end developers are in fact, afraid of CSS and HTML. Like, "it will steal my eyeballs and look back at my face with them" scared.
Nothing else explains things like this, tailwind, JSX components, etc. Nothing. There is no explanation besides absolute morbid fear of the underlying technology - because the browser support has improved immensely but apparently they're all deathly scared of using it.
Before you tell me that I don't know what challenges these problems solve: I was primarily doing front-end development.... 20ish years ago. One of my first jobs in the space was adapting the client side code for a J2EE app - mostly this meant removing an IKEA worth of tables and using CSS - in IE6 of all fucking things. Subsequently I created reusable UI frontend components (i.e. output some HTML, maybe this little bit of corresponding JS, you'll get a usable interactive components in a browser) for two different organisations.
I have said it before and I'll say it again. I think JavaScript developers heard about (or saw over someone's shoulder) how J2EE guys had ant/etc build toolchains, and had abstraction like FactoryFactoryImplementationFactoryBuilderFactory and said HEY THAT LOOKS COOL, and if it's harder to understand they can't fire me!!
It's like NIH syndrome but for an entire community of people whose primary goal is chasing the shiny, followed closely by resume padding.
well said!
Okay, what exactly are those reasons?
Why does it need so much complexity to draw a radio button that doesn't look all that different to the normal one you'd get with a perfectly ordinary <input> field, except it takes around ten seconds to draw and then doesn't work properly?
In 2020, radio buttons weren't easily stylable in all mainstream evergreen browsers. That's usually the case why some components are over engineered. Of course they should have simplified them when all browsers fell in line, but tech debt is hard.
They probably don't know Chesterton's fence [1].
[1] https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...
Author here: I tried to find answers in their docs but they don't provide any context. I expected to find an explanation of why to use their solution there but did not.
How would you suggest I reach out?
So for a React developer who doesn't want to include Shadcn/Radix, but also doesn't have time to build every component/a11y/compat/edge cases from scratch, what are the better alternatives?
Would be nice to list them here so developers can know a midpoint between DIY <-> Shadcn/Radix
One midpoint is traditional css frameworks like https://getbootstrap.com/.
Not as powerful, and you don't get this sweet 3rd-party pluggable component catalog, but it's much simpler and it's stable: there's no constantly evolving ecosystem.
Shadcn ecosystem might have calmed down by now, but when I used it years ago, the layers on top of it were super unstable, and I was annoyed every time I have to work on those projects until I got Opus 4.5 to refactor out of them.
https://react-aria.adobe.com is the new Radix, it provides unstyled components with a heavy focus on accessibility and quality. https://github.com/heroui-inc/heroui is the new Shadcn.
There are many options, each with their own pros and cons. Also, you may or may not like their default styling and/or styling options. There is no one size fits all. Having said that, we maintain an incomplete list of popular UI libraries here:
https://frontaid.ch/web/ui/libraries.html
I'd never heard of Ark UI before, and as a svelte and solidjs dabbler it's great it supports multiple frameworks. Thanks for this site!
One thing to keep in mind regarding a11y, the semantic web is accessible by default. It's once you break away from establish norms do things become harder or tricky, but if you can stick to using actual semantic elements and not div-soup you will cover 90% of your use cases (assuming your use case isn't relying on just the canvas element).
You don't want to build your own components but you also don't want to use pre-made components? At some point you have to pick one. If you really want a midpoint, it's literally Radix: behaviours are done, stylings are up to you
I heard that a more modern alternative to radix is react-aria: https://react-aria.adobe.com/
Claude Code can whip this stuff together quickly if you specify those constraints and are knowledgeable enough to know what’s possible with modern CSS, etc.
just discovered this link: https://designsystems.surf/design-systems
It has to be this way because we (the collective we) refuse to agree on adding proper UI primitives to the web.
We’re like 20+ years into web apps being a big thing and there’s still nothing like what’s offered in OS-native frameworks like Swift.
So anybody building a web app has to recreate SwiftUI in the browser every time via various bloated hacks (basically what Shadcn is).
If we could just agree on adding non-terrible cross-browser primitives for multiselect, popovers, modals, proper radio buttons, tabs, etc to the HTML spec and allow extensive CSS styling on every part of the element we could avoid these massive UI frameworks.
Radio buttons are in html spec for over 30 years and they allow extensive CSS styling on every part of the element.
> So anybody building a web app...
... beyond a specific size. This important distinction might transform "anybody" into "10%" or "5%" or "0.001%"—who knows, I'm still trying to figure this out!
What is it about multiselect or radio buttons that you feel is lacking in the current Web platform?
Native radios are notoriously hard to style consistently across browsers. You can do it with appearance: none, pseudo-elements, etc., but:
- You re-implement focus rings, checked states, hover, disabled, error states.
- You end up bloating your stylesheet incomprehensibly
- Cross-browser differences (especially Safari) still leak through.
- Controlled components, validation layers, animations/transitions, rich layouts are annoying and break accessibility
- Turning native radios into radio cards for example breaks accessibility and keyboard navigation
- Rows with icons, badges, subtext, etc. between the radio and label is a huge issue
Hence why everybody uses Shadcn instead.
I think this is the equivalent of the radix demo (which has better styling than the shadcn one) in plain html/css: https://codepen.io/mcintyre94/pen/pvbPVrP
Copied styles from the radix docs: https://www.radix-ui.com/primitives/docs/components/radio-gr...
15 years ago, Enterprise FizzBuzz [1] was supposed to be satire. These days, it's not quite complex enough to capture "modern" web dev.
[1] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
Meanwhile the Java landscape that was lampooning got a lot better, and is pretty nice to work in and get shit done.
Well Shadcn gives you more freedom to fix stuff like this and rewrite how you want the component to work and look, since everything lives in your own code base. In a regular component lib it would be less likely that you'd think about this complexity, since it would be "hidden" away in node_modules or even transpiled and minified.
> everything lives in your own code base
A common misconception.
In reality Shadcn is a thin wrapper around libraries such as Radix, recharts, etc. The article says as much.
Sure, but if you wanted to change it to just use a radio input you could. Shadcn gives you a baseline.
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.
Sure, that's true. I oversimplified.
I still don't understand why someone would choose to essentially clone some code vs import a library. Suddenly you increase your maintenance burden, lose updates, etc. I've had no problems at all with UI libraries like Mantine. If you follow this logic, why not just clone all your npm repos and build from source. Ultimate control, right? Please help me understand the benefits here, because I tried out shadcn and wasn't into it
It's for projects that are design-first, where you'll have to implement your own component library that matches the design.
Incidentally, radio buttons are a (sadly) forgotten art and are neglected in modern browsers. There are many issues with them, which is why people reimplement them on their own.
Can you provide more details about the issues?
Not really, because I no longer remember. I only remember bugs and frustration. But I looked at my code quickly and found this:
;; Let's render radio buttons ourselves. Because of bugs in React and Chrome, radio buttons mysteriously stop working.
;; https://stackoverflow.com/questions/48423061/radio-buttons-n...
;; https://github.com/facebook/react/issues/3446
followed by my own implementation of radio buttons, followed by:
;; Original implementation, to be used when radio buttons actually work:
followed by an implementation using an input of type radio, commented out.
Reading through the threads that sounds like a React bug not a browser bug
Well I want to give shadcn some credit, building a comprehensive open-source UI toolkit, on your own basically, isn't as easy as one would think. Yeah you can use native elements except for some tiny edge case with say Safari and then you go deeper into the rabbit hole, until you decide you'll just customize everything. But at this point you probably have lost a lot of time and sanity already.
I'd put the blame on React and poor Web APIs in this case. Both are way too complicated for mere mortals to understand fully, and even simplest things like maintaining 100% container height through nested elements, can become a ridiculous time-sink for something completely unrelated to what is your main objective.
> on your own basically
The base (Radix UI) was built by a team on WorkOS paycheck.
Not true. Radix was built by a team on a Modulz paycheck, then acquired and (more or less) abandoned by WorkOS.
Your (implicit) point that Shadcn didn't develop the underlying component library still stands.
This is only "overcomplex" from a naive point of view.
Radio buttons, as with all UI controls, have tremendous inherent complexity, which comes to light once requirements ask for something beyond the blessed happy path of the default browser button. Pixel perfect styling, animations, focus behaviors, interactions with external state, componentized branding to fit in with companies' ecosystems, etc.
The baseline <input> paradigm struggles to provide the tools needed to adequately handle this complexity, even today, after many decades of web development.
And of course --- you can also argue that we should all just use the default browser button and everything should be solved. But this is also suboptimal, as it's clear from research that users prefer custom buttons if they provide more "features" than the defaults.
> it's clear from research that users prefer custom buttons if they provide more "features" than the defaults.
Hate to be asking for a "source", but what research? And what "features" can a radio button even have? You click it and it's selected. I suppose accessibility can be considered "features", but I'm strongly suspecting that the overcomplex button has worse accessibility.
> all UI controls, have tremendous inherent complexity
Well, this is true in a sense, but it's not exactly a good argument for re-implementing all that complexity in JS / HTML, instead of simply using the browser's implementation that's written in a real language.
>I suppose accessibility can be considered "features", but I'm strongly suspecting that the overcomplex button has worse accessibility.
Accessibility is incredibly hard to get right, particularly managing screen reader announcements, focus management and form validation. I recently had to build a website that met WCAG 2.1 requirements and it was made significantly easier by using React Aria (https://react-aria.adobe.com/) which is a similarly complex headless component library. To get an idea of the work that goes into making an accessible component, see their blog post about making a combo box where they test 4 different screen readers x 4 different browsers: https://react-aria.adobe.com/blog/building-a-combobox
(I haven't used Radix so I'm unsure how well they do a11y)
Agree, this kind of complexity is there for a reason. I would rather have a complex component that handles all the cases within its usage in the codebase over having a bunch of little hacks/changes in the usage. It's far easier to maintain one complex component than many different usages of that component.
And you don't have to use such a complex component library if you don't need it. For small codebases it often is overkill. But for large codebases it's a massively worthwhile investment.
But handling edge cases is a self-inflicted wound, because you have decided to re-implement something that already has an extremely well tested specification and implementation in the browser. This is almost always a mistake.
Author here. I've implemented all of these with the native radio button and CSS:
> Pixel perfect styling, animations, focus behaviors, interactions with external state, componentized branding to fit in with companies' ecosystems, etc.
Do you have a more specific example of something you've struggled with recently?
I am pretty new to frontend development (but have 20 years of backend)
I assumed I would need to use one of these libraries at some point. But, perhaps since I am using Svelte instead of React, whenever I ask AI to do something, then since I don't already use a component lib it just spits out the HTML/CSS/TS to do the job from scratch (or, depending on how you look at it, output the mean component from its training data).
I have to point out it should organize the code and give the component a dedicated Svelte file (sure I could fix AGENTS md to do that).
I think with AI the usecase for these libraries is much lower. If there is anything complex you need AI can build it in some seconds specifically tailored for you, so..
I've been dabbling in backend and frontend stuff for about 25 years now, but for the past 15 years or so I haven't really had to do any webby stuff for work (and that's kind of how I like it).
Recently I've needed to put together a few things as "proof of concept" for things like internal directories and catalogues, and it's one of those "How Hard Can It Possibly Be" situations where we've had folk prevaricating for months with outline drawings and sketches and mockups.
So I knocked together a backend for it in Django, which worked okay, and then styled up the raw template with MinCSS[1], and then to do stuff like "find-as-you-type" and other "magical dynamic page" things I used HTMX[2] which has been discussed here endlessly.
No need for AI sloppiness. Just write some code, look at some examples, stick in some styles, and away you go.
[1] https://mincss.com/examples.html
[2] https://htmx.org/
I've used HTMX-like approaches a lot for other apps and I've been pretty frontend-averse, but this time I'm doing something similar to a drawing program with lots of d3 and SVG etc, very much the "real usecase" for SPA. So I feel HTMX doesn't apply to this specific usecase.
A html forms based radio button is worse than a complex - but standard - shadcn radio button many ways that matter in the real world.
Why does no one do the simpler thing? Because there’s no extra value to it, and it in fact has negative value because then the team has to write and understand it and the rationale for the departure from just using the same component library everywhere.
“Only a few kb of javascript” may as well ZERO javascript, and because of that it’s not even close to the top thing to optimize on your favorite site.
So, you engineered a non-standard radio button that is different to the rest which all use shading?? Why weren’t you building features that you know.. make money?
How's using a custom library any way close to "standard"? How about the actual HTML standards? The whole reason you'd use "shadcn" is that customizing the actual HTML radio button isn't enough for you. Otherwise, if you just want a default-looking button, here you go:
If your team can't understand that, how are they going to understand a few KB of JS? Or maybe they're not supposed to understand it, but how can you then guarantee to your customers there isn't a crypto miner or tracker or something in that? Or perhaps you care more about "making money" than protecting your customers from such things?You should not look at the button in isolation. The library is likely used to do other things vanilla HTML cannot do, but instead of maintaining multiple code, they just use the library to implement everything.
The library has in essence became an interface for developers to build for.
Interestingly Radix has both `Radio Group` and `Radio` — The simple `Radio` input does use `<input type="radio">` but the `Radio Group` does not. Git history does not show _why_ though.
They never figured how the exclusive choice works in <input type="radio" name="group">
> Web development is hard.
no it's not.
you all make it hard by bloating your sites with Jenga tower abstractions for styling, needlessly load content dynamically via Jenga tower javascript libraries that pulls complexity into frontend and most of the time puts unnecessary load on the content generator ("backend") too. I don't know a lof of sites where that actually makes sense, as web === text.
When html5 came about, along with CSS3, it was such a big leaf in terms of ease of use and accessibility. I argue that what most websites do to my taste nowadays can be achieved by early-stage html5+css3+ a few svg.
Nowadays on about 50% of websites it have to * enable 3rd-party JS just to get the text * enable massive amounts of 3rd-party JS to get the images * enable remote fonts just to grok your pathetic icon-only menu or even spot the 'search' feature (it's not even a 'button' most of the time) because you didn't care to use a proper <img> or <svg>
I don't think it's hard, it's harder than people think it's going to be. So they get frustrated and start abstracting away, ignoring history and hoping their fresh approach will finally make this thing easy.
I see this with a bunch of python libraries too.
I imagine for some usecase, they are valuable. However, when reading advice on the internet you get comments from people that tell you what technology they used without consideration of the overhead required to use this technology and the problem at hand.
There has to be a reason for picking button instead of input type="radio", right?
Yep, radio buttons weren't easily stylable in all evergreen browsers back on 2020.
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.
Ok, I'll bite. I've been coding for almost 25 years so have seen various things come and go, so hopefully have a bit of capital in the bank.
Don't get me wrong, a HTML5 radio button is a beautiful thing, and sometimes React is a hammer and everything is a nail.
However, I think something that OP doesn't mention super explicitly in their post is the codebase they are working on is probably a React codebase. React is a great abstraction for building UIs. I've built a ton of them and the complexity only needs to go above a certain degree until you need a way more descriptive way of explaining your UI based upon other state, instead of trying to wire a load of DOM elements together.
If you are already using the React ecosystem, for things like form validation (again, possible with HTML5 but as soon as the complexity cranks or you can't use the server - you probably need a library), then using something like Radix is a great choice, OP even mentions how although it's not technically a visible radio button that is shipped to the DOM, it acts like one for a11y reasons, and this is due in part because it's very, very easy to write inaccessible HTML. And ShadCN is pre-made components on top of that, and they all work pretty well together.
Nothing is perfect, but even in my "old man yells at cloud" era, I personally don't think this one is worth yelling at the cloud for.
As someone who has never really dived into React etc., my main question is "where is the line?"
I'm sure you'll agree that React is overkill for some applications and, for the sake of this discussion, I'll agree that it's beneficial for applications beyond a certain complexity.
But where exactly (or even, roughly) does that line lie? A basic CRUD app? Surely not. A calculator? I'm guessing "no". Bluesky? Maybe/probably.
Bluesky absolutely yes, something like React makes sense.
I think it depends on a few things but the two big ones in my mind are:
1) Interactivity. How rich do you need/want the interactivity to be? As this scales up the benefit of React also increases.
Of course you can get highly interactive vanilla HTML sites but it’s much easier to achieve with React.
2) Statefulness. The more UI state you have the more a tool like React helps you. Again, it’s not doing anything you cannot do with vanilla HTML/JS but the level of difficulty comparatively is night and day.
On top of that, React is widely adopted. The tooling is fantastic, the community is strong, the job prospects are very good, and if you’re hiring the talent pool for React is vast.
2 pieces of UI in different parts of the page that depend on the same data - that's the line (also matches the initial goal of React - sync FB chat widgets).
Note on the fact that this would add JS that needs to be loaded to see the page. No, because similar smart people created server-side rendering, adding another layer of complexity.
How do you implement this keyboard navigation with SSR (if you use buttons)?
https://www.radix-ui.com/primitives/docs/components/radio-gr...
I can’t tell if this is sarcasm or not! Radio buttons support keyboard navigation without JS.
That's what I mean: if you reimplement it, you need client-side JS to support keyboard navigation.
It needs JS to be interactive unlike the native radio button
I use shadcn/ui for side projects, mostly coding with agents.
Good to have a base design system for building products.
Are there any alternatives? Coded systems, not just UI components.
I much prefer React Aria's components. Yes fuck Adobe but take their RadioGroup for example: https://react-aria.adobe.com/RadioGroup Much better than shadcn's in terms of deps and LOC, and it uses an input. All of their components are built for accessibility first.
Thanks, no love for Adobe but React Aria seems good. Saved, will look in to it.
Yup, agents LOVE Tailwind+ShadCN. Even when I've explicitly told them not to use it, it still creeps in. There's a lot of prior art out on GitHub and LLMs can't help themselves. FWIW, the result does tend to look nice enough. For a POC I can't complain. If I'm really going to roll up my sleeves and get into the code though? I don't think I'd enjoy all of it.
As I was reading this text, my hands started sweating, my head began to ache, and I felt the anguish and terror of reliving a traumatic experience all over again. I can’t even count how many times I’ve been stuck in a project that’s already behind schedule, where the client (I’m a freelancer, working directly with the person who has the requirement) throws in a ‘simple’ request like: change the style of that radio button so it matches this other one. The problem isn’t that—because of reasons like the ones explained in the article—I end up spending hours and hours on what looks like a trivial task. The real nightmare is when the client asks me: ‘Why are you taking so long to do something so dumb?’ It’s a nightmare. That’s why I ran away from React, because of this and countless similar situations, and went back to WordPress, where the world is so much simpler, the clients are happy, and so am I.
The dropdown systems are something else, I spent almost as much time on that as I did on the rest of the interface when I tried Shadcn.
in early react days, and slightly before, the fun part was bidirectional binding and computed reactive values... but i admit that now it's become a big jungle just to recreate everything, plus it's rarely stable, new ui libs pop every year (shadcn is now rebasing on top of base ui i believe) .. seems wasteful now
Yup. Unfortunately common I think - not just with UI components. Occam's razor is sometimes only for others.
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.
> Look at it. It's beautiful.
Quite right too … I’m choosing HTMX over React for just that.
This is the reason I absolutely hate shadcn. The number of dependencies and files you introduce for trivial components is insane. Even tiny little divs are their own component for no good reason. I genuinely don’t understand how front-end developers accept this level of needless complexity.
Shoutout to Basecoat UI[1], so implementing the same components using Tailwind and minimal JS. That's what I am preferring to use these days.
[1]: https://basecoatui.com/
> I genuinely don’t understand how front-end developers accept this level of needless complexity.
in my anecdotal experience as a bit of an old fogey with a greying beard, the enthusiastic juniors come along, watch a video by some YouTube guru (who makes videos about code for a living instead of making actual software) proselytizing about whatever the trendy new library is, and they assume that it's just what everyone uses and don't question it. It's not uncommon for them to be unaware that the vanilla elements even exist at times, such is the pervasiveness of React bloat.
Please name some names of these performative developer/engineers. I want to know how many are on my bingo card. Ill start, something imegen and tnumber geegee.
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.
Another shoutout to Basecoat. Easy to use. Makes your website look nice. Works with any/no framework.
I'd never heard of basecoat but it looks great. IMO this is what Tailwind UI should have been. It was utter stupidity that they forced you to use their preferred shiny new JS framework of the week for UI components.
> I genuinely don’t understand how front-end developers accept this level of needless complexity.
I call it 'Shiny Object Syndrome' - Frontend devs tend to love the latest new JS frameworks for some reason. The idea of something being long running, tried and tested and stable for 5-10 years is totally foreign to many FE devs.
Despite its age JS and its ecosystem have just never matured into a stable set of reliable, repeatable frameworks and libraries.
This looks awesome.
Shadcn is an anti-pattern.
I evaluated a LOT of UI toolkits for React. The premise is always great - I want to save time by not having to build a UI toolkit for my application, so I'll use a great one off the shelf. But what I found was that the evaluation falls into three questions:
1. Does it look nice and professional?
2. Will it be here tomorrow?
3. How does it feel to work with - what does my instinct say?
The first question is easy. I either like it or not. I can't answer the second one with certainty. Nobody can. I can only guess. Sometimes I'm wrong.
The third one is instinct driven. If the ergonomics feel off, my instinct will tell me. If something is not right, I'll feel it. I might not always be able to explain it, but I'll know it's a go or no go. ShadCDN came with big praise, but my instinct said a big Nope. It's stuff like that that make me think that, maybe, we add complexity because we get bored with the "boring" tech.
So? Did you open a PR for shadcdn or Radix? Did you throw out the shadcdn code rendering the radio button from your codebase? Did you ensure it doesn't come back the next version?
Otherwise you haven't engineered anything, you've barely outlined the concept of a plan.
Two lessons here: The complexity exists for a reason. Try to understand where it comes from.
Second: Thinking "it could be done this way, I think" is barely 1% of really outlining a solution, implementing it and convincing others to use it. The latter is the hard part, but actually changes things outside of your head..
That's why I never touch web frontend dev.
And then you realize this paradigm plagues even desktop applications through electron and the like. Enshittification knows no borders or limits.
we've new dev's been trained that this is normal - a.i putting out slop / trained on this cz its the default
yeah sad state of affairs
[dead]
[dead]
[flagged]
Go on, then. Point them out.
As it is, you've joined the ranks of multiple others commenters who sound like cargo cultists, attacking OP for not understanding frontend dev without actually pointing out any issues in their writing. If it's easy to point out, then surely you can show how easy it is.
If all you have to contribute is being insulting, you don't have to comment.
What makes you think reading the code makes someone less curious than relying on someone else’s made up answer about it.
and people complain about AI code?
Shadcn most likely contains a lot of LLM generated code. Isn't it owned by Vercel these days?
> Why would you want to do this?
Have you tried completely customising a radio button with CSS? Feel free to demonstrate a heavily customised radio button style where you don’t hide the native appearance.
There's literally an example of that in the post.
> where you don’t hide the native appearance
What do you mean by this? Seems like an arbitrary requirement to set. Could you show an actual example of how this overengineered style is easier to customize?
The pseudo element solution alone is extremely limiting in its ability to be customised. For more complex customisation you will need to decorate with additional elements within a ref’ed label - and then you are effectively back to what radix does.
> 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
Yes, several times. I've been specializing in front-end dev for over a decade.
I shared a simple example because Shadcn has a simple design.
You do often hide the native appearance if you need something complex, but doing that via CSS is still much simpler than a bunch of JS and a third party dependency.
If you have a specific design in mind I can show you how to do it.
I almost had the same reaction tbh! Like I remember inline-grid and place-content for example was not at all supported css, it would've been a nightmare to do, but modern browsers css support is way more powerful than my mental model of them still is. So it's time to update that mental model.