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 a day ago | parent | next [-]

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 5 hours ago \| parent [-]
		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 a day ago | parent | prev [-]

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/

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