Breaking up with CSS-in-JS

I’d been working and re-working a post for some time on my falling out with CSS-in-JS, particularly Emotion and Styled Components, but I think this article from Sam Megura says nearly everything I wanted to, and with data to back up their claims. Basically the cost to users (in runtime performance) of these libraries outweighs their DX benefits.

I would add one more general criticism, which is that these libraries are way too opinionated. It’s not just the wild idea of writing all your CSS in JS template literals. It’s that they dictate how CSS is loaded in the browser (e.g. as a bunch of <style> tags). And that they are incompatible with established configuration and build tools like browserslist, autoprefixer, postcss, and webpack. I’ve come to much prefer the humble tool that solve one or two problems and leave others to do the rest. (CSS Modules comes to mind as one example.) Such tools acknowledge implicitly that not all developers or projects have the same needs, that offramps are necessary and don’t have to be painful, and that gradual progress and consensus are preferable to moving fast and breaking things.