Utility-first vs Semantic Classes

## The two models Every styling approach has to answer one question: **where does the knowledge of how this element looks live?** The **semantic** (component-class) model puts it in the stylesheet. Markup carries a name describing the element's *role* in the domain — `card`, `site-header`, `price-tag` — and a rule elsewhere binds that name to declarations: ```css .card { display: flex; gap: 0.5rem; padding: 1rem; border: 1px solid #d0d0d0; } ``` The **utility-first** (atomic) model puts it in the markup. The stylesheet holds a fixed vocabulary of tiny classes, each carrying essentially one declaration, and the element composes them: ```css .flex { display: flex; } .gap-2 { gap: 0.5rem; } .p-4 { padding: 1rem; } .border { border: 1px solid #d0d0d0; } ``` ```html <div class="flex gap-2 p-4 border">…</div> ``` Both produce identical rendered output. The difference is entirely about where a future engineer looks, and what they can break. ## Why anyone does the utility thing The idea is older than any current tool — Thierry Koblentz argued for it in 2013 as "atomic CSS", and libraries such as Tachyons and Basscss shipped it years before it became mainstream. Three arguments drive it: 1. **Co-location.** The styling is visible on the element. You do not jump to another file, and you do not have to guess whether `.card` is also used somewhere you have not seen. 2. **Bounded growth.** `.p-4` is written once and used ten thousand times. The stylesheet's size is a function of *how many distinct utilities exist*, not of how many components the product has. 3. **A closed vocabulary.** If the only spacing utilities are `1`, `2`, `3`, `4`…, nobody types `padding: 13px`. Consistency comes from what the system *cannot express*. ## Why anyone resists it The critiques are equally concrete: - **Class soup.** A realistic element can carry fifteen classes, plus responsive and state variations, which makes markup hard to scan and diffs hard to review. - **Duplication.** The same class string is repeated on every instance. Changing all cards means editing every occurrence — unless the markup itself is componentized, which is the standard answer. - **Loss of vocabulary.** `.card` is a name the whole team shares; `flex gap-2 p-4 border` names nothing, so searching the codebase for "the card styles" gets harder. - **Escape hatches.** Anything the utility vocabulary does not cover — a complex `grid-template-areas`, an animation, a third-party widget's internal markup you cannot touch — still needs real CSS. ## The critique that decides the argument The usual mistake is to compare markup readability, which is a matter of taste. The durable difference is **blast radius**. Editing a utility class on one element can only affect that element. Editing `.card` affects every element that has ever carried the class, including ones written by another team two years ago. That asymmetry is why long-lived semantic stylesheets tend to become append-only: it is safer to add `.card--compact` than to change `.card`, so the file grows and dead rules accumulate. The counter-argument is that the semantic model's blast radius is a **feature** when the change is intentional — one edit restyles every card in the product, which is exactly what a design change wants. Utility-first gets that back only if the markup is componentized somewhere (a template, a partial, a framework component), so the class string exists in one place. ## The honest position in an interview Say that they are not rival ideologies but two placements of the same information, and that the choice depends on whether your markup is already componentized. If templates are reusable units, utility-first is cheap: duplication is collapsed by the template, and you gain locality. If markup is hand-written pages, plain HTML, email templates, or content authored by non-developers, repeating class strings by hand is a real cost and semantic classes earn their keep. Most mature codebases run a hybrid: utilities for composition inside components, a small set of real CSS rules for base typography, resets, and things utilities cannot express.