[{"data":1,"prerenderedAt":34},["ShallowReactive",2],{"3786646":3},{"type_of":4,"id":5,"title":6,"description":7,"readable_publish_date":8,"slug":9,"path":10,"url":11,"comments_count":12,"public_reactions_count":12,"collection_id":13,"published_timestamp":14,"language":15,"subforem_id":16,"positive_reactions_count":12,"cover_image":17,"social_image":18,"canonical_url":11,"created_at":14,"edited_at":17,"crossposted_at":17,"published_at":14,"last_comment_at":14,"reading_time_minutes":19,"tag_list":20,"tags":21,"body_html":26,"body_markdown":27,"user":28},"article",3786646,"Design Tokens vs Atomic CSS: A Failed Integration and the Path to Harmony","A personal developer's attempt to map existing design tokens to UnoCSS failed. Quantified comparison, pragmatic boundaries, and the conclusion that design tokens come first, atomic CSS optional.","May 31","design-tokens-vs-atomic-css-a-failed-integration-and-the-path-to-harmony-2a7a","/yuelinghuashu/design-tokens-vs-atomic-css-a-failed-integration-and-the-path-to-harmony-2a7a","https://dev.to/yuelinghuashu/design-tokens-vs-atomic-css-a-failed-integration-and-the-path-to-harmony-2a7a",0,40332,"2026-05-31T02:10:45Z","en",1,null,"https://media2.dev.to/dynamic/image/width=1200,height=627,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fxc5ripv5pwfn1x2amr1i.png",6,"vue, css, designsystem, architecture",[22,23,24,25],"vue","css","designsystem","architecture","\u003Cblockquote>\n\u003Cp>A personal developer's attempt to map design tokens to UnoCSS failed the same day. But it resulted in a set of pragmatic boundaries.\u003C/p>\n\u003C/blockquote>\n\n\u003Ch2>\n  \u003Ca name=\"this-article-covers-quantified-comparison-between-design-tokens-and-atomic-css-the-real-configuration-of-the-failed-unocss-mapping-pragmatic-boundaries-between-css-variables-and-atomic-tools-and-when-to-abandon-atomic-css\" href=\"#this-article-covers-quantified-comparison-between-design-tokens-and-atomic-css-the-real-configuration-of-the-failed-unocss-mapping-pragmatic-boundaries-between-css-variables-and-atomic-tools-and-when-to-abandon-atomic-css\">\n  \u003C/a>\n  \u003Cstrong>This article covers\u003C/strong>: quantified comparison between design tokens and atomic CSS, the real configuration of the failed UnoCSS mapping, pragmatic boundaries between CSS variables and atomic tools, and when to abandon atomic CSS.\n\u003C/h2>\n\n\u003Ch2>\n  \u003Ca name=\"i-starting-point-i-have-a-complete-design-token-system\" href=\"#i-starting-point-i-have-a-complete-design-token-system\">\n  \u003C/a>\n  I. Starting Point: I Have a Complete Design Token System\n\u003C/h2>\n\n\u003Cp>My personal project \u003Ccode>moongate-vue\u003C/code> started with just three CSS files:\u003C/p>\n\n\u003Cul>\n\u003Cli>\n\u003Cstrong>\u003Ccode>colors.css\u003C/code>\u003C/strong> : Light/dark dual theme, 40+ semantic color variables (\u003Ccode>--ui-primary\u003C/code>, \u003Ccode>--ui-bg-muted\u003C/code>...)\u003C/li>\n\u003Cli>\n\u003Cstrong>\u003Ccode>layout.css\u003C/code>\u003C/strong> : Layout tokens for spacing, radius, shadow, animation, typography, breakpoints\u003C/li>\n\u003Cli>\n\u003Cstrong>\u003Ccode>main.css\u003C/code>\u003C/strong> : Global component styles\u003C/li>\n\u003C/ul>\n\n\u003Cp>This token system doesn't depend on any framework. Any component can access design constraints through \u003Ccode>var(--ui-spacing-md)\u003C/code>, \u003Ccode>var(--ui-primary)\u003C/code>. It's stable, intuitive, and maintainable — the foundation of my entire component library.\u003C/p>\n\n\u003Ch2>\n  \u003Ca name=\"ii-the-temptation-unocss-lightweight-and-atomic\" href=\"#ii-the-temptation-unocss-lightweight-and-atomic\">\n  \u003C/a>\n  II. The Temptation: UnoCSS Lightweight and Atomic\n\u003C/h2>\n\n\u003Cp>I had heard about Tailwind's \"heaviness\", but UnoCSS promised on-demand generation, zero runtime, ultra-lightweight. As a solo developer, I longed for the \"no need to write CSS class names\" experience — just stack \u003Ccode>flex p-4 text-center\u003C/code> directly in templates, no file switching, no naming headaches.\u003C/p>\n\n\u003Cp>So one night I decided: map the design tokens to UnoCSS, preserving the design system while enjoying atomic writing.\u003C/p>\n\n\u003Ch2>\n  \u003Ca name=\"iii-the-collision-one-night-of-struggle-with-real-config\" href=\"#iii-the-collision-one-night-of-struggle-with-real-config\">\n  \u003C/a>\n  III. The Collision: One Night of Struggle (With Real Config)\n\u003C/h2>\n\n\u003Cp>I wrote \u003Ccode>uno.config.ts\u003C/code>, trying to map each \u003Ccode>--ui-*\u003C/code> variable to an atomic class. Here's the failing configuration:\u003Cbr>\n\u003C/p>\n\n\u003Cdiv class=\"highlight js-code-highlight\">\n\u003Cpre class=\"highlight typescript\">\u003Ccode>\u003Cspan class=\"c1\">// uno.config.ts (failed version)\u003C/span>\n\u003Cspan class=\"k\">import\u003C/span> \u003Cspan class=\"p\">{\u003C/span> \u003Cspan class=\"nx\">defineConfig\u003C/span> \u003Cspan class=\"p\">}\u003C/span> \u003Cspan class=\"k\">from\u003C/span> \u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"s1\">unocss\u003C/span>\u003Cspan class=\"dl\">'\u003C/span>\n\n\u003Cspan class=\"k\">export\u003C/span> \u003Cspan class=\"k\">default\u003C/span> \u003Cspan class=\"nf\">defineConfig\u003C/span>\u003Cspan class=\"p\">({\u003C/span>\n  \u003Cspan class=\"na\">theme\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"p\">{\u003C/span>\n    \u003Cspan class=\"na\">colors\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"p\">{\u003C/span>\n      \u003Cspan class=\"na\">primary\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"s1\">var(--ui-primary)\u003C/span>\u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"p\">,\u003C/span>\n      \u003Cspan class=\"na\">success\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"s1\">var(--ui-success)\u003C/span>\u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"p\">,\u003C/span>\n      \u003Cspan class=\"na\">warning\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"s1\">var(--ui-warning)\u003C/span>\u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"p\">,\u003C/span>\n      \u003Cspan class=\"na\">error\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"s1\">var(--ui-error)\u003C/span>\u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"p\">,\u003C/span>\n      \u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"s1\">bg-muted\u003C/span>\u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"s1\">var(--ui-bg-muted)\u003C/span>\u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"p\">,\u003C/span>\n      \u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"s1\">border-subtle\u003C/span>\u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"s1\">var(--ui-border-subtle)\u003C/span>\u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"p\">,\u003C/span>\n      \u003Cspan class=\"c1\">// 40+ variables need mapping...\u003C/span>\n    \u003Cspan class=\"p\">},\u003C/span>\n    \u003Cspan class=\"na\">spacing\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"p\">{\u003C/span>\n      \u003Cspan class=\"na\">sm\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"s1\">var(--ui-spacing-sm)\u003C/span>\u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"p\">,\u003C/span>\n      \u003Cspan class=\"na\">md\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"s1\">var(--ui-spacing-md)\u003C/span>\u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"p\">,\u003C/span>\n      \u003Cspan class=\"na\">lg\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"s1\">var(--ui-spacing-lg)\u003C/span>\u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"p\">,\u003C/span>\n      \u003Cspan class=\"na\">xl\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"s1\">var(--ui-spacing-xl)\u003C/span>\u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"p\">,\u003C/span>\n    \u003Cspan class=\"p\">},\u003C/span>\n    \u003Cspan class=\"na\">borderRadius\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"p\">{\u003C/span>\n      \u003Cspan class=\"na\">none\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"s1\">var(--ui-radius-none)\u003C/span>\u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"p\">,\u003C/span>\n      \u003Cspan class=\"na\">sm\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"s1\">var(--ui-radius-sm)\u003C/span>\u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"p\">,\u003C/span>\n      \u003Cspan class=\"na\">md\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"s1\">var(--ui-radius-md)\u003C/span>\u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"p\">,\u003C/span>\n      \u003Cspan class=\"na\">lg\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"s1\">var(--ui-radius-lg)\u003C/span>\u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"p\">,\u003C/span>\n    \u003Cspan class=\"p\">}\u003C/span>\n  \u003Cspan class=\"p\">},\u003C/span>\n  \u003Cspan class=\"na\">shortcuts\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"p\">{\u003C/span>\n    \u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"s1\">btn\u003C/span>\u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"s1\">px-4 py-2 rounded\u003C/span>\u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"p\">,\u003C/span>\n    \u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"s1\">btn-primary\u003C/span>\u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"s1\">btn bg-primary text-white\u003C/span>\u003Cspan class=\"dl\">'\u003C/span>\n  \u003Cspan class=\"p\">}\u003C/span>\n\u003Cspan class=\"p\">})\u003C/span>\n\u003C/code>\u003C/pre>\n\u003Cdiv class=\"highlight__panel js-actions-panel\">\n\u003Cdiv class=\"highlight__panel-action js-fullscreen-code-action\">\n    \u003Csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"20px\" height=\"20px\" viewbox=\"0 0 24 24\" class=\"highlight-action crayons-icon highlight-action--fullscreen-on\">\u003Ctitle>Enter fullscreen mode\u003C/title>\n    \u003Cpath d=\"M16 3h6v6h-2V5h-4V3zM2 3h6v2H4v4H2V3zm18 16v-4h2v6h-6v-2h4zM4 19h4v2H2v-6h2v4z\">\u003C/path>\n\u003C/svg>\n\n    \u003Csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"20px\" height=\"20px\" viewbox=\"0 0 24 24\" class=\"highlight-action crayons-icon highlight-action--fullscreen-off\">\u003Ctitle>Exit fullscreen mode\u003C/title>\n    \u003Cpath d=\"M18 7h4v2h-6V3h2v4zM8 9H2V7h4V3h2v6zm10 8v4h-2v-6h6v2h-4zM8 15v6H6v-4H2v-2h6z\">\u003C/path>\n\u003C/svg>\n\n\u003C/div>\n\u003C/div>\n\u003C/div>\n\n\n\n\u003Cp>Then in \u003Ccode>Button.vue\u003C/code>, I replaced all scoped styles with atomic classes:\u003Cbr>\n\u003C/p>\n\n\u003Cdiv class=\"highlight js-code-highlight\">\n\u003Cpre class=\"highlight vue\">\u003Ccode>\u003Cspan class=\"c\"><!-- Button.vue after refactor (failed attempt) -->\u003C/span>\n\u003Cspan class=\"nt\"><button\u003C/span> \u003Cspan class=\"na\">:class=\u003C/span>\u003Cspan class=\"s\">\"cn('bg-primary text-white', 'bg-bg-muted', 'border-border-subtle')\"\u003C/span>\u003Cspan class=\"nt\">>\u003C/span>\n\u003C/code>\u003C/pre>\n\u003Cdiv class=\"highlight__panel js-actions-panel\">\n\u003Cdiv class=\"highlight__panel-action js-fullscreen-code-action\">\n    \u003Csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"20px\" height=\"20px\" viewbox=\"0 0 24 24\" class=\"highlight-action crayons-icon highlight-action--fullscreen-on\">\u003Ctitle>Enter fullscreen mode\u003C/title>\n    \u003Cpath d=\"M16 3h6v6h-2V5h-4V3zM2 3h6v2H4v4H2V3zm18 16v-4h2v6h-6v-2h4zM4 19h4v2H2v-6h2v4z\">\u003C/path>\n\u003C/svg>\n\n    \u003Csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"20px\" height=\"20px\" viewbox=\"0 0 24 24\" class=\"highlight-action crayons-icon highlight-action--fullscreen-off\">\u003Ctitle>Exit fullscreen mode\u003C/title>\n    \u003Cpath d=\"M18 7h4v2h-6V3h2v4zM8 9H2V7h4V3h2v6zm10 8v4h-2v-6h6v2h-4zM8 15v6H6v-4H2v-2h6z\">\u003C/path>\n\u003C/svg>\n\n\u003C/div>\n\u003C/div>\n\u003C/div>\n\n\n\n\u003Cp>Problems quickly emerged:\u003C/p>\n\n\u003Cul>\n\u003Cli>\n\u003Cstrong>Redundant and non-semantic class names\u003C/strong> : \u003Ccode>bg-bg-muted\u003C/code>, \u003Ccode>border-border-subtle\u003C/code> — reads like stuttering\u003C/li>\n\u003Cli>\n\u003Cstrong>High mapping maintenance cost\u003C/strong> : Change a CSS variable in one place, update the UnoCSS config in another — single source of truth becomes two\u003C/li>\n\u003Cli>\n\u003Cstrong>Conditional logic explosion\u003C/strong> : Handling \u003Ccode>neutral\u003C/code> color required \u003Ccode>color === 'neutral' ? 'text-dim' : 'text-'+color\u003C/code>\n\u003C/li>\n\u003Cli>\n\u003Cstrong>Difficult debugging\u003C/strong> : Seeing \u003Ccode>bg-bg-muted\u003C/code> in the browser means reverse-looking up which CSS variable it corresponds to\u003C/li>\n\u003Cli>\n\u003Cstrong>No IDE autocomplete\u003C/strong> : UnoCSS's type generation can't automatically cover my custom variable names\u003C/li>\n\u003C/ul>\n\n\u003Cp>I deleted all mapping code that night and returned to the original solution.\u003C/p>\n\n\u003Ch2>\n  \u003Ca name=\"iv-epiphany-design-tokens-are-the-lightest-atomic-framework\" href=\"#iv-epiphany-design-tokens-are-the-lightest-atomic-framework\">\n  \u003C/a>\n  IV. Epiphany: Design Tokens Are the Lightest Atomic Framework\n\u003C/h2>\n\n\u003Cp>Looking at \u003Ccode>bg-bg-muted\u003C/code>, I suddenly asked myself: \u003Cstrong>Why not just write \u003Ccode>background-color: var(--ui-bg-muted)\u003C/code> directly?\u003C/strong>\u003C/p>\n\n\u003Cp>My design token system already provides all the design constraints. The only value UnoCSS adds is \"fast writing\" — syntactic sugar.\u003C/p>\n\n\u003Cp>Deeper still: mapping \u003Ccode>--ui-primary\u003C/code> to \u003Ccode>bg-primary\u003C/code> is essentially \u003Cstrong>\"wrapping CSS with CSS\"\u003C/strong>. UnoCSS generates \u003Ccode>.bg-primary { background-color: var(--ui-primary); }\u003C/code> at compile time. If that's the final CSS, isn't writing it directly in scoped styles more straightforward?\u003C/p>\n\n\u003Ch2>\n  \u003Ca name=\"v-quantified-comparison-pure-design-tokens-vs-unocss-mapping\" href=\"#v-quantified-comparison-pure-design-tokens-vs-unocss-mapping\">\n  \u003C/a>\n  V. Quantified Comparison: Pure Design Tokens vs UnoCSS Mapping\n\u003C/h2>\n\n\u003Cp>To objectively judge how \"not worth it\" it really is, I compiled this table (based on my project measurements):\u003C/p>\n\n\u003Cdiv class=\"table-wrapper-paragraph\">\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Metric\u003C/th>\n\u003Cth>Pure Design Tokens (final)\u003C/th>\n\u003Cth>UnoCSS Mapping (abandoned)\u003C/th>\n\u003C/tr>\n\u003C/thead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>Number of CSS variables\u003C/td>\n\u003Ctd>40+\u003C/td>\n\u003Ctd>40+ (unchanged)\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Extra config file lines\u003C/td>\n\u003Ctd>0\u003C/td>\n\u003Ctd>~150 lines (\u003Ccode>uno.config.ts\u003C/code>)\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Class name length in templates\u003C/td>\n\u003Ctd>Short (\u003Ccode>mg-button\u003C/code>)\u003C/td>\n\u003Ctd>Long (\u003Ccode>bg-primary text-white rounded\u003C/code>)\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Places to change one color\u003C/td>\n\u003Ctd>1 place (CSS variable definition)\u003C/td>\n\u003Ctd>2 places (CSS variable + UnoCSS mapping)\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>TypeScript support\u003C/td>\n\u003Ctd>None for CSS variables\u003C/td>\n\u003Ctd>Via type generation, requires extra config\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Initial CSS size (gzipped)\u003C/td>\n\u003Ctd>~4 KB\u003C/td>\n\u003Ctd>~2 KB (smaller, on-demand)\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Debugging experience\u003C/td>\n\u003Ctd>See \u003Ccode>background: var(--ui-primary)\u003C/code> directly\u003C/td>\n\u003Ctd>Need to look up what \u003Ccode>bg-primary\u003C/code> maps to\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>Learning curve (newcomers)\u003C/td>\n\u003Ctd>Low (just understand CSS variables)\u003C/td>\n\u003Ctd>Medium (need to understand mapping + UnoCSS rules)\u003C/td>\n\u003C/tr>\n\u003C/tbody>\n\u003C/table>\u003C/div>\n\n\u003Cp>\u003Cstrong>Conclusion\u003C/strong> : Sacrifice ~2 KB in size for a massive reduction in maintenance cost. For a personal project, \u003Cstrong>maintainability, semantic clarity, and debugging experience\u003C/strong> are more important than extreme size optimization.\u003C/p>\n\n\u003Ch2>\n  \u003Ca name=\"vi-the-path-to-harmony-pragmatic-boundaries\" href=\"#vi-the-path-to-harmony-pragmatic-boundaries\">\n  \u003C/a>\n  VI. The Path to Harmony: Pragmatic Boundaries\n\u003C/h2>\n\n\u003Cp>My experience doesn't prove atomic CSS is bad — it proves that \u003Cstrong>when your project already has a mature design token system, forcibly mapping tokens to atomic classes is redundant\u003C/strong>.\u003C/p>\n\n\u003Cp>But that doesn't mean abandoning atomic tools entirely. I later found a reasonable division of labor, the key being distinguishing between \u003Cstrong>\"classes unrelated to values\"\u003C/strong> and \u003Cstrong>\"classes related to values\"\u003C/strong> :\u003C/p>\n\n\u003Cdiv class=\"table-wrapper-paragraph\">\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Style Type\u003C/th>\n\u003Cth>Recommended Solution\u003C/th>\n\u003Cth>Reason\u003C/th>\n\u003C/tr>\n\u003C/thead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>\n\u003Cstrong>Layout\u003C/strong> (flex, grid, position)\u003C/td>\n\u003Ctd>UnoCSS atomic classes (\u003Ccode>flex\u003C/code>, \u003Ccode>grid\u003C/code>, \u003Ccode>items-center\u003C/code>, \u003Ccode>justify-between\u003C/code>, \u003Ccode>relative\u003C/code>)\u003C/td>\n\u003Ctd>No values involved, no tokens needed, works out of the box\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>\n\u003Cstrong>Spacing\u003C/strong> (padding, margin, gap)\u003C/td>\n\u003Ctd>\u003Cstrong>Prefer scoped styles + \u003Ccode>var(--ui-spacing-*)\u003C/code>\u003C/strong>\u003C/td>\n\u003Ctd>Maintains theme consistency. If atomic classes must be used, modify UnoCSS config to map values to your tokens\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>\u003Cstrong>Colors, border-radius, shadow, animation\u003C/strong>\u003C/td>\n\u003Ctd>Always scoped styles + CSS variables\u003C/td>\n\u003Ctd>Strong semantics, no mapping cost, intuitive debugging\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>\u003Cstrong>Responsive variants\u003C/strong>\u003C/td>\n\u003Ctd>Can use UnoCSS \u003Ccode>md:\u003C/code> prefix, but only for layout/spacing classes, never for colors\u003C/td>\n\u003Ctd>Clean and doesn't pollute design tokens\u003C/td>\n\u003C/tr>\n\u003C/tbody>\n\u003C/table>\u003C/div>\n\n\u003Ch3>\n  \u003Ca name=\"special-note-on-spacing\" href=\"#special-note-on-spacing\">\n  \u003C/a>\n  Special Note on Spacing\n\u003C/h3>\n\n\u003Cp>UnoCSS's default \u003Ccode>p-4\u003C/code> equals \u003Ccode>1rem\u003C/code>, while your design token might have \u003Ccode>--ui-spacing-md: 0.75rem\u003C/code>. Using \u003Ccode>p-4\u003C/code> directly bypasses the design system. If you really want to use atomic spacing classes, you must modify the config:\u003Cbr>\n\u003C/p>\n\n\u003Cdiv class=\"highlight js-code-highlight\">\n\u003Cpre class=\"highlight typescript\">\u003Ccode>\u003Cspan class=\"c1\">// uno.config.ts (only if you want atomic spacing)\u003C/span>\n\u003Cspan class=\"nx\">theme\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"p\">{\u003C/span>\n  \u003Cspan class=\"nl\">spacing\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"p\">{\u003C/span>\n    \u003Cspan class=\"na\">sm\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"s1\">var(--ui-spacing-sm)\u003C/span>\u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"p\">,\u003C/span>\n    \u003Cspan class=\"na\">md\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"s1\">var(--ui-spacing-md)\u003C/span>\u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"p\">,\u003C/span>\n    \u003Cspan class=\"na\">lg\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"s1\">var(--ui-spacing-lg)\u003C/span>\u003Cspan class=\"dl\">'\u003C/span>\u003Cspan class=\"p\">,\u003C/span>\n  \u003Cspan class=\"p\">}\u003C/span>\n\u003Cspan class=\"p\">}\u003C/span>\n\u003C/code>\u003C/pre>\n\u003Cdiv class=\"highlight__panel js-actions-panel\">\n\u003Cdiv class=\"highlight__panel-action js-fullscreen-code-action\">\n    \u003Csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"20px\" height=\"20px\" viewbox=\"0 0 24 24\" class=\"highlight-action crayons-icon highlight-action--fullscreen-on\">\u003Ctitle>Enter fullscreen mode\u003C/title>\n    \u003Cpath d=\"M16 3h6v6h-2V5h-4V3zM2 3h6v2H4v4H2V3zm18 16v-4h2v6h-6v-2h4zM4 19h4v2H2v-6h2v4z\">\u003C/path>\n\u003C/svg>\n\n    \u003Csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"20px\" height=\"20px\" viewbox=\"0 0 24 24\" class=\"highlight-action crayons-icon highlight-action--fullscreen-off\">\u003Ctitle>Exit fullscreen mode\u003C/title>\n    \u003Cpath d=\"M18 7h4v2h-6V3h2v4zM8 9H2V7h4V3h2v6zm10 8v4h-2v-6h6v2h-4zM8 15v6H6v-4H2v-2h6z\">\u003C/path>\n\u003C/svg>\n\n\u003C/div>\n\u003C/div>\n\u003C/div>\n\n\n\n\u003Cp>Then you can write \u003Ccode>p-sm\u003C/code>, \u003Ccode>m-md\u003C/code>. But note: this returns to the mapping maintenance problem — every time you change a token value, you must sync the UnoCSS config. \u003Cstrong>I ultimately chose to completely avoid atomic spacing classes, using only valueless layout classes.\u003C/strong>\u003C/p>\n\n\u003Ch2>\n  \u003Ca name=\"vii-when-to-use-atomic-css-if-you-dont-have-design-tokens\" href=\"#vii-when-to-use-atomic-css-if-you-dont-have-design-tokens\">\n  \u003C/a>\n  VII. When to Use Atomic CSS (If You Don't Have Design Tokens)\n\u003C/h2>\n\n\u003Cp>I'm not an opponent of atomic CSS. I would not hesitate to choose UnoCSS/Tailwind if:\u003C/p>\n\n\u003Cul>\n\u003Cli>✅ New project, rapid prototyping\u003C/li>\n\u003Cli>✅ Design system not yet mature, still iterating quickly\u003C/li>\n\u003Cli>✅ Entire team familiar with atomic syntax\u003C/li>\n\u003Cli>✅ No need to reuse styles across frameworks\u003C/li>\n\u003C/ul>\n\n\u003Cp>\u003Cstrong>Scenarios to avoid\u003C/strong> :\u003C/p>\n\n\u003Cul>\n\u003Cli>❌ Existing mature design tokens requiring long-term maintenance\u003C/li>\n\u003Cli>❌ Need to reuse style files across Vue/React/Svelte\u003C/li>\n\u003Cli>❌ CSS size is not the primary concern (modern atomic frameworks are actually quite small)\u003C/li>\n\u003C/ul>\n\n\u003Ch2>\n  \u003Ca name=\"viii-advice-for-developers-in-the-same-situation\" href=\"#viii-advice-for-developers-in-the-same-situation\">\n  \u003C/a>\n  VIII. Advice for Developers in the Same Situation\n\u003C/h2>\n\n\u003Cp>If you're like me — already have a complete design token system (CSS variables, Design Tokens) but want to try atomic CSS — my advice:\u003C/p>\n\n\u003Col>\n\u003Cli>\n\u003Cstrong>Don't map core tokens like colors, theme spacing, border-radius\u003C/strong>. Use them directly via \u003Ccode>var(--ui-*)\u003C/code> in scoped styles.\u003C/li>\n\u003Cli>\n\u003Cstrong>Only use the generic layout classes provided by atomic tools\u003C/strong> (\u003Ccode>flex\u003C/code>, \u003Ccode>grid\u003C/code>, \u003Ccode>items-center\u003C/code>, \u003Ccode>relative\u003C/code>...). These have nothing to do with your design system and require no mapping.\u003C/li>\n\u003Cli>\n\u003Cstrong>Beware of \"magic numbers\"\u003C/strong> : Avoid hardcoded values like \u003Ccode>p-3.5\u003C/code> or \u003Ccode>gap-11\u003C/code> in templates — they break the design token contract.\u003C/li>\n\u003Cli>\n\u003Cstrong>For responsive layouts\u003C/strong> , continue using atomic tools' responsive variants (\u003Ccode>md:flex\u003C/code>), but try to use them only for layout, never for colors/spacing.\u003C/li>\n\u003Cli>\n\u003Cstrong>If atomic tools feel like \"using for the sake of using\", you can completely abandon them\u003C/strong>. Native CSS + design tokens is already clear and maintainable enough.\u003C/li>\n\u003C/ol>\n\n\u003Ch2>\n  \u003Ca name=\"ix-looking-ahead-dtcg-and-the-future\" href=\"#ix-looking-ahead-dtcg-and-the-future\">\n  \u003C/a>\n  IX. Looking Ahead: DTCG and the Future\n\u003C/h2>\n\n\u003Cp>The W3C Design Tokens Community Group (DTCG) released its first stable specification at the end of 2025, advancing design tokens as a cross-platform common language. This means the \u003Cstrong>token-centric\u003C/strong> architecture is becoming industry consensus.\u003C/p>\n\n\u003Cp>Atomic tools can consume design tokens, but shouldn't hijack them. Hardcoding tokens into tool-specific atomic classes locks your design system into that tool's syntax. Using CSS variables directly, on the other hand, is framework-agnostic and future-oriented.\u003C/p>\n\n\u003Cp>In the future, when DTCG tooling matures, it may automatically generate atomic classes from design tokens. At that point I'll reevaluate UnoCSS. But for now (2026), manual mapping is still a maintenance burden.\u003C/p>\n\n\u003Ch2>\n  \u003Ca name=\"x-conclusion-design-tokens-first-atomic-optional\" href=\"#x-conclusion-design-tokens-first-atomic-optional\">\n  \u003C/a>\n  X. Conclusion: Design Tokens First, Atomic Optional\n\u003C/h2>\n\n\u003Cp>In the end, my \u003Ccode>Button.vue\u003C/code> went back to its original form:\u003Cbr>\n\u003C/p>\n\n\u003Cdiv class=\"highlight js-code-highlight\">\n\u003Cpre class=\"highlight vue\">\u003Ccode>\u003Cspan class=\"nt\"><\u003C/span>\u003Cspan class=\"k\">style\u003C/span> \u003Cspan class=\"na\">scoped\u003C/span>\u003Cspan class=\"nt\">>\u003C/span>\n\u003Cspan class=\"nc\">.mg-button\u003C/span> \u003Cspan class=\"p\">{\u003C/span>\n  \u003Cspan class=\"nl\">background-color\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"n\">var\u003C/span>\u003Cspan class=\"p\">(\u003C/span>\u003Cspan class=\"n\">--ui-primary\u003C/span>\u003Cspan class=\"p\">);\u003C/span>\n  \u003Cspan class=\"nl\">color\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"no\">white\u003C/span>\u003Cspan class=\"p\">;\u003C/span>\n  \u003Cspan class=\"nl\">padding\u003C/span>\u003Cspan class=\"p\">:\u003C/span> \u003Cspan class=\"n\">var\u003C/span>\u003Cspan class=\"p\">(\u003C/span>\u003Cspan class=\"n\">--ui-spacing-md\u003C/span>\u003Cspan class=\"p\">)\u003C/span> \u003Cspan class=\"n\">var\u003C/span>\u003Cspan class=\"p\">(\u003C/span>\u003Cspan class=\"n\">--ui-spacing-lg\u003C/span>\u003Cspan class=\"p\">);\u003C/span>\n\u003Cspan class=\"p\">}\u003C/span>\n\u003Cspan class=\"nt\"></\u003C/span>\u003Cspan class=\"k\">style\u003C/span>\u003Cspan class=\"nt\">>\u003C/span>\n\u003C/code>\u003C/pre>\n\u003Cdiv class=\"highlight__panel js-actions-panel\">\n\u003Cdiv class=\"highlight__panel-action js-fullscreen-code-action\">\n    \u003Csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"20px\" height=\"20px\" viewbox=\"0 0 24 24\" class=\"highlight-action crayons-icon highlight-action--fullscreen-on\">\u003Ctitle>Enter fullscreen mode\u003C/title>\n    \u003Cpath d=\"M16 3h6v6h-2V5h-4V3zM2 3h6v2H4v4H2V3zm18 16v-4h2v6h-6v-2h4zM4 19h4v2H2v-6h2v4z\">\u003C/path>\n\u003C/svg>\n\n    \u003Csvg xmlns=\"http://www.w3.org/2000/svg\" width=\"20px\" height=\"20px\" viewbox=\"0 0 24 24\" class=\"highlight-action crayons-icon highlight-action--fullscreen-off\">\u003Ctitle>Exit fullscreen mode\u003C/title>\n    \u003Cpath d=\"M18 7h4v2h-6V3h2v4zM8 9H2V7h4V3h2v6zm10 8v4h-2v-6h6v2h-4zM8 15v6H6v-4H2v-2h6z\">\u003C/path>\n\u003C/svg>\n\n\u003C/div>\n\u003C/div>\n\u003C/div>\n\n\n\n\u003Cp>Simple, direct, semantic. That's how design tokens should be used.\u003C/p>\n\n\u003Cp>UnoCSS and Tailwind are good tools, but they're not substitutes for a design system. Design tokens are the foundation; atomic is just a layer of paint on top. When you already have a solid foundation, whether to apply that layer of paint depends on whether you're willing to accept the maintenance cost for some syntactic sugar.\u003C/p>\n\n\u003Cp>For me, at least, \u003Cstrong>it's not worth it\u003C/strong>.\u003C/p>\n\n\n\u003Chr>\n\n\u003Cp>\u003Cem>This article is part of the **Vue 3 Component Library Development Guide\u003C/em>* series.*\u003Cbr>\u003Cbr>\n\u003Cem>The original Chinese version is available on my blog: \u003Ca href=\"https://moongate.top\" target=\"_blank\" rel=\"noopener noreferrer\">moongate.top\u003C/a>.\u003C/em>\u003Cbr>\u003Cbr>\n\u003Cem>Try the component library on npm: \u003Ca href=\"https://www.npmjs.com/package/moongate-vue\" target=\"_blank\" rel=\"noopener noreferrer\">moongate-vue\u003C/a>\u003C/em>\u003C/p>\n\n\u003Cp>© 2026 yuelinghuashu. This work is licensed under \u003Ca href=\"https://creativecommons.org/licenses/by-nc/4.0/\" target=\"_blank\" rel=\"noopener noreferrer\">CC BY-NC 4.0\u003C/a>.\u003C/p>\n\n","---\ntitle: \"Design Tokens vs Atomic CSS: A Failed Integration and the Path to Harmony\"\ndescription: \"A personal developer's attempt to map existing design tokens to UnoCSS failed. Quantified comparison, pragmatic boundaries, and the conclusion that design tokens come first, atomic CSS optional.\"\ntags: [vue, css, designsystem, architecture]\nseries: Vue 3 Component Library Development Guide\n---\n\n> A personal developer's attempt to map design tokens to UnoCSS failed the same day. But it resulted in a set of pragmatic boundaries.\n\n**This article covers**: quantified comparison between design tokens and atomic CSS, the real configuration of the failed UnoCSS mapping, pragmatic boundaries between CSS variables and atomic tools, and when to abandon atomic CSS.\n---\n\n## I. Starting Point: I Have a Complete Design Token System\n\nMy personal project `moongate-vue` started with just three CSS files:\n\n- **`colors.css`** : Light/dark dual theme, 40+ semantic color variables (`--ui-primary`, `--ui-bg-muted`...)\n- **`layout.css`** : Layout tokens for spacing, radius, shadow, animation, typography, breakpoints\n- **`main.css`** : Global component styles\n\nThis token system doesn't depend on any framework. Any component can access design constraints through `var(--ui-spacing-md)`, `var(--ui-primary)`. It's stable, intuitive, and maintainable — the foundation of my entire component library.\n\n## II. The Temptation: UnoCSS Lightweight and Atomic\n\nI had heard about Tailwind's \"heaviness\", but UnoCSS promised on-demand generation, zero runtime, ultra-lightweight. As a solo developer, I longed for the \"no need to write CSS class names\" experience — just stack `flex p-4 text-center` directly in templates, no file switching, no naming headaches.\n\nSo one night I decided: map the design tokens to UnoCSS, preserving the design system while enjoying atomic writing.\n\n## III. The Collision: One Night of Struggle (With Real Config)\n\nI wrote `uno.config.ts`, trying to map each `--ui-*` variable to an atomic class. Here's the failing configuration:\n\n```ts\n// uno.config.ts (failed version)\nimport { defineConfig } from 'unocss'\n\nexport default defineConfig({\n  theme: {\n    colors: {\n      primary: 'var(--ui-primary)',\n      success: 'var(--ui-success)',\n      warning: 'var(--ui-warning)',\n      error: 'var(--ui-error)',\n      'bg-muted': 'var(--ui-bg-muted)',\n      'border-subtle': 'var(--ui-border-subtle)',\n      // 40+ variables need mapping...\n    },\n    spacing: {\n      sm: 'var(--ui-spacing-sm)',\n      md: 'var(--ui-spacing-md)',\n      lg: 'var(--ui-spacing-lg)',\n      xl: 'var(--ui-spacing-xl)',\n    },\n    borderRadius: {\n      none: 'var(--ui-radius-none)',\n      sm: 'var(--ui-radius-sm)',\n      md: 'var(--ui-radius-md)',\n      lg: 'var(--ui-radius-lg)',\n    }\n  },\n  shortcuts: {\n    'btn': 'px-4 py-2 rounded',\n    'btn-primary': 'btn bg-primary text-white'\n  }\n})\n```\n\nThen in `Button.vue`, I replaced all scoped styles with atomic classes:\n\n```vue\n\u003C!-- Button.vue after refactor (failed attempt) -->\n\u003Cbutton :class=\"cn('bg-primary text-white', 'bg-bg-muted', 'border-border-subtle')\">\n```\n\nProblems quickly emerged:\n\n- **Redundant and non-semantic class names** : `bg-bg-muted`, `border-border-subtle` — reads like stuttering\n- **High mapping maintenance cost** : Change a CSS variable in one place, update the UnoCSS config in another — single source of truth becomes two\n- **Conditional logic explosion** : Handling `neutral` color required `color === 'neutral' ? 'text-dim' : 'text-'+color`\n- **Difficult debugging** : Seeing `bg-bg-muted` in the browser means reverse-looking up which CSS variable it corresponds to\n- **No IDE autocomplete** : UnoCSS's type generation can't automatically cover my custom variable names\n\nI deleted all mapping code that night and returned to the original solution.\n\n## IV. Epiphany: Design Tokens Are the Lightest Atomic Framework\n\nLooking at `bg-bg-muted`, I suddenly asked myself: **Why not just write `background-color: var(--ui-bg-muted)` directly?**\n\nMy design token system already provides all the design constraints. The only value UnoCSS adds is \"fast writing\" — syntactic sugar.\n\nDeeper still: mapping `--ui-primary` to `bg-primary` is essentially **\"wrapping CSS with CSS\"**. UnoCSS generates `.bg-primary { background-color: var(--ui-primary); }` at compile time. If that's the final CSS, isn't writing it directly in scoped styles more straightforward?\n\n## V. Quantified Comparison: Pure Design Tokens vs UnoCSS Mapping\n\nTo objectively judge how \"not worth it\" it really is, I compiled this table (based on my project measurements):\n\n| Metric | Pure Design Tokens (final) | UnoCSS Mapping (abandoned) |\n|--------|---------------------------|----------------------------|\n| Number of CSS variables | 40+ | 40+ (unchanged) |\n| Extra config file lines | 0 | ~150 lines (`uno.config.ts`) |\n| Class name length in templates | Short (`mg-button`) | Long (`bg-primary text-white rounded`) |\n| Places to change one color | 1 place (CSS variable definition) | 2 places (CSS variable + UnoCSS mapping) |\n| TypeScript support | None for CSS variables | Via type generation, requires extra config |\n| Initial CSS size (gzipped) | ~4 KB | ~2 KB (smaller, on-demand) |\n| Debugging experience | See `background: var(--ui-primary)` directly | Need to look up what `bg-primary` maps to |\n| Learning curve (newcomers) | Low (just understand CSS variables) | Medium (need to understand mapping + UnoCSS rules) |\n\n**Conclusion** : Sacrifice ~2 KB in size for a massive reduction in maintenance cost. For a personal project, **maintainability, semantic clarity, and debugging experience** are more important than extreme size optimization.\n\n## VI. The Path to Harmony: Pragmatic Boundaries\n\nMy experience doesn't prove atomic CSS is bad — it proves that **when your project already has a mature design token system, forcibly mapping tokens to atomic classes is redundant**.\n\nBut that doesn't mean abandoning atomic tools entirely. I later found a reasonable division of labor, the key being distinguishing between **\"classes unrelated to values\"** and **\"classes related to values\"** :\n\n| Style Type | Recommended Solution | Reason |\n|------------|---------------------|--------|\n| **Layout** (flex, grid, position) | UnoCSS atomic classes (`flex`, `grid`, `items-center`, `justify-between`, `relative`) | No values involved, no tokens needed, works out of the box |\n| **Spacing** (padding, margin, gap) | **Prefer scoped styles + `var(--ui-spacing-*)`** | Maintains theme consistency. If atomic classes must be used, modify UnoCSS config to map values to your tokens |\n| **Colors, border-radius, shadow, animation** | Always scoped styles + CSS variables | Strong semantics, no mapping cost, intuitive debugging |\n| **Responsive variants** | Can use UnoCSS `md:` prefix, but only for layout/spacing classes, never for colors | Clean and doesn't pollute design tokens |\n\n### Special Note on Spacing\n\nUnoCSS's default `p-4` equals `1rem`, while your design token might have `--ui-spacing-md: 0.75rem`. Using `p-4` directly bypasses the design system. If you really want to use atomic spacing classes, you must modify the config:\n\n```ts\n// uno.config.ts (only if you want atomic spacing)\ntheme: {\n  spacing: {\n    sm: 'var(--ui-spacing-sm)',\n    md: 'var(--ui-spacing-md)',\n    lg: 'var(--ui-spacing-lg)',\n  }\n}\n```\n\nThen you can write `p-sm`, `m-md`. But note: this returns to the mapping maintenance problem — every time you change a token value, you must sync the UnoCSS config. **I ultimately chose to completely avoid atomic spacing classes, using only valueless layout classes.**\n\n## VII. When to Use Atomic CSS (If You Don't Have Design Tokens)\n\nI'm not an opponent of atomic CSS. I would not hesitate to choose UnoCSS/Tailwind if:\n\n- ✅ New project, rapid prototyping\n- ✅ Design system not yet mature, still iterating quickly\n- ✅ Entire team familiar with atomic syntax\n- ✅ No need to reuse styles across frameworks\n\n**Scenarios to avoid** :\n\n- ❌ Existing mature design tokens requiring long-term maintenance\n- ❌ Need to reuse style files across Vue/React/Svelte\n- ❌ CSS size is not the primary concern (modern atomic frameworks are actually quite small)\n\n## VIII. Advice for Developers in the Same Situation\n\nIf you're like me — already have a complete design token system (CSS variables, Design Tokens) but want to try atomic CSS — my advice:\n\n1. **Don't map core tokens like colors, theme spacing, border-radius**. Use them directly via `var(--ui-*)` in scoped styles.\n2. **Only use the generic layout classes provided by atomic tools** (`flex`, `grid`, `items-center`, `relative`...). These have nothing to do with your design system and require no mapping.\n3. **Beware of \"magic numbers\"** : Avoid hardcoded values like `p-3.5` or `gap-11` in templates — they break the design token contract.\n4. **For responsive layouts** , continue using atomic tools' responsive variants (`md:flex`), but try to use them only for layout, never for colors/spacing.\n5. **If atomic tools feel like \"using for the sake of using\", you can completely abandon them**. Native CSS + design tokens is already clear and maintainable enough.\n\n## IX. Looking Ahead: DTCG and the Future\n\nThe W3C Design Tokens Community Group (DTCG) released its first stable specification at the end of 2025, advancing design tokens as a cross-platform common language. This means the **token-centric** architecture is becoming industry consensus.\n\nAtomic tools can consume design tokens, but shouldn't hijack them. Hardcoding tokens into tool-specific atomic classes locks your design system into that tool's syntax. Using CSS variables directly, on the other hand, is framework-agnostic and future-oriented.\n\nIn the future, when DTCG tooling matures, it may automatically generate atomic classes from design tokens. At that point I'll reevaluate UnoCSS. But for now (2026), manual mapping is still a maintenance burden.\n\n## X. Conclusion: Design Tokens First, Atomic Optional\n\nIn the end, my `Button.vue` went back to its original form:\n\n```vue\n\u003Cstyle scoped>\n.mg-button {\n  background-color: var(--ui-primary);\n  color: white;\n  padding: var(--ui-spacing-md) var(--ui-spacing-lg);\n}\n\u003C/style>\n```\n\nSimple, direct, semantic. That's how design tokens should be used.\n\nUnoCSS and Tailwind are good tools, but they're not substitutes for a design system. Design tokens are the foundation; atomic is just a layer of paint on top. When you already have a solid foundation, whether to apply that layer of paint depends on whether you're willing to accept the maintenance cost for some syntactic sugar.\n\nFor me, at least, **it's not worth it**.\n\n---\n\n*This article is part of the **Vue 3 Component Library Development Guide** series.*  \n*The original Chinese version is available on my blog: [moongate.top](https://moongate.top).*  \n*Try the component library on npm: [moongate-vue](https://www.npmjs.com/package/moongate-vue)*\n\n© 2026 yuelinghuashu. This work is licensed under [CC BY-NC 4.0](https://creativecommons.org/licenses/by-nc/4.0/).",{"name":29,"username":29,"twitter_username":17,"github_username":29,"user_id":30,"website_url":31,"profile_image":32,"profile_image_90":33},"yuelinghuashu",3817907,"https://moongate.top","https://media2.dev.to/dynamic/image/width=640,height=640,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3817907%2F1c2400a0-aa1e-4f4a-987c-7f8bb69ff818.png","https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3817907%2F1c2400a0-aa1e-4f4a-987c-7f8bb69ff818.png",1780372426323]