Copy-paste from Figma feels fast. It is fast—right up until you need to change your brand's primary color and discover it lives in 47 different files.
The problem with copying CSS values directly from the Inspect panel is that you're capturing raw numbers, not meaning. #3B82F6 says nothing about why that color is used. 24px doesn't explain whether it's card padding, section spacing, or an icon size. Hardcoded values accumulate silently, and the codebase slowly diverges from the design.
What Copy-Paste Actually Costs
A new component might take 20 minutes to copy values and paste them into CSS. That feels efficient. The hidden cost appears later:
Rebrand work. Changing a brand color requires a find-replace across every file that hardcoded it. Miss one instance and the visual breaks.
Dark mode. Every hardcoded color needs a manual counterpart in your dark theme. The list grows with every component.
Design drift. One developer uses 12px padding; another uses 16px because it "looked close." Over six months, nothing is consistent.
Maintenance. A year from now, #3B82F6 appears in a PR and nobody remembers whether it's the primary, an accent, or something legacy.
The Semantic Naming Shift
Design tokens flip the relationship between value and meaning. Instead of asking "what is this value?" you ask "what does this value do?"
A token named --color-primary can change its hex without breaking anything that references it. The name encodes the intent. When your brand moves from blue to purple:
/* Before */
--color-primary: #3B82F6;
/* After */
--color-primary: #9333EA;
Every button, link, and focus state updates immediately. The name stays meaningful because it describes role, not appearance.
Compare that to renaming --color-blue-500 to --color-purple-500—you'd have to find and update every reference anyway, which defeats the purpose.
How FramingUI Uses Tokens
FramingUI builds design tokens directly into its component API. When you use a Button component with variant="primary", it applies the right tokens internally:
.button-primary {
background: var(--bg-primary-default);
color: var(--fg-on-primary);
border-radius: var(--radius-md);
padding: var(--spacing-3) var(--spacing-6);
}
You never look up which token goes with which element. The component already knows. Change the token value in one place; every button in the application reflects the update.
Theme switching works the same way. The tokens resolve to different values under different data attributes:
:root {
--bg-primary-default: #3B82F6;
--bg-canvas: #FFFFFF;
}
[data-theme="dark"] {
--bg-primary-default: #60A5FA;
--bg-canvas: #1F2937;
}
The component code doesn't change. The CSS variable resolves differently based on the active theme.
Migrating an Existing Codebase
If you already have a codebase full of hardcoded values, a full rewrite isn't necessary. You can migrate incrementally.
Start by auditing colors—they have the highest consistency impact:
# Find all hardcoded hex colors
rg '#[0-9A-Fa-f]{6}' --type css --type tsx
Group the values by intent. If #3B82F6 appears in 12 places and always means "primary action," that's your --color-primary token. Define the tokens, then replace the hardcoded values one component at a time.
Start with the most-used components (buttons, inputs, cards). Each one you migrate reduces future maintenance overhead. Typography and spacing follow the same pattern—find the values that repeat, name them semantically, replace the literals.
When Copy-Paste Still Makes Sense
Design tokens aren't the right tool for every situation. One-off marketing pages with custom art direction, external CSS you don't control, and quick throw-away prototypes don't justify the overhead of a token system.
The dividing line is longevity and reuse. If the code will be maintained, if multiple developers will touch it, if it will need to work across themes or platforms—tokens pay for themselves quickly. If it's a one-day experiment that will be discarded, copying values directly is fine.
Product UIs, component libraries, and any codebase that needs to evolve over months or years are where the token approach compounds in value. The upfront cost is defining the names. The ongoing benefit is that intent is encoded in the code itself, and changes propagate automatically.