SebastianVerified account

I definitely agree with this sentiment. I'm curious what you mean by dynamic values. How would dynamic values be prevented in JS?

You can restrict them at lint or compile-time. eg. you disallow {color: generateColor()} You can also support a bunch of other stuff if the values are all used locally, for example: const baseRadius = 2; {borderRadius: baseRadius * 2}

Can you elaborate even further on the dynamic values you would ban? Would you ban CSS variables & emerging CSS color functions involving shade & etc?

If your motivation for using css in js is to remove the cascade, why not just write stricter css?

When you write CSS you still need to deal with specificity issues. I don't want to worry about correctly namespacing all of my styles. Colocation of styles with your component code is generally good. Changes are isolated to one place, dead code is removed easily.

There develops this unfortunate divide between the way styles would make sense and “performance styles”. Especially if your doing single immutable atom, it sucks to for example enforce a state for hover styles vs. using :hover.

Hover shouldn’t be considered a local state conceptually. It’s a global state. It can be modeled as such. However when I tried to optimize it, it started looking very similar to local memoization.