CSS-in-JS: A Better Utility, or a Step Back?
Brent Jackson, creator of Basscss, argues that CSS utility libraries have a fundamental flaw: they break down when developers need one-off styles that aren't in the library's repertoire. Without a clear extension path, teams fall back on inconsistent hacks and append-only stylesheets.
Eventually, you’ll need to add one-off styles that just aren’t covered by the library you’re using, and there isn’t always a clear way to extend what you’re working with.
That critique may not sit well with Tailwind's devotees, who seem fiercer than the early Basscss/Tachyons crowd ever was. Jackson's follow-up is that CSS-in-JS solves the same problems more cleanly.
CSS-in-JS libraries help solve a lot of the same issues Utility-based CSS methodologies were focused on (and more) in a much better way. They connect styles directly to elements without needing to name things or create abstractions in class selectors. They avoid append-only stylesheets with encapsulation and hashed classnames... Many libraries also include CSS performance optimizations, such as critical CSS, enabled by default.
The "one step back" in his title is that CSS-in-JS is more open-ended, potentially undermining consistency. Jackson's claim is debatable: in a component-based architecture, consistency tends to follow naturally, even before layers like design tokens enter the picture. And CSS-in-JS encourages those patterns anyway. The direct link to his full post is below.
