7 ways to deal with CSS

CSS stops being “just fundamentals” the moment a real app grows: naming collisions, cascading side effects, and bloated stylesheets quickly become painful. With Next.js and React, there’s no single universal fix—so the practical answer is choosing among several approaches and accepting their trade-offs.

The most basic option is global CSS, where styles apply across the entire app. It can work for small projects, but it scales poorly. Cascading makes class naming harder, often pushing developers toward conventions like BEM and frequent use of overrides such as `!important`. Global styles also tend to inflate bundle size, which can slow page loads.

Next.js offers a more scalable default: CSS Modules. These look like regular CSS but scope class names to a specific component, preventing collisions when multiple components define the same class. Because Next.js can load only the CSS needed for a given page, it can reduce the amount of CSS shipped to the browser. When sharing styles becomes necessary, Modules support a `composes` property to import and override rules from other modules.

If the goal is more “programming-like” CSS, preprocessors such as SCSS add variables, mixins, and functions by compiling to plain CSS. SCSS is a superset of CSS, so developers can keep familiar syntax while gaining concision and reuse. The downside is that it introduces a separate language layer and remains decoupled from the application’s JavaScript logic.

That gap is where CSS-in-JS libraries come in—tools like styled components, emotion, jss, and styletron—letting developers write CSS inside JavaScript. This unlocks dynamic styling tied to application state and gives access to full JavaScript capabilities. A homegrown example mentioned is `style.jsx`, which uses a `style` tag with a `jsx` attribute and template literals to compute/interpolate style values directly. Like CSS Modules, these styles are scoped to where they’re defined, reducing unintended bleeding.

For faster UI building, utility-first styling is another route. Tailwind (and Windy CSS) provides large sets of utility classes so developers can assemble designs quickly, often with IDE autocomplete. Tailwind also supports purging unused CSS to keep bundles lean. The trade-off is that component markup can become cluttered, and the approach requires committing to a particular organization style; it also doesn’t ship pre-built UI components, so more work may be needed.

Finally, there are component-oriented frameworks and design systems. Bootstrap and Bulma provide pre-built components like buttons and cards with minimal setup, but importing their styles can include lots of unused CSS unless additional steps are taken. A more integrated alternative is full component libraries such as Mantine, which combines styling with utilities and even JavaScript-adjacent features (e.g., hooks for the Intersection Observer API, plus tools for modals, notifications, and calendars). These systems are often opinionated, so picking one that fits a team’s preferences matters.

The overall takeaway: the best CSS strategy in React/Next.js is often a mix—CSS Modules for scoping, SCSS or CSS-in-JS for reuse and dynamism, Tailwind for speed, and component libraries for ready-made UI and richer behavior.