[abritinthebay]

> build or render-time extraction of CSS

Render-time is waaaay too late. The ship has sailed at that point: so no, that doesn't take care of your first point.

> Many CSS-in-JS libraries also handle style modularization, often in ways arguably better than CSS preprocessors.

I've yet to see one that comes even close to SASS - not even the same game let alone the same league - so agree to disagree here.

> You should take a look at: https://github.com/MicheleBertoli/css-in-js

I have - all it shows is that css-in-js is not a realistic competition for sensible modular CSS via something like SASS (CSS Modules, etc, good patterns).

[tobz]

Can you explain your rationale on the first point WRT render time being "waaaay too late"?

If your app is rendered via JS, having the CSS loaded at runtime should not matter: there's no markup to affect (repaint) and the CSS will be available before your React/etc components are rendered up.

[abritinthebay]

> if your app is rendered by JS

only if it's pure browser-side only. Which is fine I guess - at that point you've given up on rendering performance anyhow generally (especially in initial paint).

[izym]

How about server-side rendering?

[abritinthebay]

Well that that point it's slower to paint with CSS-in-JS because the browser won't have the CSS until the very last thing (after asset load, after initial paint, after content load, then after script execution).

Now you could extract the CSS with a build step... but at that point you've admitted the solution is poor (and/or you're not good at CSS) and are just mitigating it by producing real CSS by automation.

That's fine, but it's no replacement for general good practice or domain knowledge.

[izym]

Do you have any proof that it's slower or is it just an assumption?