There's a reflex in startup codebases that goes like this: the team wraps a third-party component, the wrapper grows, someone complains it's "just extra indirection," and the next developer imports the library directly to save time. Six months later, the library's API changes, and now you have two migration paths instead of one.
The wrapper wasn't the problem. The wrapper without a clear contract was.
Composition over inheritance is correct architectural advice. But "wrap everything" and "compose everything" are not the same instruction, and conflating them is how teams end up with wrapper patterns that genuinely do slow them down.
The Case For Wrappers Is Architectural, Not Aesthetic
The strongest argument for an internal UI layer isn't consistency — it's replaceability. As Alexander Nenashev argues on DEV, when UI libraries are hidden behind your own components, swapping them becomes feasible. The application talks to your architecture; your architecture talks to vendor libraries. Without that boundary, a library deprecation or acquisition doesn't just create a migration task — it creates a migration that touches every file that ever imported directly.
This matters more now than it did two years ago. As GreatFrontend's 2026 headless UI roundup notes, Radix UI was acquired by WorkOS and updates have slowed for some components, with Base UI (maintained by MUI) emerging as the more actively maintained primitive layer. Teams that imported Radix directly into product code are now weighing a migration. Teams that wrapped it are changing one file.
That's the real argument for wrappers: not that they make your code prettier, but that they make your dependencies containable.
Where Wrapper Patterns Actually Break Down
Here's where the honest tradeoff lives. A wrapper that just re-exports a component with a renamed prop is not an architectural boundary — it's a tax. And startup teams feel that tax acutely.
The failure mode looks like this:
// This wrapper does nothing useful
export function AppButton({ label, onClick, variant }) {
return <ThirdPartyButton text={label} onPress={onClick} type={variant} />;
}
This component exists to rename props. It adds a layer of indirection without adding a layer of abstraction. When the underlying library changes its API, you still have to update this file — you've just moved the problem one level up. Developers learn quickly that the wrapper isn't protecting them from anything, and they start bypassing it.
The wrapper earns its existence when it centralizes decisions that would otherwise leak into product code: default configurations, analytics hooks, accessibility overrides, design token application. Nenashev's framing is useful here — the wrapper layer should express product semantics, not vendor implementation details. <DatePicker /> that enforces your locale defaults and fires your analytics event is doing real work. <DatePicker /> that just passes props through to PrimeVue is not.
The velocity cost of wrappers is real, but it's almost always a symptom of wrappers that don't pull their weight — not of the pattern itself.
A Concrete Signal for When to Wrap
The question isn't whether to wrap. It's whether the wrapper has a job.
// Wrapper with a real job
export function AppModal({ children, onClose, analyticsId }) {
const { track } = useAnalytics();
return (
<Dialog.Root onOpenChange={(open) => {
if (!open) {
track('modal_closed', { id: analyticsId });
onClose?.();
}
}}>
<Dialog.Content className={modalStyles}>
{children}
</Dialog.Content>
</Dialog.Root>
);
}
This wrapper owns something: the analytics contract, the default styling, the close behavior. Product code doesn't need to know it's Radix underneath. If you swap to Base UI next year, you change this file. Nothing else moves.
Compare that to a wrapper that just aliases Dialog.Root with a different name. That one should be deleted.
The Heuristic
Before writing a wrapper, ask: what decision does this component own that product code shouldn't have to make?
If the answer is "none" — if the wrapper is just renaming props or adding a className — skip it. Import the library directly and accept the coupling. The velocity cost of a useless abstraction is immediate and real.
If the answer is "defaults, analytics, accessibility overrides, or design token enforcement" — wrap it. That's a real architectural boundary, and it will pay for itself the first time the underlying library changes or gets replaced.
The composition pattern that survives contact with a real product (which I wrote about back in May) isn't the one with the most layers. It's the one where each layer has a clear owner and a clear job. Wrappers that can't answer "what do I own?" are the ones that slow teams down — not the pattern itself.