Comment by karaterobot | Hacker News Reader

Comment by karaterobot | Hacker News Reader

Parent Full thread

Pretty much every CSS framework I've ever seen (and certainly every CSS-in-JS solution I've ever seen) has as its underlying premise "we know you hate CSS, and want to avoid thinking about it as much as possible". For people like me (and perhaps you) who actually like CSS, our reaction is "why would I ever want to use something that abstracts away the power and flexibility of a thing I enjoy using?"

The problem is that I think we are outnumbered. Most engineers want to avoid CSS, pretend it doesn't exist, and if all else fails, build a complicated mech suit they can climb into to manipulate it without coming into contact with it directly. That's why things like Tailwind and Bootstrap and CSS-in-JS solutions took off.

My solution on the teams I worked with was to say "hello, I will do all of the CSS in the entire application if it means we don't have to add another dependency just to indulge the team's distaste for CSS."

Near the end of my career I was pretty much just doing CSS all day. I liked it, but probably what I did was create a terrible situation for whoever came after me. They still hated CSS, were bad at using it, but now had to maintain a lot of it. We probably should just have consented to the convenience of the majority even if (as I still maintain) they are wrong.

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

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.

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.

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."

> 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.

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.

> Pretty much every CSS framework I've ever seen (and certainly every CSS-in-JS solution I've ever seen) has as its underlying premise "we know you hate CSS, and want to avoid thinking about it as much as possible". For people like me (and perhaps you) who actually like CSS, our reaction is "why would I ever want to use something that abstracts away the power and flexibility of a thing I enjoy using?"

I don't find this to be the case with styled-components. To me styled components feels just like writing CSS (which I like), but with a slightly obscure variable syntax (if I need a prop or theme value).

Reply on news.ycombinator.com