A five-file prototype survives any CSS approach you throw at it. What separates the options in this lesson is what happens at file two hundred: whether class names collide, whether a theme change forces a re-render, whether the CSS bundle keeps growing forever or levels off. None of these approaches is "the best" one, and treating one as a favorite is usually the wrong answer in an interview. What matters is knowing the real trade-offs well enough to pick the right one for a given team and app.

BEM: discipline, not tooling

Block-Element-Modifier is a naming convention, nothing more. It needs no build step and works in a plain .css file, which is exactly why it predates every other option here.

The strength is zero tooling, and a class name that documents its own relationships. The weakness is that nothing actually enforces the scoping: another file can define its own .card__title and silently collide with yours. BEM only works as well as everyone's discipline holds, and that discipline is the first thing to slip once more than one team touches the codebase.

Remember: BEM is a naming convention, not a guarantee. Nothing stops a second file from reusing the same class name by accident.

CSS Modules: scoping enforced by the build

CSS Modules solve exactly the problem BEM cannot: every class name gets scoped to its own file automatically, compiled to a hashed name at build time.

.card compiles to something like .Card_card__a1b2c, so a class named card in a completely unrelated file can never collide with this one. No naming convention is needed to make that true; the build enforces it. It is the default in both Next.js and Vite with zero configuration, which is a big part of why it is such a common starting point.

Remember: CSS Modules turn scoping from a human habit into a build-time guarantee.

CSS-in-JS, and the runtime cost that changed the ecosystem

Libraries like styled-components and Emotion let you write CSS directly in TypeScript, next to the component, with full access to props and theme values.

Here is the detail worth naming precisely, because it is what actually pushed the ecosystem to change: the classic version of this approach parses those template literals and injects <style> tags at runtime, in the browser, on every render where a dynamic style changes. That costs real JS parsing time on the client, makes server-side rendering harder (style extraction has to happen on the server and reconcile with what the client injects, which is why styled-components needed its own build plugin just to avoid a flash of unstyled content), and makes a bundler's job harder, since dynamically generated class names resist tree shaking and critical-CSS extraction.

That cost is exactly why the industry moved toward zero-runtime CSS-in-JS: vanilla-extract, Panda CSS, and styled-components' own newer compiler mode, among others. These extract styles to static CSS files at build time instead of runtime. You keep the convenience of writing CSS next to your component; you drop the browser-side parsing tax. Naming this shift, and why it happened, reads as someone who has tracked the ecosystem, not someone reciting whichever library happens to be popular this year.

Remember: the problem with classic CSS-in-JS was never the syntax, it was generating styles in the browser at runtime instead of once at build time.

Atomic CSS: composing utilities instead of writing new rules

Tailwind is the dominant example: small, single-purpose classes composed directly in markup, instead of authoring new CSS per component.

The upside is real: the utility set is finite and shared across the whole app, so unlike a hand-written stylesheet, the CSS bundle levels off instead of growing with every new component, and Tailwind purges anything unused at build time on top of that. There is also no more debating what to name a wrapper <div>, and no specificity conflicts, since every utility class touches one property and carries roughly equal weight. The cost is markup that reads noisier, and a real learning curve for anyone used to styling in a separate stylesheet instead of inline in JSX.

Remember: a hand-written stylesheet grows with every component. A shared, finite utility set does not.

Design tokens and a theme that doesn't need a re-render

Design tokens are the named, central values, colors, spacing, radii, that both design and code point to, instead of scattering hardcoded values through the codebase. CSS custom properties are the natural way to build a theme that can change at runtime, because unlike a Sass variable, a --variable is resolved in the browser, not baked in at build time.

Notice there is no React re-render anywhere in that theme switch. Flipping the data-theme attribute makes the browser recompute styles for every element referencing a changed custom property, on its own, with React never knowing or caring. Compare that to a JS-driven theme object passed through Context, where every consuming component genuinely re-renders on every theme change. For a value that changes as rarely as a light/dark toggle, CSS variables are the cheaper mechanism by a wide margin.

Remember: flipping one HTML attribute lets the browser update every themed element on its own. No React re-render involved.

A responsive card grid, using both ideas at once

Two distinct responsive mechanisms are stacked here, and it is worth being able to tell them apart. repeat(auto-fill, minmax(220px, 1fr)) gives you a reflowing grid with zero media queries: the number of columns is whatever fits, driven purely by available width. Container queries (@container) solve a different problem entirely: they let one component respond to its own box size, not the screen's, which a media query structurally cannot do. A card that needs to lay out differently depending on whether its parent gave it 300px or 900px, regardless of the overall screen size, is exactly the case container queries exist for.

Remember: a media query answers "how big is the screen?" A container query answers "how big is my own box?"

Actually picking one

If an interviewer asks which CSS approach is "correct," the strong answer names the actual constraints rather than a favorite: CSS Modules for a small team with no design-system ambitions on a Next.js or Vite setup that already supports it for free; Tailwind for a team that wants to move fast and skip naming debates entirely; a zero-runtime CSS-in-JS library for a design system that needs runtime theming without the classic styled-components performance tax. Scoping guarantees, runtime cost, markup verbosity, and theming story are the four axes the decision actually runs on. Naming those four is worth more than naming a winner.