Architecture Walkthrough

Two Different Places to Put the Abstraction

Utility-first CSS, exemplified by Tailwind, provides a large set of single-purpose classes, each mapping to one or a few declarations drawn from a constrained token scale: p-4, flex, text-sm, bg-blue-500. Components are composed by combining utilities in the markup. There is no per-component stylesheet.

Component-scoped CSS, exemplified by CSS Modules, styled-components, or Vue and Svelte scoped styles, gives each component its own stylesheet whose class names are made unique at build time. Components are styled by writing semantic rules such as .card and .cardTitle in a file next to the component.

The abstraction lives in different places: in the utility scale for one, in the component's own named rules for the other. Nearly every tradeoff follows from that.

Bundle Size Grows Differently

This is the most measurable difference. Utilities are shared, so the stylesheet grows with the number of distinct declarations used, not with the number of components. The hundredth card in an application reuses p-4 and rounded-lg and adds nothing to the CSS. Combined with build-time purging of unused classes, a large Tailwind application typically ships a small stylesheet that stops growing meaningfully.

Component-scoped CSS grows roughly linearly with components, because each one contributes its own rules and duplicate declarations across components are not deduplicated. Two hundred components each declaring padding: 16px produce two hundred such declarations.

The cost does not disappear, it moves. Utility markup is verbose, so the bytes shift from the stylesheet into the HTML or the component files, where they compress well but are still transferred and, in a client-rendered app, still shipped in the JavaScript bundle.

Specificity and the Cascade

Utility-first keeps every selector at a single class, so specificity is flat by construction and there is no escalation to manage. That is a genuine architectural benefit rather than a side effect.

But flat specificity means conflicts cannot be resolved by the cascade in the way people expect. class="p-4 p-8" does not apply p-8 because it appears second in the attribute; the class attribute is an unordered token set. Which one wins depends on the order those rules appear in the generated stylesheet. This is exactly why utility frameworks ship merge helpers such as tailwind-merge: a component that accepts a className prop for overrides has to deduplicate conflicting utilities before they reach the DOM, because the cascade cannot express the intent.

Component-scoped CSS has the collision problem solved by generated names, but nothing prevents a developer from nesting three levels deep inside a module, so specificity escalation is still possible unless the team maintains the discipline.

Where Each One Struggles

Utility-first struggles with anything that is not a simple declaration on a single element. Pseudo-elements, complex selectors, keyframes, and container-relative rules need either arbitrary-value escape hatches, plugin configuration, or a hand-written CSS file. Long class strings reduce markup readability, and diffs on a class attribute are harder to review than diffs on a stylesheet. Repeated patterns must be extracted into a component or a shared constant, since extracting them into a CSS class defeats the model. And because every value comes from a token scale, a value outside the scale requires either extending the config or an arbitrary-value bracket that quietly bypasses the design system.

Component-scoped CSS struggles with consistency. Nothing stops one component using padding: 15px and another padding: 16px, so a token discipline has to be imposed and enforced separately, usually through custom properties plus review. Naming every part has a real cognitive cost. Cross-component consistency requires shared abstractions that are easy to duplicate instead. And the stylesheet growth is real: dead CSS accumulates because a rule's usage is not statically obvious the way a deleted utility class is.

Both Have a Refactoring Story, and They Differ

With utilities, changing a component's appearance means editing the markup where it renders, which is local and immediate. But changing a value globally means editing the config, which is one place, or find-and-replacing class names across the codebase if the value was not tokenised.

With component-scoped CSS, changing a component's appearance means editing its stylesheet, and the effect is contained. Changing a value globally means editing a custom property, if one was used, or auditing every stylesheet if not.

Neither is unambiguously better; they fail in different directions. Utilities make local change trivial and global change dependent on tokenisation. Scoped CSS makes component boundaries clear and cross-component consistency a discipline problem.

The Hybrid Is Usually the Answer

In practice most mature codebases combine them. Utilities handle layout and one-off spacing where naming a class would be pure overhead. Component-scoped CSS or a component library handles anything with complex state, pseudo-elements, animation, or a genuine design-system identity. Custom properties supply the shared token layer both can read, which is what keeps them consistent with each other.

Framework component libraries such as shadcn/ui demonstrate the pattern directly: real components with real names, styled with utility classes internally, exposing a className prop merged through a conflict-resolving helper.

Key Code Explained

<!-- UTILITY-FIRST: the abstraction is the token scale -->
<article class="rounded-lg bg-white p-4 shadow-sm">
  <header class="mb-2 flex items-center justify-between">
    <h3 class="text-lg font-semibold text-slate-900">Title</h3>
  </header>
  <p class="text-sm text-slate-600">Body</p>
</article>
<!-- The hundredth card adds ZERO bytes of CSS. -->

/* COMPONENT-SCOPED: the abstraction is the named rule (Card.module.css) */
.card {
  border-radius: 8px;
  background: #fff;
  padding: 16px;
  box-shadow: 0 1px 2px rgb(0 0 0 / 0.05);
}
.header {
  display: flex;
  align-items: center;
  justify-content: space-between;
  margin-bottom: 8px;
}
.title {
  font-size: 1.125rem;
  font-weight: 600;
}
/* The hundredth component adds its own rules; duplicates are not merged. */

