That wasn't how "CSS-in-JS" was sold to me, and obviously, does nothing to actually solve that, scoping works the same in CSS regardless if you generate it from JS or not.

The way it was sold to me, was that developers were tired of having to have the styles in a different place than the layouting, and CSS-in-JS would make all of that worth it, even when you consider the performance tradeoff.

I was never sold on it, and continued doing CSS in separate files, mostly following something like BEM most of the time, and still am not affected by scoping issues, and I didn't even need to do the tradeoffs you get when doing CSS-in-JS.

I don’t remember who said it but I really like this summary: posting LLM slop as your own writing destroys the reader/writer contract. Normally you’d expect the writer to have spent more effort on a piece than the reader. But now the reader is the one who’s spending more effort, trying to interpret a chain of words from nobody’s mind.

This should be embarrassing to post.

does anyone know, scoped style rules are here to stay or not? <style scoped> is deprecated and in HTML spec <style> is not allowed in body https://html.spec.whatwg.org/multipage/semantics.html#the-st...

(This is how I suspect it's LLM slop, it's such an important thing and it just is skipped without mention)

IMO it delivered said simplicity, and the performance issues are there, but they've never been the lowest hanging, biggest fruit to optimize. Not even close in my experience, which for me indicates a resounding success. And as a result, more "native" CSS solutions like Tailwind improved the native CSS landscape. So, wins all around for everyone: you can stick with CSS-in-JS and take the almost always practically invisible performance hit, or use newer solutions for improved ergonomics and performance.