In brief, CSS in JS libraries like Emotion and Styled Components parse and apply your styles when your page loads in the browser, whereas Linaria extracts the styles to CSS files when you create your project (e.g. with webpack), and the CSS files are loaded regularly.
On the Linaria website they say; Write CSS in JS and get real CSS files during the build. Use dynamic prop-based styles with the React bindings and have them transpire to CSS variables automatically. Great productivity with source maps and linting support.
Linaria is unusual in that it does not require a runtime to function. Styles are processed, assessed, and produced at build time, so no additional processing on the client is required.
When using component-based CSS in JS libraries, displaying the same component with various props might result in numerous instances of the same set of styles. It has no effect on the client, however, it may increase the size of the rendered CSS when using SSR. It may not be seen in most situations, but when rendering a long list of components with minor changes in style, it can soon mount up.
Furthermore, when you use SSR, the rendered CSS is downloaded in addition to the CSS you wrote in JS files, which increases the size even more.
Linaria generates only one rule set per declaration, and differences are handled with CSS variables, so there is no repetition, which is fantastic for lowering bundle size.
Since Linaria works at build time, you don’t need to have SSR set up to improve the time to first paint or for your page to work without JS.
Linaria, unlike some CSS in JS libraries, allows you to use regular CSS syntax, which means you can copy and paste styles from the browser's dev tools (or StackOverflow) while avoiding needless noise in the styles.
If you want, you may use a preprocessor like Sass.
Linaria removes unneeded styles from a file unless it is exported. Linters such as ESLint may also alert you about unused styles because they are just JS variables.
One of the solutions to improving lost performance time due to double parsing is that the libraries should convert the CSS-in-JS block into a separate .css file first. Then, the browser will read and apply those styles to the webpage, ultimately saving runtime that’s typically wasted while generating a style tag. This is called zero-runtime CSS-in-JS. It is particularly useful for scaled or complex projects where performance is key.
If you care about static or prerendered webpages (for example, Gatsby), Linaria may be a better alternative for your static output.