4 ms·

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 e

by chvid 3mo ago

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.

sreekanth850 3mo ago
Bigger issue ,every app that use shadcn use 100% same. I still have to figure how people differentiate their brand using shadcn.
sevenzero 3mo ago
I highly prefer a copy and paste approach. The less npm installs the better.
IceDane 3mo ago
Martine just straight up sucks. 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.
- chvid 3mo ago
  The ai agent “claim” is from the webpage that is linked to: 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
  - addandsubtract 3mo ago
    This is just an ongoing trend to address coding agents first in documentation, and people / manual methods second.
- Griffinsauce 3mo ago
  > Mantine just straight up sucks. > Mantine is brilliant. Thanks internet.
- whynotisay 3mo ago
  Had to scroll way too far to find this - mantine sucks so much I hate it and hope no manager ever forces it on anyone ever again
Exoristos 3mo ago
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.
- dkersten 3mo ago
  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)
  - elxr 3mo ago
    Any direct comparisons to base UI? I've been pretty satisfied with base UI so far, but my usage has been very basic so I'm open to switching if Mantine offers something better.
    - Exoristos 3mo ago
      They have very similar concepts and goals, only Mantine is much more full-featured (without being messy and while maintaining flexibility). I'd suggest if you hand-craft most of your site, but need a well-thought-out complex widget, use Base UI -- but bear in mind Mantine also offers unstyled components.
- stevepotter 3mo ago
  Love love love mantine.
notpushkin 3mo ago
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.
- dsego 3mo ago
  > building your own UI library 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.
  - threetonesun 3mo ago
    Odd to me when I read stuff like this but also posts about how AI is making everything trivial. Surely a thing that almost every company did in the early 2000s should not be hard today, but of course today you can’t just write HTML + CSS, you must consider every front end framework introduced in the last decade.
    - dsego 3mo ago
      I remember the 2000s web, it was primitive. It's not hard to combine some html and css, it is hard to support more complex dynamic actions and components, all with consistent theming and behaviors and have them composable and reusable.
victorbjorklund 3mo ago
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.
rzmmm 3mo ago
I don't like the copy paste. Rather use lower-level abstractions for the UI if I know I have to make modifications.
lucumo 3mo ago
> 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.
p-e-w 3mo ago
> 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.
chrismsimpson 3mo ago
As grug, I prefer the paste approach
slowjames 3mo ago
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.
- c-hendricks 3mo ago
  MUI v5 absolutely supported React 17 though. Unless you're thinking of React 16, which hadn't had updates for almost a year when MUI v5 released.
  - slowjames 3mo ago
    Oh yes you are right. My bad. I got my dependencies backwards. We were using react 17 and wanted to upgrade to 18, but first we had to migrate an entire app on MUI v4 to v5 first since v4 was not supported by 18. And it was an upgrade full of breaking changes. My point still stands that having a UI library like MUI deeply ingrained into your app can cause dependency and other issues like this. The speed you get upfront can bite you if you don’t plan carefully. Sure there are steps we could have taken to avoid such a mess. But that’s not how things often work out.
    - c-hendricks 3mo ago
      Still not sure if the alternative of vendoring like Shadcn, where a migration like this requires a black box probability machine to do the migration for you is any better.
Griffinsauce 3mo ago
> that should just be ticking up a version imber. Is it ever that simple?
stevepotter 3mo ago
I never understood the copy paste thing. Shadcn just reeks of a fad, and even after doing copy paste and trying it, I didn’t see what the big deal was. But enjoy it, y’all. One of the benefits of AI is that HN isn’t clogged with talk of JavaScript frameworks as much
- satvikpendem 3mo ago
  You own the code, not the library, hence you can fix whatever you need instead of relying on them to fix it.
dbbk 3mo ago
The copy paste approach is just a plain bad idea, I am not sure why this doesn't get more criticism
matt-attack 3mo ago
Can you explain what copy paste means here? I use Material UI for all my AI coded applications. Am I doing something wrong? What difference would Shadcnd even make in a world of Claude Code? Isn’t either infinitely customizable via CSS? So what’s the difference?
- xiaoape 3mo ago
  I think it's design / aesthetic choice.
oneneptune 3mo ago
"just ticking up a version number" drastically understates the headaches of Material UI over the years. Not a boring application, a very large application -- each major version update was a tedious process because they completely upended many APIs. We've migrated to shadcn, and upgrades are now easy; we can upgrade a single component -- add the new ones free. With MaterialUI we had to update EVERYTHING to their new APIs to be able to take advantage of the new features anywhere. With shadcn we can be selective.
- RadiozRadioz 3mo ago
  This sounds like a problem with Material UI being undisciplined with API compatibility, rather than a problem with the broader approach itself.
  - c-hendricks 3mo ago
    MUI release codemods for their major version bumps to ease the migration. Those and TypeScript take out most of the issues with upgrading. There were a couple of rough migrations though.
andrewingram 3mo ago
I think it depends on the project, but I've found that using installable libraries becomes a bottleneck over time as you find yourself running into their limits, or trying to customise them in ways they really aren't design for. I wrote something about it a few years ago when shadcn was relatively new on the scene https://andrewingram.net/posts/recipe-kits-a-great-alternative-to-installable-libraries https://andrewingram.net/posts/recipe-kits-a-great-alternati...
whynotisay 3mo ago
You just gave me PTSD, and probably anyone who has been forced to use Mantine at work. Mantine sucks so much it's unreal. It's the react-table of UI libraries. Absolutely over-engineered and terrible in every way compared to everything else available.

