It’s getting tiring to hear at this point, but the Claude voice comes through clearly in this post, and it’s a little off-putting. If even an important product release doesn’t warrant full human attention, where will we draw the line?
Serious question, why does it matter to you? Maybe they wrote a draft and reviewed Claude's writing before publishing. Why are we trying to "call out" when AI is assisting us in our work? This is an open source project, not a F500 company. They have limited resources, maybe English isn't their first language.
Because it implies that the users of the AI don't understand that it's output is usually horseshit littered with enough good info to make it sound correct
For boring applications - do people prefer the copy paste approach of shadcn instead of a traditional ui library like mantine?
The copy paste approach may be easily modifiable but creates new problems - ie now there is an upgrade ai agent for something that should just be ticking up a version number.
Ticking up a version number is all fine and good until it requires a dependency upgrade you aren’t ready for. If for example you wanted to upgrade MUI from 4 to 5, you’d find react 17 wasn’t supported. And if you weren’t ready or able to upgrade react, then you’d just be stuck using a UI library going more out of date by the day.
With shadcn / the copy paste format, you’ll almost never see that happen. The button shadcn provides for example is just css / tailwind. And if you did ever for some reason want to bring in a dependency for your button component you wouldn’t have to consider its effect on your other UI elements. The rest of your components can live independently (for the most part)
We have customized UI components we got from shadcn and now some use radix and some use base ui, and some have other dependencies or no dependencies at all. Properly tree shaken this is not a big deal at all and we can upgrade components individually as needed.
For boring applications this may be a bit much. But even then if you wait too long and mantine falls behind more than a couple versions, who knows how easy it would be to get your whole project up to date.
I’m leaning towards vendoring for all my new projects.
Grabbing an off-the-shelf UI library is easy in the short term, but it’s usually overcomplicated, implements things I won’t ever need, is hard to tweak if/when you want to distinguish your app from the thousand others using the same library, and when you do decide to upgrade it, all your tweaks break in subtle ways.
What I think would be the best approach is building your own UI library. You own it, you get to reuse it across different projects and maintain the same visual style (if desired), and you add features when you need them.
It's one more thing to maintain, and it's also difficult to push back on things. If you use off the shelf components it's much easier to say to designers and managers that a UX pattern is not available or not valid. You can point to the mature well known community owned UI library you use and make it authoritative. It's harder to do it if you build your own, suddenly each designer and developer is throwing things in there, adding features etc. It's also difficult to agree on the structure, so the components are well thought out, flexible, but also not so flexible to lose semantics. It's not an easy job, do you use slots, composition, rendering callbacks, there are too many decisions and you spend time building the UI library instead of actually shipping features.
> that should just be ticking up a version number.
Ah, but it's rarely just that in many systems. It can only be just that if the component library does exactly what you want. Unfortunately, it happens quite often that component doesn't entirely do what's needed.
People bolt on extra CSS to the components all the time. Two lines of CSS is very tempting if the alternatives are a few hours of work at least. But those two lines need to be verified against every new feature of the component library.
Do those two line fixes a lot, and upgrading becomes A Project.
Mantine is brilliant, I can build anything in it quickly and then extend it or completely customize the theme or individual components, but there is a learning curve. I would not call it a giant learning curve.
I love Mantine. It’s easy to use, full featured with lots of components and helpers, and yet if you need to, you can use it headless and customise it too (I’ve never bothered though; I did add my own additional spacing/sizing options via the theme support though)
If you don't need to make any changes, it should be very simple to just upgrade by replacing the components. And if you need to make changes then well it's not gonna work with a traditional UI library.
> now there is an upgrade ai agent for something that should just be ticking up a version number.
If a component as basic as a button or a list view ever requires an “upgrade”, something is fundamentally wrong to begin with. HTML5, ARIA, etc. aren’t cutting edge technologies that the ecosystem still needs time to figure out. This should be pull once and forget.
Vendoring your components gives you the best of both worlds. You get a full component library but retain the ability to modify them as you want.
Your AI agent claim doesn't make any sense either. When upgrading normally your component just gets rewritten on disk. When switching from radix to base ui, a more comprehensive approach is needed.
I have used and mostly like Shadcn, and yet their Radix-based radio button was a bit much, as are other choices, where similarly overblown solutions were used.
How about leveraging llms to produce deterministic codemods? You can then iterate on this by running the codemods and using other deterministic guardrails, feeding the results back into the llm to improve the codemods?
I think the two complement each other perfectly and will continue to do so. I keep writing AGENTS.md files for soft rules and custom linter rules for hard ones which IMO is the best of both worlds.
I'm building Lily Design System as a response to Shadcn and similar systems not yet being available directly for multiple stacks including Svelte, Angular, Nunchucks. It's all free open source. If you want to send me your feedback, suggestions, etc. I can easily add things to Lily.
It uses Zag js for its primitives which is framework agonistic as opposed to Radix or Base UI. Shadcn is only for React. If you use Solid.js for example, Skeleton is an option for your design system.
That's great. Started using Base UI early on via 9ui [0] and found the primitives very pleasant to work with, especially if one wants to compose more complex components from other Base UI components. Maybe Shad can reduce some of the dependencies they rely on now.
Base UI is more low-level, a lot less opinionated and doesn’t force you into certain layouts. This of course makes it more complex to use, but that doesn’t matter if you’re using shadcn components because they’re doing that work for you.
So essentially they look and operate the same as Radix components at the shadcn level but you have low-level control later on should you need it.
I tried to use baseUI and gave up. Forms are a bit different and I can't no longer copy/paste similar form code between projects (unless I migrate everything to baseUI).
Personally I'd prefer React Aria; I don't have the patience to try understand why suddenly everyone is rushing to adopt Base UI instead of Radix which itself was once suddenly the thing everyone rushed to instead of Stitches.
Having a library not in anyway related to that to me feels like a big pro.
I have found React Aria to be very good. I really like how its a set of hooks, a set of premade components using said hooks, and I like how you can choose bits of either approach for your own components. Some of the hooks are very useful.
The copy paste approach may be easily modifiable but creates new problems - ie now there is an upgrade ai agent for something that should just be ticking up a version number.
With shadcn / the copy paste format, you’ll almost never see that happen. The button shadcn provides for example is just css / tailwind. And if you did ever for some reason want to bring in a dependency for your button component you wouldn’t have to consider its effect on your other UI elements. The rest of your components can live independently (for the most part)
We have customized UI components we got from shadcn and now some use radix and some use base ui, and some have other dependencies or no dependencies at all. Properly tree shaken this is not a big deal at all and we can upgrade components individually as needed.
For boring applications this may be a bit much. But even then if you wait too long and mantine falls behind more than a couple versions, who knows how easy it would be to get your whole project up to date.
Grabbing an off-the-shelf UI library is easy in the short term, but it’s usually overcomplicated, implements things I won’t ever need, is hard to tweak if/when you want to distinguish your app from the thousand others using the same library, and when you do decide to upgrade it, all your tweaks break in subtle ways.
What I think would be the best approach is building your own UI library. You own it, you get to reuse it across different projects and maintain the same visual style (if desired), and you add features when you need them.
It's one more thing to maintain, and it's also difficult to push back on things. If you use off the shelf components it's much easier to say to designers and managers that a UX pattern is not available or not valid. You can point to the mature well known community owned UI library you use and make it authoritative. It's harder to do it if you build your own, suddenly each designer and developer is throwing things in there, adding features etc. It's also difficult to agree on the structure, so the components are well thought out, flexible, but also not so flexible to lose semantics. It's not an easy job, do you use slots, composition, rendering callbacks, there are too many decisions and you spend time building the UI library instead of actually shipping features.
Ah, but it's rarely just that in many systems. It can only be just that if the component library does exactly what you want. Unfortunately, it happens quite often that component doesn't entirely do what's needed.
People bolt on extra CSS to the components all the time. Two lines of CSS is very tempting if the alternatives are a few hours of work at least. But those two lines need to be verified against every new feature of the component library.
Do those two line fixes a lot, and upgrading becomes A Project.
If a component as basic as a button or a list view ever requires an “upgrade”, something is fundamentally wrong to begin with. HTML5, ARIA, etc. aren’t cutting edge technologies that the ecosystem still needs time to figure out. This should be pull once and forget.
Vendoring your components gives you the best of both worlds. You get a full component library but retain the ability to modify them as you want.
Your AI agent claim doesn't make any sense either. When upgrading normally your component just gets rewritten on disk. When switching from radix to base ui, a more comprehensive approach is needed.
When You're Ready to Migrate
You don't need to migrate. But if you want to, we built a skill for it:
pnpm dlx skills add shadcn/ui
Then ask your coding agent:
migrate accordion to base-ui
https://news.ycombinator.com/item?id=46688971
I’m trying out Ark UI on a side project. They do have some genuinely useful components, like tags input: https://ark-ui.com/docs/components/tags-input
They have a tabs/“segment group” component with a nice animated active element indicator which would probably be tricky to implement: https://ark-ui.com/docs/components/segment-group
And then they also have stuff like overcomplicated “click to copy” button and a <details> reimplementation: https://ark-ui.com/docs/components/clipboard, https://ark-ui.com/docs/components/collapsible
All with a verbose markup that renders as a div soup.
Even if they’re more deterministic, I wonder if the days of codemods are numbered.
PrimeNG had a licensing change recently and I'm looking at a suitable alternatives for a fresh project.
Both attempts [1] to surface this on HN failed but if you are using a PrimeTek component library you need to be aware of this change.
PrimeNG, PrimeReact, and PrimeVue are all going fully closed source and ongoing licencing will be $800 per developer seat in 2027. [2]
The previous repos have been archived. [3]
PrimeFaces remains open source but it's now developed and maintained by independent volunteer developers who are not employees of PrimeTek.
[1]: https://hn.algolia.com/?q=The+Next+Chapter+of+PrimeTek
[2]: https://primeui.dev/nextchapter
[3]: https://github.com/primefaces/primeng
https://lilydesignsystem.github.io
[0] https://www.9ui.dev
All of these component libraries look the same.
So essentially they look and operate the same as Radix components at the shadcn level but you have low-level control later on should you need it.
Trying to decide between the two atm.
Having a library not in anyway related to that to me feels like a big pro.
I have found React Aria to be very good. I really like how its a set of hooks, a set of premade components using said hooks, and I like how you can choose bits of either approach for your own components. Some of the hooks are very useful.
It even looks incredible when building desktop apps. We used it to build DB Pro [1] and the DB Pro website, and everyone compliments us on our design.
I see it becoming the defacto choice for UIs especially when building with agents.
[1] https://dbpro.app