The Styling Toolbox, Evaluated
Styling a modern web project means choosing from an ever-widening range of approaches. A recent overview in the context of Next.js touches on all the major possibilities, but the options themselves apply well beyond any single framework. Here is a practical look at where each method stands.
Plain CSS: The No-Build Baseline
If your project can get away with it, regular CSS remains a strong default. No build tooling means no extra complexity, and the syntax will age gracefully. The one genuine pain point is the inability to nest media queries inside selector blocks, a convenience you only really miss once you have used a preprocessor.
Preprocessors: Sass, Less, Stylus, and PostCSS
Sass has been around long enough to be embedded in a wide range of tools, so choosing it does not always imply the same setup. A minimal integration can be as simple as a sass --watch src/style.scss dist/style.css npm script. Once you accept that a build step exists, you can also start concatenating files, minifying, and busting cache—tasks you will likely end up doing anyway.
Less and Stylus never quite reached the same level of adoption, which is somewhat surprising given their long-standing Node compatibility and feature-rich nature. Sass, however, is more ubiquitous and actively developed, and its canonical implementation now works natively in Node environments.
PostCSS takes a different tack: rather than offering a fixed feature set, it lets you assemble the processing pipeline yourself. That flexibility has a downside—the process of writing CSS can end up inconsistent across projects. There is also the issue of preprocessing away modern features that cannot truly be polyfilled, like custom properties. Still, its ecosystem gave us Autoprefixer, which was invaluable when prefixing was a daily necessity.
Component-Scoped Styles: CSS Modules
Built on PostCSS, CSS Modules solve a real problem for component-based architectures: they scope styles to a specific component. That is an incredibly useful idea regardless of the framework you use. CSS Modules can also be written as Sass, giving you scoping and preprocessor features together.
CSS-in-JS: Mostly a React Concern
When people say CSS-in-JS, they usually mean CSS-in-React. Frameworks like Vue, Svelte, and Angular each have their own preferred way of handling styles—React is the un-opinionated one, leaving you to pick from a long list of libraries such as styled-components, styled-jsx, and Emotion. The appeal is clear: automatic scoping and the ability to incorporate props into styling decisions, which can be powerful for design systems. That said, using Sass plus CSS Modules in React projects also works well.
The Utility-First Trade-Off
Going all-in on utility classes brings some real advantages: smaller CSS files and styles that are consistent yet still flexible. The trade-off is that markup becomes crowded with dozens of commingled classes, which makes the HTML harder to read and refactor. It is not for everyone, but the benefits clearly resonate with many teams.
