Wow. I mean I’ve seen some outlandish takes about CSS-in-JS but this is pretty surprising to me. Most, not all but most, CSS-in-JS is written as plain CSS or a

Wow. I mean I’ve seen some outlandish takes about CSS-in-JS but this is pretty surprising to me. Most, not all but most, CSS-in-JS is written as plain CSS or a Sass-like superset, in a tagged template literal. Where it’s not that, it’s typically written as the equivalent but with camelCase in a POJO. Effectively the same thing with minor syntax differences. In a few other cases it’s written in literal style tags. In nearly all cases, the styles are not inlined at all. They produce one or more classes which can be applied to an element. None of that is a fuck-it solution. You might not agree with the benefits, but to people who prefer it those are: - Colocation of styles and usage, which aids understanding how or whether styles are applied (and could help correct cases like the example early in this article) - Composition with clear semantics - Language and tooling integration of various levels beyond referencing arbitrary CSS - Build-time optimizations that allow extraction or inlining or code splitting, as appropriate for the project I have no ill will toward Tailwind or any other “atomic CSS” solution, but I suspect more of your points apply to that particular approach than anything to do with CSS-in-JS. (Except Fela, which I quite like for some use cases, but by default has output similar to the complaints raised by the article.)