I see development teams stuck in endless migration cycles all the time. One week it’s Global CSS, the next it’s CSS Modules, and suddenly everyone wants to jump on the Tailwind or utility-first bandwagon. Sometimes these shifts are just about preference, but more often, they happen because of a specific kind of friction that no one has quite put a name to yet.
Features like HMR (Hot Module Replacement) give us this sense of freedom while we're styling, but the architecture you choose determines whether editing stays lightweight or turns into a massive headache six months down the road.
To be honest, no approach is perfect; every method has its downsides.
With Global CSS, everything comes down to the cascade and specificity. It’s incredibly easy to start, but the "tax" you pay is the risk of class collisions and an accumulation of dead code that’s nearly impossible to prune. CSS Modules solves the collision problem because every file has its own scope, but it requires much more discipline in how components share styles.
Then there’s the utility-first approach. Instead of sweating over naming every tiny element, you just grab existing small classes and go. It’s lightning-fast for layout iterations, but if you don't have a solid component system in place, your HTML can get incredibly messy.
I’ve put together some notes to help decide when you actually need to switch, rather than just following a trend.
Move from Global to Modules if your team is constantly running into style
conflicts—for example, when two different features both use a .button class
and end up breaking each other. It's also time to move if new developers are
constantly confused about where to actually put their CSS. But if you're just
building a small landing page, don't bother with the overhead of Modules.
Switch to utility-first if you feel like half of your CSS modules are just wrappers for unique spacing or colors. If the team is exhausted from constantly making up class names just to handle a layout, that’s a sign. However, it makes much more sense to do this only if you already have a mature design tokens system ready to go.
You can even move back to Modules or plain CSS if your component classes are becoming paragraphs long, or if you need complex animations that feel forced when using only utility classes.
The bottom line: don't just look at what's trending on Twitter. Look at your team, look at the product, and check if your current workflow actually makes sense or if it’s just starting to hurt.
Cheers.