VivekUI vs shadcn/ui: A Dependency or a Copy-Paste Kit?

shadcn/ui is not really a library in the dependency sense. A CLI copies component source into your repository, and from that moment the code is yours: yours to edit, yours to maintain, and yours to update by hand. VivekUI is a conventional npm package — you import from it and run `npm update` for fixes.

Almost every practical difference follows from that one distinction. It is not a question of which has better buttons. It is a question of who owns the source and who carries the maintenance.

Copy-paste is excellent on day one. You own everything, you can change anything, and there is no abstraction between you and the markup. The cost arrives around month six. Once a dozen components live in your repo, every upstream fix is a manual re-copy, and every file you edited has drifted from upstream so the re-copy is a merge rather than an overwrite.

With a dependency, an accessibility fix or a React 19 compatibility patch reaches you through `npm update`. The trade is that you cannot reach into the internals — you get the props the author exposed, and if the component cannot do what you need, you wrap it or you file an issue.

shadcn/ui expects Tailwind, a config file, and a CLI to add each component. Its components pull in Radix primitives, CVA and clsx, so the runtime dependency count grows with the surface you use. That is a coherent design — it leans on well-tested primitives rather than reimplementing them.

VivekUI is one install and one CSS import with zero runtime dependencies. There is no Tailwind requirement, no config file and no per-component add step. The cost of that independence is that the keyboard models are the author's own implementations rather than Radix's battle-tested ones, which is a genuine consideration — Radix has far more production exposure.

In the copy-paste model, whether a component works in a Server Component depends entirely on what you copied and whether it declares `'use client'`. That is under your control, which is an advantage if you are paying attention and a hazard if you are not.

VivekUI ships 49 of its 91 components with no client directive, asserted in CI on every build across both module formats. You do not have to audit it yourself. Whether that matters depends on how much of your app is server-rendered.

If your product's differentiator is the interface itself, owning the source is the right call. Design systems that need pixel-level divergence from any upstream default should not be fighting a dependency's prop surface — they should own the markup.

The same is true if your team is large enough to maintain the components properly, or if you are already deep in Tailwind with tooling and conventions built around it. Migrating away from that has a real cost and 'fewer dependencies' is not on its own a good enough reason.

Small teams shipping products where the UI is a means rather than the point. If nobody on the team wants to own a focus trap implementation, having it arrive through `npm update` is straightforwardly better than owning a copy of it.

It also wins on breadth. VivekUI includes an `EditableGrid`, `Scheduler`, `KanbanBoard`, `FileTree` and `VirtualList` — the components that are hard because of their keyboard models. Copying those from anywhere means owning the hardest accessibility code in your application.