[andrewingram]

You linked to server side rendering, not static extraction of styles, did you mean something else?

The point of static extraction (something the current wave of new CSS-in-JS libraries seem to be focusing on), is to generate all the style sheets at build time and serve them as regular CSS files — so that your styles don’t inflate your JS bundles (a problem most older CSS-in-JS libraries have).

[jonorsi]

SSR would extract all the styles out for the styled components, but I guess now it would have an advantage as all the html/js would be as well.

My point is, the comparison seems more “js runtime stylesheets” vs “regular static stylesheets.” Styled Components, or CSS-in-JS, isn’t really the main focus here. There are options to get the static stylesheets generated, and I predict most CSS-in-JS frameworks will eventually provide the tools to do so.

[andrewingram]

With conventional CSS-in-JS solutions like emotion and styled-components, SSR with these libraries still extracts the stylesheets at run-time, so it's not static extraction -- where the extraction is done at build-time. And your style definitions still live in your code bundles -- inflating the size.

Both emotion and styled-components have dabbled in supporting static (build-time) extraction, but it's actually a hard problem to solve when you have such flexible APIs. The libraries that have cropped up to support this notion of near-zero runtime CSS-in-JS (Linaria, Astroturf, vanilla-extract, and more) do so by providing tighter constraints surrounding what you can and can't do.

[jonorsi]

SSR (at least with Gatsby) extracts the styles at build-time.

[andrewingram]

styled-components can do automatic injection of critical CSS into the page HTML, but doesn't do static extraction of stylesheets.