10 comments

[ 3.0 ms ] story [ 26.1 ms ] thread
Maybe CSS in JS was the wrong thing to begin with. Your developers were so preoccupied with whether they could, they didn't stop to think if they should.
Does this mean I can eat 40% faster when I use a fork.

if so, I shall set the dining table without knives.

there is no spoon!

Haven't written frontend in a few years but honestly for me CSS Modules solved the scoping issue and all the CSS in JS/Tailwind stuff since then feels like a red herring.
CSS-in-JS is possibly the worst idea to come out of the last 10 years of frontend. Saying that as someone who has written a lot of CSS-in-JS code.
I normally refrain from commenting on anything regarding CSS, styling, and design systems as I feel that HN in particular has disingenuous debates on it.

Rather than using a fork, you could completely remove the “style sheets at runtime” part by using a CSS in TypeScript tool which builds everything and produces plain CSS files and CSS variables.

There are at least four main benefit:

- Can enforce design tokens (colours, spacing, whatever) with type safety

- The previous point helps enforce and encourage design consistency; I have lost count of the amount of times I’ve seen lazy “just append some more unmaintainable mess” at the bottom of CSS files

- CSS is built at build time which is what you are already familiar with if you’ve used a CSS preprocessor before

- Smaller file sizes sent to the users browser

Oh and one final thing: vanilla-extract is not just for React, its standalone meaning you can use it even with something entirely server side if you wished.

Personally I've started migrating to vanilla-extract (https://vanilla-extract.style/): syntactically & conceptually similar to SC, relatively easy migration and lots of the same advantages, but entirely precompiled with zero runtime and nicely framework & tooling agnostic.
Sounds like a good development, but some statements in the post are a bit odd to me:

> Your app has styled-components. That's not changing today. But it doesn't have to be slow while you figure out tomorrow.

It always was. You decided to make it slow and were fine with it, not sure why that's suddenly unacceptable.

Thanks for fixing Styled-Components.

I ditched Emotion, a very similar solution, since it doesn't work with Next’s App Router, and while looking for a replacement (styleX, Griffel, Vanilla Extract…), I discovered that Styled-Components can be compatible with the App Router.

Why stick with Styled-Components? Because I want to write CSS, not JavaScript objects like most alternatives impose. I understand the typing advantages, but the readability loss just isn’t worth it.

I also use classNames, scoped to each component, it works fine. So why would I replace classNames with JavaScript constants? Again, proper CSS syntax is enough.

I was hoping YakJS would be a complete replacement for Styled-Components, but they don’t support classNames & global styles.

CSS-in-js is one of the best things that happened to the web over the last 10y. And no, this is not for web documents which many call “apps” these days.