CSS-in-JS vs SCSS vs CSS Modules for Next.js Component Libraries

Choosing between CSS-in-JS vs SCSS vs CSS Modules for a Next.js component library is not only a styling preference. It affects server rendering, bundle size, theme behavior, debugging, and how developers customize components.

Each option can work. The best choice depends on what your library promises.

CSS-in-JS

CSS-in-JS can be powerful because styles live close to component logic. Some solutions support dynamic styling, theme objects, variants, and colocated component APIs.

The tradeoff is complexity. In a Next.js App Router project, runtime styling can interact with server rendering, streaming, and hydration. Some libraries require careful setup to avoid style ordering issues or flashes.

CSS-in-JS can be a good fit when:

• Your library depends on runtime theme objects.
• Component variants are highly dynamic.
• Your team values colocated styles.
• You are comfortable with framework-specific setup.

It may be less ideal if you want simple compiled CSS output and low runtime styling overhead.

SCSS

SCSS remains a strong option for component libraries because it offers structure without hiding the platform. Variables, mixins, maps, nesting, and modular files help organize large style systems.

For themeable libraries, SCSS pairs well with CSS variables. SCSS can define component structure, while CSS variables allow runtime themes to change without recompiling.

SCSS is useful when:

• You want inspectable CSS output.
• You need shared tokens and reusable style patterns.
• You want styling that works across React and Next.js packages.
• You prefer theme APIs backed by CSS variables.

The tradeoff is that dynamic behavior belongs in React props and CSS variables, not in runtime style generation.

CSS Modules

CSS Modules provide scoped class names with a familiar CSS authoring model. They are easy to use in Next.js and reduce accidental style leakage.

For application components, CSS Modules are often excellent. For a reusable component library, they can work well if the library controls the build pipeline and exposes the right class hooks.

CSS Modules are useful when:

• You want local scoping.
• You prefer plain CSS semantics.
• You are styling page-level or component-level modules.
• You want minimal runtime behavior.

The limitation is that CSS Modules do not provide the same design-token organization as SCSS by themselves. They can be paired with CSS variables, but larger systems may still need extra structure.

Themeability in Next.js

Themeability is where these choices become more than syntax.

A Next.js component library should avoid theme flashes and hydration mismatches. That usually means theme attributes and CSS variables need to be available early in the render path.

For that reason, a compiled CSS approach with runtime variables can be very effective. It keeps CSS available to the browser while letting the app switch themes through attributes, classes, or provider state.

What Boreal UI chooses

Boreal UI uses SCSS-powered styling and theme variables because the goal is an installable React and Next.js component library with accessible defaults and predictable customization.

This approach keeps component styles organized, makes output inspectable, and gives product teams a practical way to customize tokens, surfaces, states, and layouts.

The practical answer

Use CSS-in-JS when your system needs deeply dynamic runtime styling and your team accepts the setup cost.

Use CSS Modules when you want scoped styling for app components or simpler library pieces.

Use SCSS when you want a structured styling layer for a reusable component library with theme tokens, compiled output, and broad customization.

For Next.js component libraries, the best styling model is the one that supports server rendering, theme control, and long-term maintainability without surprising the teams who use it.