Why Copy-Paste Headless Architecture Wins Over Monolithic NPM
How shadcn/ui and Exhuma proved that owning your component source code fundamentally outscales third-party npm runtime dependencies across multi-framework teams.
- 6 min read
- October 2026
- Authored by Fleect
- Architecture
- Philosophy
- Ecosystems
The Illusion of Monolithic Libraries
For nearly a decade, frontend development was dominated by massive, monolithic npm UI packages. You ran npm install some-ui-library, and overnight your node_modules absorbed hundreds of megabytes of nested dependencies, conflicting emotion/styled-components runtimes, and CSS-in-JS abstractions that slowed server rendering down to a crawl.
The Hidden Dependency Tax
Monolithic libraries introduce severe technical debt during major framework upgrades. When Next.js 15, React 19, or Svelte 5 release groundbreaking concurrency or compiler features, teams frequently find themselves blocked for months waiting for an upstream npm package maintainer to release compatible type definitions and peer dependency fixes.
# Old World: Monolithic Dependency Hell
npm install @bloated/ui-components
# npm ERR! ERESOLVE could not resolve peer dependency React 19
# Exhuma World: Direct Code Ownership
npx exhuma add tilt-card --flavor=react
# ✔ Installed TiltCard -> src/components/ui/tilt-card.tsx (100% owned, zero runtime lock-in)The Universal Component Contract
Exhuma took this concept one step further. What if you work in an enterprise organization with teams authoring applications across Next.js, Nuxt/Vue, SvelteKit, and Flutter? With Exhuma, a single canonical mathematical engine authors idiomatic, clean code natively tailored for each target platform without runtime wrappers.
Zero Runtime Lock-in
Because the code lives directly inside your repository, you possess 100% control over the DOM, styling tokens, accessibility roles, and performance optimizations. You can refactor props or change CSS variables anytime without waiting for external release cycles.