> CSS-in-JS was supposed to free us from global namespace nightmares and styling spaghetti.
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’m so tired of reading LLM slop articles. I don’t mind someone using AI assistance but it should be embarrassing to put your name next to something you so obviously didn’t write.
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 article focuses a lot on runtime computation of css-in-js but much of css-in-js today is compiled (no runtime computation). Ignoring that fact feels disingenuous. There are still arguments to be had against css-in-js for readability, sharing, and complexity, but the amount of focus on something that was solved is bad.
I'm still using emotion CSS-in-JS and I love the Developer Experience. I love being able to create styles in separate files or inline. I can understand the drawbacks in performance/hidration and lack of support from SSR frameworks like Next/Remix, but the DX for me is just too good compared to the new generation of new CSS tools.
> CSS-in-JS promised simplicity but delivered performance issues.
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.
9 comments
[ 2.9 ms ] story [ 27.4 ms ] threadThat 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.