[stevebmark]

I don't get it. CSS Modules are designed to be combined with global utility classes. Using mainly utility classes is some OOCSS shenanigans we stopped doing literally decades ago. And CSS-in-JS has worse performance because styles aren't compiled to sytlesheets like they're supposed to be, they're applied at runtime. Downloading JS > parsing JS > executing JS > generating stylesheets > injecting stylesheets in to the DOM dynamically > repaint + reflows is how you get poor performance.

CSS is a solved problem and that solution is CSS modules with global utility classes compiled to static stylesheets.

[jakelazaroff]

> And CSS-in-JS has worse performance because styles aren't compiled to sytlesheets like they're supposed to be, they're applied at runtime.

That depends on the tool. Libraries like Linaria [1] ("zero-runtime" CSS-in-JS) do generate CSS files.

[1] https://linaria.dev

[steve_adams_86]

I liked linaria at first, but it has been a huge headache and my team is eager to get away from it now.

A lot of helpful strategies like lazy loading components and inlining critical CSS are incompatible with linaria and cause very strange breakage due to changing precedence as components are loaded.

It's an awesome library when it works with what you need, but it's been a compatibility nightmare for us. So many popular tools in the JS ecosystem are a headache to get working with it.

[toastercat]

I explored this a long time ago, but after a while, I was like "what's the point" and just went back to CSS Modules. I'll just write more classes and have a separate file in my directory if it means not adding even more shit that can break in my project.

[have_faith]

Zero runtime css-in-js feels like the natural progression. It combines the best of both worlds and is very flexible, bring your own design system instead of relying on your css implementation to decide on one for you ala tailwind.