Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Performance-focused forks of styled-components

sanity.io

Post reply on HN
Print view View original

11–20 of 29 posts

Re: Performance-focused forks of styled-components

#11

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

Re: Performance-focused forks of styled-components

#12

Post by a_humean »

jeswin wrote: post #7
RedShift1 wrote: post #2

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.

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.

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.

Re: Performance-focused forks of styled-components

#13

Post by Perz1val »

breakingcups wrote: post #9
RedShift1 wrote: post #2

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.

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

"React Andies" have not seen jquery days

Re: Performance-focused forks of styled-components

#14

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

Re: Performance-focused forks of styled-components

#15

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

Re: Performance-focused forks of styled-components

#16

Post by theknarf »

tym0 wrote: post #5

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.

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.

Re: Performance-focused forks of styled-components

#17

Post by coxmi »

tym0 wrote: post #5

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.

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.

Re: Performance-focused forks of styled-components

#18

Post by jeswin »

a_humean wrote: post #12
jeswin wrote: post #7

Earlier quoted context omitted.

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.

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.

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.

Re: Performance-focused forks of styled-components

#19

Post by diggan »

coxmi wrote: post #17
tym0 wrote: post #5

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.

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 sma…

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

Hear hear. Started using BEM in like 2016, haven't had collision issues since. Not sure why people are so hellbent on doing CSS inside JavaScript when CSS by itself can do almost anything you'd want at this point, even handling basic interactions.

Re: Performance-focused forks of styled-components

#20

Post by VPenkov »

lloydatkinson wrote: post #11

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 (colo…

I'm really not a fan of CSS in JS, however it does have it's use-cases. Class mangling is very convenient with it and allows you to be prescriptive about how you're doing theming support, which is great when building libraries that 3rd parties embed on their websites.

The trade-off is that of course your customers can't style things you haven't anticipated, but it means you can control what changes are breaking.

And you can always add an extra variable in a new version if a customer wants to change a border color.

Post reply on HN