Utility-first versus semantic CSS trade-offs

WHAT THIS TESTS This is a senior architecture discussion testing nuance: can you articulate genuine trade-offs across maintainability, onboarding, and bundle size rather than evangelize one approach. The interviewer wants context-aware reasoning.

A GOOD ANSWER COVERS Utility-first, like Tailwind: pros include rapid development, no time lost naming classes, styles co-located with markup so you rarely jump files, consistent constraints from a design-token config, and small production bundles because unused utilities are purged. Cons include verbose, noisy markup, a learning curve for the class vocabulary, and design decisions scattered into HTML that can be harder to audit. Semantic component-based, like BEM with Sass: pros include readable, intention-revealing markup, clear component boundaries, and centralized styling that maps to a mental model. Cons include naming overhead and bikeshedding, CSS that tends to grow and accumulate dead rules without tooling, specificity drift over time, and more file-switching. For a large multi-developer system, the deciding factors are: team familiarity and onboarding, how strong your design-token discipline is, whether you can extract repeated utilities into components, and tooling for purging and linting. Many mature teams blend both: utilities for one-off layout, components for recurring patterns.

COMMON WRONG ANSWERS Claiming Tailwind is always smaller or always messier. Ignoring that utilities purge well while hand-written semantic CSS often grows unbounded. Treating the two as mutually exclusive rather than blendable. Forgetting the human factors of onboarding and consistency.

LIKELY FOLLOW-UPS How do you keep utility markup maintainable, for example via component extraction? How does each approach handle theming and tokens? What linting prevents dead CSS in the semantic approach? When would you mandate one in a large org?

ONE CONCRETE EXAMPLE A fifty-developer product might adopt utilities for layout and spacing to guarantee consistent scales and a purged bundle, while extracting frequently repeated patterns like cards and buttons into named components so the markup for those stays clean. This hybrid limits both the verbosity of pure utilities and the dead-CSS growth of pure semantic styling.