[mind-blight]

I actually think a lot of CSS-in-js frameworks became popular for the same reason that React became popular: css, html, and to some extent JavaScript can't really be decoupled.

Things like CSS Zen garden made it seem like they were, but that was only a separation of control. If the HTML structure changes, then the CSS likely needs to change. That's a tight coupling.

CSS-in-js embraces the coupling and makes it explicit instead of implicit, which makes refactoring safer and speeds up development.

edit for typo

[karaterobot]

I wrote that because the benefit most people who liked styled-components told me they appreciated was that they didn't have to think about inheritance. Everything is encapsulated in the component. This, to me, is equivalent to saying "I think the cascading part of CSS is either a mistake, or too complicated to maintain in practice, so I am going to eliminate it."

[mind-blight]

> This, to me, is equivalent to saying "I think the cascading part of CSS is either a mistake, or too complicated to maintain in practice, so I am going to eliminate it."

I agree both with your interpretation, and with the sentiment. I think, in many contexts, using the Cascading part of CSS is a mistake. It's great for low-level design system kinds of work (e.g. setting matching text and BG color, then override font size or decoration later). But, it's pretty problematic when you start styling specific components in a web app. (This is less of an issue with static documents).

If we're using SASS instead of a css-in-js, we end up doing things like:

``` .my-custom-hero { h1 { // override necessary styles } } ```

That's essentially the same encapsulation. It's just hidden in a one-off class in the CSS rather than embedded with the HTML - which makes it even less legible. It also has a dependency on the root-level `h1` styles. If someone change those, they inadvertently change the hero's styles.

We could get around that by having a `.my-custom-hero .my-custom-hero-title`. But, that's essentially a worse version of css-in-js encapsulation: I have to come up with names for everything, and my component's internals are split across multiple files.

[bdougherty]

Whether you like it or not, the cascading part of cascading style sheets is an integral part of the web platform, and one is better off in the long run swimming with the current of the platform rather than against it.

[dimmke]

Agreed. I think he's completely misidentified why CSS-in-JS became a thing.

I've done a lot of thinking about this - like "How would we adopt what we have done in frameworks into web standards"? And the closest I have come up with is Svelte.

In Svelte your file is a component. It can have a <script> tag which defines state that can be passed to it or any other arbitrary javascript. You can have a <style> tag which scopes specifically to that component. And the rest is just regular HTML markup with the ability to do light interpolation for dynamic values.

That's how it should be, in my opinion. That's what we should be moving towards as an industry. I think CSS-in-JS was a side effect of JSX being in JavaScript. Hopefully we are moving away from that trend now.

[bdougherty]

I cannot agree with this comment any more. Every time I read any one of these Tailwind threads, I am yelling in my head "SVELTE!!!!" the whole time. Going against the current of the platform is a recipe for disaster every time, and Svelte is one of the few frameworks that is actually trying to go _with_ the current.