5 ms·

Performance-focused forks of styled-components

38 points by isaiahwp 1y ago

tym0 1y ago
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.
- theknarf 1y ago
  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.
- coxmi 1y ago
  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.
  - diggan 1y ago
    > 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.
    - coxmi 1y ago
      Nice to know i’m not alone, I’m sure there are dozens of us — dozens!
RedShift1 1y ago
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.
- mootoday 1y ago
  I came to post the same comment :-)!
- jeswin 1y ago
  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 1y ago
    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 1y ago
      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.
  - hu3 1y ago
    I want to invest in web components because it seems to be the next step in downscaling complexity. What's your experience with state management and data binding in Web components? Any suggestion?
- breakingcups 1y ago
  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.
reify 1y ago
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 1y ago
  You might not have a fork if you dine with philosophers ( https://en.wikipedia.org/wiki/Dining_philosophers_problem https://en.wikipedia.org/wiki/Dining_philosophers_problem )
AustinSerb 1y ago
[dead]
joduplessis 1y ago
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.
lloydatkinson 1y ago
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.
- VPenkov 1y ago
  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.
  - lloydatkinson 1y ago
    vanilla-extract accommodates this by having an API you can use at runtime if you really really want, to allow for CSS variables, which the user could then use.
- cocody 1y ago
  Hi fork author here :) I agree, the end game should be to get rid of styled-components. At Sanity we are in fact in the process of moving to https://vanilla-extract.style/ https://vanilla-extract.style/ At the same time, with thousands of styled components already in use in production, it'll take a while until they're all refactored. And so it makes sense for us to make the best of styled-components and make it as fast as it can be on the React 18 and 19 baselines, to buy us time for the larger refactor that completely solves it. TL;DR it's better to never insert CSS at runtime and only link to a cached external stylesheet. If you have brownfield code that inserts CSS at runtime that should be refactored. Until they are refactored, they should insert CSS at runtime in the best possible way (even though it's never truly good or fast).
pimterry 1y ago
Personally I've started migrating to vanilla-extract (https://vanilla-extract.style/ 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.
- cocody 1y ago
  Hi, I made the forks linked to here :D We're also migrating to vanilla-extract, huge fan of the runtime type-safety ;) The SC forks is to buy us time, Rome wasn't built in a day :)
jorams 1y ago
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.
- cocody 1y ago
  When you start out on a small app the slowness doesn't stick out anywhere. App keeps growing until one day it becomes very obvious in perf profiles. At that stage it's difficult to refactor out of it to another system, as a lot of the brownfield might've drifted into relying on techniques that can only be used when inserting CSS at runtime: - generate `@media` query selectors with ranges based on JS state and nesting. - calc background color that pass a11y contrast ratio tests based on dynamic foreground colors (for example the color palette generated from an image asset) While these have new solutions: - @container queries, no need to fiddle with global viewport size calc. - https://developer.mozilla.org/en-US/docs/Web/CSS/color_value/light-dark https://developer.mozilla.org/en-US/docs/Web/CSS/color_value... Even so, it takes time to refactor thousands of files. >It always was. You decided to make it slow and were fine with it, not sure why that's suddenly unacceptable. The decision might've been made years before you joined the organization, and you're now left with that decision and have to plan for what to do about it.
ihatemodels 1y ago
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.
blabla1224 1y ago
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.

38 points by isaiahwp 1y ago

tym0 1y ago

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.

theknarf 1y ago
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.
coxmi 1y ago
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.
- diggan 1y ago
  > 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.
  - coxmi 1y ago
    Nice to know i’m not alone, I’m sure there are dozens of us — dozens!

RedShift1 1y ago

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.

mootoday 1y ago
I came to post the same comment :-)!
jeswin 1y ago
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 1y ago
  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 1y ago
    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.
- hu3 1y ago
  I want to invest in web components because it seems to be the next step in downscaling complexity. What's your experience with state management and data binding in Web components? Any suggestion?
breakingcups 1y ago
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.

reify 1y ago

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 1y ago
You might not have a fork if you dine with philosophers ( https://en.wikipedia.org/wiki/Dining_philosophers_problem https://en.wikipedia.org/wiki/Dining_philosophers_problem )

AustinSerb 1y ago

[dead]

joduplessis 1y ago

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.

lloydatkinson 1y ago

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.

VPenkov 1y ago
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.
- lloydatkinson 1y ago
  vanilla-extract accommodates this by having an API you can use at runtime if you really really want, to allow for CSS variables, which the user could then use.
cocody 1y ago
Hi fork author here :) I agree, the end game should be to get rid of styled-components. At Sanity we are in fact in the process of moving to https://vanilla-extract.style/ https://vanilla-extract.style/ At the same time, with thousands of styled components already in use in production, it'll take a while until they're all refactored. And so it makes sense for us to make the best of styled-components and make it as fast as it can be on the React 18 and 19 baselines, to buy us time for the larger refactor that completely solves it. TL;DR it's better to never insert CSS at runtime and only link to a cached external stylesheet. If you have brownfield code that inserts CSS at runtime that should be refactored. Until they are refactored, they should insert CSS at runtime in the best possible way (even though it's never truly good or fast).

pimterry 1y ago

Personally I've started migrating to vanilla-extract (https://vanilla-extract.style/ 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.

cocody 1y ago
Hi, I made the forks linked to here :D We're also migrating to vanilla-extract, huge fan of the runtime type-safety ;) The SC forks is to buy us time, Rome wasn't built in a day :)

jorams 1y ago

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.

cocody 1y ago
When you start out on a small app the slowness doesn't stick out anywhere. App keeps growing until one day it becomes very obvious in perf profiles. At that stage it's difficult to refactor out of it to another system, as a lot of the brownfield might've drifted into relying on techniques that can only be used when inserting CSS at runtime: - generate `@media` query selectors with ranges based on JS state and nesting. - calc background color that pass a11y contrast ratio tests based on dynamic foreground colors (for example the color palette generated from an image asset) While these have new solutions: - @container queries, no need to fiddle with global viewport size calc. - https://developer.mozilla.org/en-US/docs/Web/CSS/color_value/light-dark https://developer.mozilla.org/en-US/docs/Web/CSS/color_value... Even so, it takes time to refactor thousands of files. >It always was. You decided to make it slow and were fine with it, not sure why that's suddenly unacceptable. The decision might've been made years before you joined the organization, and you're now left with that decision and have to plan for what to do about it.

ihatemodels 1y ago

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.

blabla1224 1y ago

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.