CSS modules

In the previous section, we saw a CSS-in-JS library, meaning that we had to write our CSS definitions in JavaScript, transforming those styling rules to plain CSS at runtime or compile time, depending on which library we choose and how we configure it.

While I personally like the CSS-in-JS approach, I eventually recognized that it has some significant drawbacks to consider when choosing the styling method for a new Next.js app.

Many CSS-in-JS libraries don't provide good IDE/code editor support, making things way harder for developers (no syntax highlighting, autocomplete, linting, and so on). Also, using CSS-in-JS forces you to adopt more and more dependencies, making your application bundle bigger and slower.

Talking about performance, here's another big drawback: even if we pre-generate CSS rules on the server side, we would need to re-generate them after React hydration on the client side. That adds a high runtime cost, making the web application...