Performance-focused forks of styled-components

tym0

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.

coxmi

I’d go further than this and say globally-scoped CSS is fine as long as you’re using a decent naming pattern (e.g. BEM), or @layers.

For me, back in the JQuery days, the problem was always globally-scoped JS/DOM, rather than CSS. The big revolution was simply co-locating/importing styles in JS modules during the compile step, which works surprisingly well even outside of any framework.

Just using vanilla DOM or a small wrapper around web components for connectedCallback/disconnectedCallback logic is refreshingly simple. It’s quite sad that most SSR frameworks don’t allow this sort of approach, and lock you in to a specific front-end library.

theknarf

I've always thought CSS Modules was the best solution as well, having worked a lot with Tailwind its entirely okay, but "CSS in JS" was always a bad idea from the get go.

pimterry

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.

joduplessis

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.

jorams

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.

RedShift1

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.

breakingcups

I was about to say the same. Having lived mostly in Vue land, this quote felt astounding to me:

"The React team themselves have made it clear: runtime CSS injection will always be slower than statically extracted styles. They recommend using <link rel="stylesheet"> for static styles and inline styles for dynamic values. That's the future."

I thought this lesson was already widely learned since the jQuery days.

Perz1val

"React Andies" have not seen jquery days

jeswin

It might seem like a terrible idea now. But when it was first introduced, a) people were still trying to get CSS and Components to work together, React having made components quite popular; and (b) React was actually usable, compared to the complete mess it's become now, especially after they introduced hooks.

I switched to web components for all my personal work.

a_humean

But we already had things like tachyons css (tailwind precursor) and webpack css modules at the time that both offered static stylesheet solutions to that problem.

jeswin

They weren't great either in hindsight.

But more importantly, we need to explore different paths to figure out what doesn't work. Things which seem like bad ideas in hindsight aren't bad experiments to run - otherwise we will all learn nothing.

mootoday

I came to post the same comment :-)!

lloydatkinson

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.

AustinSerb

[dead]

reify

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!

dalf

You might not have a fork if you dine with philosophers

( https://en.wikipedia.org/wiki/Dining_philosophers_problem )