CSS-in-JS: The Great Betrayal of Front End Sanity(thenewstack.io)
thenewstack.io
CSS-in-JS: The Great Betrayal of Front End Sanity
https://thenewstack.io/css-in-js-the-great-betrayal-of-frontend-sanity/
16 comments
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.
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.
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 should be embarrassing to post.
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.
The article is certainly shallow, and its title is clickbait, and it says things that will make some web developers roll their eyes, and of course LLMs are now available to anyone — but what makes you think this particular article was written by an LLM? What are the telltale signs?
It’s more of a vibe, as they say :) Things that cumulatively feel off: overly descriptive headers, overuse of flowery language (“we’re entering a new age where A is B, where X coexist peacefully with Y”). Lots of “isn’t X but Y”, “not X, just Y”. In general the rhythm and the tone is a tell (authoritative and scoldy but vapid and bland at the same time).
I am a former D-list tech blogger, and the thought of posting slop under my name horrifies me. But then again, I consider myself an author who has enjoyed the pleasant side-effect of minor notability. I never considered myself an influencer who happened to use writing to acquire more influence.
Anybody shipping slop around—whether written by interns and published under their name or written by machines—is not an author. They are an influencer, and reposting slop is what they do.
Anybody shipping slop around—whether written by interns and published under their name or written by machines—is not an author. They are an influencer, and reposting slop is what they do.
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.
The Great Betrayal of Front End Sanity 2: JS-in-CSS
> We’re entering a new chapter where simplicity is sophistication again, where global stylesheets coexist peacefully with scoped rules.
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)
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)
> does anyone know, scoped style rules are here to stay or not?
There is the @scope CSS directive. It is part of the CSS spec now. MDN even says it is supported by all latest browsers.
> in HTML spec <style> is not allowed in body
Parts of the body can be encapsulated in the shadow DOM; and the shadow DOM allows its own <style> tags.
There is the @scope CSS directive. It is part of the CSS spec now. MDN even says it is supported by all latest browsers.
> in HTML spec <style> is not allowed in body
Parts of the body can be encapsulated in the shadow DOM; and the shadow DOM allows its own <style> tags.
Thanks. That's a JS-only thing then right?
The style tag inside of a shadow DOM? No, it can be written declaratively in plain html markup.
if you need JS to actually use shadow dom then this sort of scoped styling is JS only
can't die soon enough, if i have js disabled by default it messes up some websites
This is completely meaningless AI slop. No mention of tailwind, no real nuance. This is embarrassing.
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.