Why I Write CSS in JavaScript

I don't entirely understand why some people find CSS so difficult to work with. I agree that it has its own challenges, but solutions generally aren't very complex. Global selectors ("variables") collisions? Use namespacing. Specificity is convoluted? Simplify by using only non-nested classes.

Does the annoyance primarily center around the fact that styles cascade to child elements? Hard to tell from the article.

When my styled-components app is in prod, the styles are non-editable. When developing, I can use Chrome Dev Tools. On prod, I have to copy paste. Maybe I'm doing something wrong?

It is absolutely a limitation, because there are things you can express in other languages that you cannot in CSS.

But a limitation isn’t necessarily bad, and is often good. Finding the language of least power (ie it is just powerful enough to express the sorts of things you want, and no more) is very useful for safety and productivity, but in CSS’s case it seems like it’s no longer powerful enough to express all the things its users desire.

I feel like a lot of this boils down to a variation on Greenspun's Tenth Rule: "Any JavaScript-centric web development framework contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a web browser."

"I can add, change and delete CSS without any unexpected consequences. My changes to the styling of a component will not affect anything else. If I delete a component, I delete its CSS too."

This is readily achievable with ordinary CSS. Selectors by ID/class have existed for multiple decades. A Ctrl-F for said ID/class name should be pretty painless to do even in the case where you're doing everything in one giant spreadsheet (though in this day and age of CSS preprocessors, no reason why you couldn't have widget.js and widget.css, the latter of which gets compiled into the final spreadsheet as part of the build process).

"Never go on a hunt for CSS affecting your components ever again."

I'd hardly call Ctrl-F a "hunt". JavaScript can't fix bad code hygiene/organization.

"I cannot expect all team members, particularly juniors, to have an encyclopedic understanding of CSS."

So you expect them to have an encyclopedic understanding of your CSS-in-JS library instead, then?

Or perhaps it'd me more reasonable to be okay with looking things up every once in awhile?

"With CSS-in-JS, we automatically sidestep common CSS frustrations such as class name collisions and specificity wars."

I'm curious how much these are actually problems in the first place (or at least problems inherent in CSS itself), and how a CSS-in-JS framework expects to solve them without completely reinventing the browser's styling engine.

"This leads to a marginally slower time to interactive, but a much quicker first meaningful paint!"

If you didn't try to do everything with a giant blob of JS, you wouldn't have to do these kinds of ridiculous tricks to reduce time-to-first-paint.

"Send only the critical CSS to the user for a rapid first paint."

If the CSS is not critical, then it shouldn't be sent at all. No reason a backend framework couldn't selectively send only the CSS relevant to the HTML being sent.

"Simply style your components with a global theme or based on different states."

So difficult.

"CSS-in-JS combines all these benefits into one handy package and enforces them."

Yes, at the cost of needlessly reinventing stylesheets and making it significantly more difficult to modify the styles downstream (e.g. for accessibility reasons).

"Thousands of companies use CSS-in-JS in production [...] (including this website)"

As an experiment, I switched JS off for that page and refreshed. The styling certainly doesn't seem to be happening client-side. Instead, the HTML source contains a bunch of obfuscatedly-classed divs and a giant obfuscated stylesheet in an inline tag.

Surely JS is not specifically needed to achieve this result. This could've been done with CSS-in-Python or CSS-in-Ruby or CSS-in-C or CSS-in-Lisp or CSS-in-COBOL or CSS-in-Brainfuck or whatever. It also could've surely been done with a dedicated language-agnostic CSS preprocessor. Further, it could've been done the "hard" way (not really hard at all) with CSS selectors alone (since that is indeed the end result).

I don’t really understand this comment. Emacs lisp always had dynamic scoping, which is a bit more than just global scope because you aren’t quite stomping on top of other variable bindings. You get resetting your bindings to what they were before you started for free and you don’t need to worry about nonlocal exits. Emacs lisp also has macros and gensym to avoid some of the pain of name clashes.

Emacs lisp also has lexical scoping. It optionally had it for a long time using cl.el with lexical-let and friends. It now has it as a file-local variable read by the compiler/interpreter.

I also don’t understand what you’ve written at all. You say “Nowadays it does support semantic scoping” but semantic scoping isn’t really a thing (as you next write lexical scoping, I assume you mean dynamic scoping), but the words “nowadays,” “but,” and “still” imply that you are talking about the new kind of scoping (ie lexical) and comparing with the old (dynamic, which you cal lexical???).