Why do we need linaria with gatsbyjs?

[kaushalyap]

Please help me to understand here!

As I know the improvements of Linaria over Styled components or Emotion are

• Remove CSS generation runtime (small JS bundle)
• No generation of CSS at runtime (faster page loads)

And Gatsbyjs is static site generator that optimize static assets at build time, so it generate style components CSS at build time.

So the my question is Why we need to use Linaria with gatsbyjs?

[JM-Mendez]

And Gatsbyjs is static site generator that optimize static assets at build time, so it generate style components CSS at build time.

I'm just a user, but here's my take:

Because after Gatsbyjs loads the initial static html with the styled-components or emotion style tags in the head, it will rehydrate with react and run as a regular SPA. This means that you still incur the cost of sending the client the bundled styling packages and parsing it on the client. On a 3g network you're looking at around 100-150ms download according to bundlephobia.

Also, if you use dynamic styling with those other libraries, you may run into performance costs due to how they manage styles. You can read this article for a deeper analysis

That being said, it all depends on your app and how you feel about the (non)issues I pointed out.

EDIT: Here's another link to read that may give you more insight for a decision

[silvenon]

So the my question is Why we need to use Linaria with gatsbyjs?

I read your question over and over again, but I'm not sure what you're asking. The overhead that comes from styled-components and emotion applies to Gatsby sites, too, so the benefits of zero-runtime CSS-in-JS libraries are the same.

I'll close this because it's not a bug report, but we can keep the discussion going.

[kaushalyap]

The overhead that comes from styled-components and emotion applies to Gatsby sites, too, so the benefits of zero-runtime CSS-in-JS libraries are the same.

I thought gatsbys build process extract CSS to separate stylesheets.

[JM-Mendez]

@kaushalyap gatsby creates static pages by server-side rendering your pages during the build stage. Therefore it can only do what packages enable for SSR.

styled-components does not do static stylesheet extraction during SSR. It only extracts the critical css and places it in style tags.

Here's an explanation from the creator of the library

styled-components/styled-components#1018 (comment)

And here's another thread with authors from both libraries providing explanations

styled-components/styled-components#2377

[kaushalyap]

it cannot do critical CSS extraction during server-side rendering, leading to (potentially lots of) unnecessary code being downloaded.

~ comment

@JM-Mendez So does the gatsbys build process split CSS bundle by route inorder to avoid unnecessary CSS loading?

[kaushalyap]

Found the answer

Regarding critical CSS extraction, but it's mostly handled if you're doing code splitting (unless a lot of conditional rendering is going on) already and isn't probably an issue with Linaria's approach due to less style duplication (as we won't generate separate rulesets if props vary for dynamic styles). But it's hard to say, because as you can see these things are very much context dependent and will vary for every app.

However, we do provide a utility to do critical CSS extraction during SSR for the cases you need, so it can do critical CSS extraction.

An extra request for CSS can be a good thing, because the request for the CSS and parsing happens in parallel to your JavaScript, which can improve performance on lower end devices with slower parsing time. It also depends on a lot of factors like the network latency, whether you're using HTTP2 etc.

~ comment

Since Linaria extracts the CSS statically at build time, you don't need to setup a server rendering. Usually, critical CSS extraction will be automatic if you are code splitting your code and using something like mini-css-extract-plugin for webpack to generate your CSS files.

~ Critical CSS extraction

Since gatsby do code splitting and use the mini-css-extract-plugin so the CSS should be also split.

[CanRau]

Just wanted to add that the StyledComponents/Emotion runtime won't be gone after SSR and some or all CSS has been inlined. They're normal and heavy JS modules which will stay in your Gatsby website as they need the runtime to do their work.

I think in Gatsby all styles will be inlined in the head, not just critical 🤔

Wasn't sure that was understood before.
Not sure if my statement is understandable though 😅

Anyway... 😁

[cometkim]

As already mentioned above, Linaria still has an advantage because it does not require an initial mount or computational cost. This is exactly what "Zero runtime" means.

---

For Critical CSS Extraction, it is recommended to analyze the actual case.

Most libraries describe it in the Server Side Rendering section, but Gatsby and Linaria both are static, so the approach should be quite different.

This means that every possible stylesheet in the app must be determined at the build time.

This is different from Emotion/SC. In Emotion, there is a runtime that manipulates CSSOM directly, hydrated stylesheets from the initial markup.

Gatsby removes the server runtime and Linaria removes the CSS runtime. If the markup can be changed at runtime, how would you import additional stylesheets not included in Critical CSS?

When I actually used it, it was helpful to inject Critical CSS, but splitting the rest of the stylesheets was rather inefficient because of the low cache hit rate.

See the current implementation for details.

[cometkim]

Gatsby's mini-css-extract configuration does not split style chunks. As far as I know, It used to do it before, but now it rolls back and uses only 'all' chunk by default for compatibility issues when using plugins.

So the option for chunk splitting is definitely a plugin's job, and most plugins don't do it at all. (ex. gatsby-plugin-styled-components, gatsby-plugin-emotion)

[cometkim]

This plugin separates a chunk for Linaria, separates the initial CSS injected into the , and asynchronously reloads whole chunk instead of the rest of the stylesheet. (This is why audit tools like Lighthouse complain about duplicate stylesheets)

Maybe there are actually some better strategies for each use case, but making it customizable increases the complexity of the plugin.