Hey folks!
Thank you for opening this thread @furrysmile2, much appreciate it.
I believe @mmczaplinski and @luisherranz are summarising really well, what should look after when trying to choose how one should style a project.
Frontity is server side rendered, that means for each page, you’re gonna send only the css used + the global one, in the same http request trip. If you would use a compiled time styling library, you would either have to load the css file in it’s entirety, which is render blocking, or have to do the method that the linaria project is suggesting:
import { collect } from '@linaria/server';
const css = fs.readFileSync('./dist/styles.css', 'utf8');
const html = ReactDOMServer.renderToString(<App />);
const { critical, other } = collect(html, css);
// critical – returns critical CSS for given html
// other – returns the rest of styles
Source: https://github.com/callstack/linaria/blob/master/docs/API.md#collecthtml-string-css-string--string
This might be working fine, but if one looks closely, you would notice that on the server you are actually reading a css file on disk, and then scan the resulted html for the used classNames. This, in my opinion, it is really undesirable.
I wished the author of the article you’ve linked to, would have posted the source of the test or a link to the repo. There are a couple of red flags in the screenshots that I think needs to be checked before any claim. One thing that I do believe he is right about, is the use of css variables. Makes total sense and I do believe should be encouraged.
I wanna (re)assure you that the CSS-in-JS ecosystem is strong and has a solution to every performance bottleneck there is . With that being said, emotion, is one of the top-notch libraries out there with really optimised runtime.