// Utility conflicts are NOT resolved by class attribute order
<div className="p-4 p-8" />
// The winner depends on the order in the GENERATED STYLESHEET,
// not on which class appears second in the attribute.

// This is why a merge helper is required for override-friendly components
import { twMerge } from 'tailwind-merge';

function Card({ className, ...props }) {
  return <div className={twMerge('rounded-lg bg-white p-4', className)} {...props} />;
}
// twMerge('p-4', 'p-8') -> 'p-8': deduplicated BEFORE reaching the DOM.

/* Utilities struggle here: pseudo-elements and complex selectors */
.tooltip::after {
  content: '';
  position: absolute;
  border: 6px solid transparent;
  border-top-color: #1e293b;
}
.row:has(+ .row--selected) {
  border-bottom-color: transparent;
}
/* Expressible in Tailwind only via before:/after: variants,
   arbitrary values, or an escape into plain CSS. */

/* THE HYBRID: shared tokens both approaches read */
:root {
  --space-4: 1rem;
  --radius-lg: 8px;
  --surface: #fff;
}
/* Utilities for layout, scoped CSS for complex component internals,
   custom properties keeping the two consistent. */

The className="p-4 p-8" example is the most useful thing here because it corrects a near-universal misconception. Developers assume utility conflicts resolve like inline styles, with the later declaration winning, and they do not: the class attribute is an unordered set and the outcome comes from stylesheet order. Understanding that explains why tailwind-merge exists rather than treating it as incidental tooling.

The two card implementations side by side make the bundle-size argument concrete. Both produce the same visual result. The utility version's CSS cost is paid once for the whole application; the scoped version's is paid per component, and the duplicate padding: 16px across two hundred components is never deduplicated.

Tradeoffs

What Interviewers Actually Check

• Whether you can describe both fairly instead of caricaturing one as inline styles
• Whether you can explain the sub-linear versus linear growth difference and why it happens
• Whether you know utility conflicts are resolved by stylesheet order, not attribute order
• Whether you can name a real weakness of the approach you personally prefer
• Whether you arrive at a hybrid with tokens as the shared layer

Follow-Up Questions

1. How does @apply in Tailwind change the tradeoffs, and why is heavy use of it generally discouraged?
2. How do custom properties act as the shared token layer between both approaches?
3. What does a component library like shadcn/ui do differently from both a pure utility approach and a pure component library?
4. How does critical CSS extraction differ between the two approaches?
5. How do cascade layers help when a utility layer must reliably override a component layer?

Common Candidate Mistakes

• Dismissing utility-first as inline styles with extra steps, which ignores that utilities draw from a constrained token scale, support responsive and state variants, and keep specificity flat
• Claiming component-scoped CSS has no scaling cost, when the stylesheet grows with component count, duplicate declarations are never merged, and dead rules accumulate invisibly
• Believing the last conflicting class in a class attribute wins, when the attribute is an unordered token set and stylesheet order decides
• Overlooking that utilities express pseudo-elements, keyframes, and relational selectors poorly, requiring variants, arbitrary values, or an escape into plain CSS
• Framing the decision as exclusive, when most mature codebases use utilities for layout, scoped CSS for complex component internals, and custom properties as the shared token layer

Interview Readiness Checklist

Before you leave this question, make sure you can answer:

• Can you describe both approaches fairly, including where the abstraction lives in each?
• Can you explain the bundle-size difference and the mechanism behind it?
• Can you explain how utility conflicts are actually resolved and why a merge helper is needed?
• Can you name a concrete weakness of each approach?
• Can you describe a hybrid strategy and justify which work goes where?

Summary

Utility-first CSS puts the abstraction in a constrained token scale of single-purpose classes composed in the markup; component-scoped CSS puts it in named rules in a per-component stylesheet whose class names are made unique at build time. Nearly every tradeoff follows from where that abstraction sits.

Utilities are shared, so the stylesheet grows with the number of distinct declarations used rather than the number of components, and with purging it effectively stops growing. Component-scoped CSS grows roughly linearly with components and never deduplicates identical declarations across them. The cost moves rather than vanishing: utility markup is verbose, so bytes shift into the HTML or component files. Utilities also keep specificity flat by construction, though that means conflicts cannot be resolved by the cascade, since the class attribute is unordered and stylesheet order decides, which is exactly why merge helpers like tailwind-merge are required for override-friendly components.

Each approach struggles in a different place. Utilities handle pseudo-elements, keyframes, and relational selectors awkwardly, need escape hatches for values outside the scale, and produce class attributes that are harder to review. Component-scoped CSS makes cross-component consistency a discipline problem, has a real naming cost, and accumulates dead rules that are hard to detect. Most mature codebases therefore combine them: utilities for layout and one-off spacing, scoped CSS or a component library for anything with complex state or identity, and custom properties as the shared token layer that keeps the two consistent.