Share Meaning Before Markup
A button's intent, sizes and states can be shared even when React, Vue and Blade express them differently. Treat semantic behaviour as the contract and implementation syntax as an adapter.
8 minute read · Updated 2026-09-05
Maintaining One Design System Across Multiple Frameworks
How to support several implementation stacks without allowing them to become several unrelated products.
The Direct Answer
A multi-framework design system needs one semantic source of truth for tokens, component intentions, variants and page patterns. Each framework implements that contract natively and parity tests detect drift.
Generate What Must Be Identical
Tokens, class variants, icon names and documentation indexes are strong generation candidates. Framework-specific lifecycle and accessibility behaviour should remain native and tested.
Publish an Honest Parity Matrix
Do not say every edition is identical when one lacks a data table, calendar or form workflow. Generate availability from package manifests and distinguish built, previewable, published and purchasable states.
Version the Contract
A shared contract needs migration notes when a token, component prop or page pattern changes. Otherwise one framework can silently remain on the previous meaning while keeping the same visual name.
Frequently Asked Questions
Should all framework editions share component APIs?
Share names and concepts where natural, but do not force React hooks or Vue slots into frameworks that express composition differently.
Can Tailwind and Bootstrap use the same design contract?
Yes at the semantic level, but each needs a separately tested renderer and component implementation.
How should parity be measured?
Track component families, variants, states, page patterns, accessibility behaviour, build status, documentation and release availability.