How does goober compare to linaria?

[cfuendev]

Today I was checking out some CSS-in-JS solutions, since I am working on my own, and I wanted to explore the pros and cons of each solution available right now, including their bundle size.

I have known goober for very long, and have been always impressed at how small the library is, always regarding it as the smallest CSS-in-JS solution. However, I checked emotion's bundle size on bundlephobia today as part of my research, and saw it weights a whopping >200B min + gzip. Okay I'm changing the purpose of this PR, because I just did some further research and found out that emotion doesn't actually weight 200B. If you're using the cross-framework approach (Which is like goober's css macro available to use in vanilla js), you're adding the same 5KB min + gzip that previous versions of Emotion have always been shipping.

Is the library doing some trick with the dependencies to achieve this number? Or is it really THAT small after various versions weighting 5.8kb min + gzip? It's now clear that the "emotion" package on npm (Which is probably just a monorepo or something like that) weighting 200B doesn't mean anything. However, I still want to take advantage of this PR to ask how goober would compare to another competitor I discovered during my investigation - Linaria. The @linaria/core package, which is the package where you retrieve a css macro from (Just like the goober package) weights a whopping 400B! So I'd love if someone could explain how this compares to goober. I think this is information that should be in the README's comparison chart, by the side of goober's comparison against Emotion and styled-components.

[B-Teague]

Linaria’s main key feature is zero runtime cost by replacing dynamic values with css variables and generating css files during the build process. You can achieve similar results with goober using extractCss for server side rendering and caching the results.

[cristianbote]

@B-Teague is spot on! Thank you for answering it.

@cfuendev there are two kinds of libraries:

• they work at build time (when you compile your code) and add a tiny little layer of 400B in this case
• they are doing everything at runtime, like goober does it

[cfuendev]

Thanks @B-Teague & @cristianbote, that clears everything out a lot!

Now that I understand both libraries better, I think that shipping my library (Which only supports transpiling a specific syntax to in-lineable css and will require a separate library as a back-end to achieve full CSS-in-JS capabilities) with integrations for both linaria and goober would be a nice approach.

But for now, working with goober is enough. Thanks for the insight!