by chvid 3mo ago

sreekanth850 3mo ago

Bigger issue ,every app that use shadcn use 100% same. I still have to figure how people differentiate their brand using shadcn.

sevenzero 3mo ago

I highly prefer a copy and paste approach. The less npm installs the better.

IceDane 3mo ago

Martine just straight up sucks. 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.

chvid 3mo ago
The ai agent “claim” is from the webpage that is linked to: 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
- addandsubtract 3mo ago
  This is just an ongoing trend to address coding agents first in documentation, and people / manual methods second.
Griffinsauce 3mo ago
> Mantine just straight up sucks. > Mantine is brilliant. Thanks internet.
whynotisay 3mo ago
Had to scroll way too far to find this - mantine sucks so much I hate it and hope no manager ever forces it on anyone ever again

Exoristos 3mo ago

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.

dkersten 3mo ago
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)
- elxr 3mo ago
  Any direct comparisons to base UI? I've been pretty satisfied with base UI so far, but my usage has been very basic so I'm open to switching if Mantine offers something better.
  - Exoristos 3mo ago
    They have very similar concepts and goals, only Mantine is much more full-featured (without being messy and while maintaining flexibility). I'd suggest if you hand-craft most of your site, but need a well-thought-out complex widget, use Base UI -- but bear in mind Mantine also offers unstyled components.
stevepotter 3mo ago
Love love love mantine.

notpushkin 3mo ago

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.

dsego 3mo ago
> building your own UI library 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.
- threetonesun 3mo ago
  Odd to me when I read stuff like this but also posts about how AI is making everything trivial. Surely a thing that almost every company did in the early 2000s should not be hard today, but of course today you can’t just write HTML + CSS, you must consider every front end framework introduced in the last decade.
  - dsego 3mo ago
    I remember the 2000s web, it was primitive. It's not hard to combine some html and css, it is hard to support more complex dynamic actions and components, all with consistent theming and behaviors and have them composable and reusable.

victorbjorklund 3mo ago

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.

rzmmm 3mo ago

I don't like the copy paste. Rather use lower-level abstractions for the UI if I know I have to make modifications.

lucumo 3mo ago

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

p-e-w 3mo ago

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

chrismsimpson 3mo ago

As grug, I prefer the paste approach

slowjames 3mo ago

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.

c-hendricks 3mo ago
MUI v5 absolutely supported React 17 though. Unless you're thinking of React 16, which hadn't had updates for almost a year when MUI v5 released.
- slowjames 3mo ago
  Oh yes you are right. My bad. I got my dependencies backwards. We were using react 17 and wanted to upgrade to 18, but first we had to migrate an entire app on MUI v4 to v5 first since v4 was not supported by 18. And it was an upgrade full of breaking changes. My point still stands that having a UI library like MUI deeply ingrained into your app can cause dependency and other issues like this. The speed you get upfront can bite you if you don’t plan carefully. Sure there are steps we could have taken to avoid such a mess. But that’s not how things often work out.
  - c-hendricks 3mo ago
    Still not sure if the alternative of vendoring like Shadcn, where a migration like this requires a black box probability machine to do the migration for you is any better.

Griffinsauce 3mo ago

> that should just be ticking up a version imber. Is it ever that simple?

stevepotter 3mo ago

I never understood the copy paste thing. Shadcn just reeks of a fad, and even after doing copy paste and trying it, I didn’t see what the big deal was. But enjoy it, y’all. One of the benefits of AI is that HN isn’t clogged with talk of JavaScript frameworks as much

satvikpendem 3mo ago
You own the code, not the library, hence you can fix whatever you need instead of relying on them to fix it.

dbbk 3mo ago

The copy paste approach is just a plain bad idea, I am not sure why this doesn't get more criticism

matt-attack 3mo ago

Can you explain what copy paste means here? I use Material UI for all my AI coded applications. Am I doing something wrong? What difference would Shadcnd even make in a world of Claude Code? Isn’t either infinitely customizable via CSS? So what’s the difference?

xiaoape 3mo ago
I think it's design / aesthetic choice.

oneneptune 3mo ago

"just ticking up a version number" drastically understates the headaches of Material UI over the years. Not a boring application, a very large application -- each major version update was a tedious process because they completely upended many APIs. We've migrated to shadcn, and upgrades are now easy; we can upgrade a single component -- add the new ones free. With MaterialUI we had to update EVERYTHING to their new APIs to be able to take advantage of the new features anywhere. With shadcn we can be selective.

RadiozRadioz 3mo ago
This sounds like a problem with Material UI being undisciplined with API compatibility, rather than a problem with the broader approach itself.
- c-hendricks 3mo ago
  MUI release codemods for their major version bumps to ease the migration. Those and TypeScript take out most of the issues with upgrading. There were a couple of rough migrations though.

andrewingram 3mo ago

I think it depends on the project, but I've found that using installable libraries becomes a bottleneck over time as you find yourself running into their limits, or trying to customise them in ways they really aren't design for. I wrote something about it a few years ago when shadcn was relatively new on the scene https://andrewingram.net/posts/recipe-kits-a-great-alternative-to-installable-libraries https://andrewingram.net/posts/recipe-kits-a-great-alternati...

whynotisay 3mo ago

You just gave me PTSD, and probably anyone who has been forced to use Mantine at work. Mantine sucks so much it's unreal. It's the react-table of UI libraries. Absolutely over-engineered and terrible in every way compared to everything else available.