Performance implications of CSS-in-JS solutions

[samuelcastro]

CSS-in-JS solutions like Emotion have performance implications, which is essentially the js runtime parse to convert js into className.

I'm considering other solutions like Linaria and even Tailwind CSS.

I think this is something that could be improved here as well to improve performances in general.

Related topics:

• https://daily.dev/blog/why-i-moved-from-styled-components-to-tailwind-css-and-whats-the-future-of-css-in-js
• https://leerob.io/blog/tailwind

What's your thoughts?

[Vadorequest]

@samuelcastro Moving this to discussions 😉

[Vadorequest]

I don't think there are any silver bullet, unfortunately.

I agree there are a few concerns with Emotion about the performances, here are two different issues:

• Perf in IDE: WebStorm is definitely slower with Emotion, it's clearly visible. It's nothing to do (IMHO) with how Emotion works, but it's related to the in-IDE syntax and parsing, which is inefficient and makes the DX experience really bad sometimes (files with more than 200 lines of Emotion code scroll up/down much slower). It's noticeable because .ts files are fast (scroll) while .tsx files are slow, if Emotion is being used.
• Perf in browser: I haven't noticed this. I find NRN rather fast by default in development mode, but on my other apps with a lot more stuff I find it slow in development (localhost). Although, I haven't noticed any perf issue in production, and I believe that's what matters the most.

Tailwind comes with its downsides, it's very different, and it's quite a big lib (70+ kB): https://tailwindcss.com/docs/optimizing-for-production

I wouldn't change my current projects from Emotion to Tailwind just because of this. But I've considered writing the Emotion styles differently (I currently use inline css=css(), thinking of moving those in a different file) because of the IDE performances issues.

[Vadorequest]

Although I haven't personally noticed performance issues with NRN, it is true the LightHouse "performance" score is much lower than I'd like, but I hadn't linked it to the use of Emotion until now.

It'd be very interesting to see what'd be the score of NRN after replacing Emotion by Tailwind or similar.

[samuelcastro]

Yeah, I'd love to see the results with Tailwind or even Linaria.

[thiagodebastos]

It could be worth investigating stitches. I've had a play around with it, and the concept is great, it builds on theme-ui and styled-system. It also seems to overcome some of the performance concerns experienced with other CSS-in-JS options like emotion. However, the team working on it is quite small and they still have a ways to go.
I gave up trying to get it to work in a jest test environment after a few hours of playing around. I don't have much experience with jest and don't really want to start digging into how jest creates a virtual DOM and how that effects how stitches does things 😓

[Vadorequest]

Playing around at #372.

[thiagodebastos]

Thanks for sharing! Indeed, the usage examples look great!

https://stitches.dev/docs/benchmarks performs better in all highlighted use-cases.

Also, the API is very similar (css, styled) and might be easy to replace one by another without changing much code (besides config)

Also, it's composable in a way that might be compatible with ChakraUI (px, mx, etc.) to share a similar API between ChakraUI components and other components/elements.

SSR seems to need to be handled manually.

What issues did you experience with Jest? Why wouldn't it work using Jest? 🤔

Hey @Vadorequest! Here are some of the issues I experienced:

Jest

I was writing up an example of the issues I was facing with Jest, but when re-creating the bug, I found that it appears to have been fixed with a recent release. I was on "@stitches/react": "^0.2.0-canary.7" and it appears to have been fixed when I updated it to ^0.2.2 which is great! The issue had something to do with a conflic with jest-dom, but I can't find the issue anywhere anymore. If I do, I will link it here.

TS + Storybook

Initialising Storybook with npx sb init results in many TS errors, I think all to do with the css prop, and a CSS type created as:
type CSS = StitchesCss<typeof stitches>.
It seems that Storybook makes it hard to pass types around (admitedly this is a much more complex use of TS than I am used to, and although I have the basic feeling for what is going on, I've never had to understand TS so deeply during working 😓 ).

• I found a PR 0.2.x — updated typings stitchesjs/stitches#610 that may resolve these issues, but have not looked into it.
• Likely related to TS: error spreading abstracted style onto css prop stitchesjs/stitches#407, which provides a workaround similar to me typing css?: any in the examples hidden below/

To reproduce the TS + Storybook issues:

* clone [radix-ui/design-system](https://github.com/radix-ui/design-system) * run `yarn tsc` * see that there are no ts errors * run `npx sb init` * run `yarn tsc` * 💥

import React from 'react';
import type * as Polymorphic from '@radix-ui/react-polymorphic';
import { CSS, styled, StitchesVariants } from '@config/stitches.config';

const DEFAULT_TAG = 'button';

/**
 * Primary UI component for user interaction
 */
const StyledButton = styled(DEFAULT_TAG, { /**  some styles */});

type ButtonCSSProp = { css?: CSS }; // <-- casting this to `any` gets some of the `design-system` errors to 'go away' but its not ideal
type ButtonVariants = StitchesVariants<typeof StyledButton>;
type ButtonOwnProps = ButtonCSSProp & ButtonVariants & { size?: any };

type ButtonComponent = Polymorphic.ForwardRefComponent<
  typeof DEFAULT_TAG,
  ButtonOwnProps
>;

export const Button = React.forwardRef((props, forwardedRef) => {  // ts-error No overload matches this call
  return <StyledButton {...props} ref={forwardedRef} />;       // <-- i notice that in my use case, with NextJS, the `ref` type referred to here is `legacyRef` only after adding Storbook
}) as ButtonComponent;

Button.toString = () => `.${StyledButton.className}`;

No <ThemeProvider />

This is also something I noticed. However, being a novice in creating multiple themes for clients, and the use case I am after, I was unsure of a workaround for this. It's still murky territory for me.
I was thinking it would work roughly like:
CMS --> choose/edit a theme --> store theme config as JSON in a DB --> load config during build time and load into getStaticProps in NextJS --> SSG --> website has theme hardcoded in build.
But like I said, I am still very fresh to learning about the architecture required for my use case. I can go into it more somewhere else to not take over this thread. I started learning about tenancy for the first time in your docs, and am super grateful for you sharing what you've learned, wow!
🚀

[Vadorequest]

Storybook uses Emotion v10, and Emotion uses a css prop. That's probably related to the issue you've faced, it might be name clashing with different types assigned to the css property (one defined by Emotion, the other defined by Stitches).

I've met the same issue with Emotion 11, because there are a few differences, and it fails sometimes on some element (like SVGs), for some reason.

The solution with the "config as JSON hardcoded in build" is something NRN already supports through https://github.com/ricokahler/next-plugin-preval. It's how Locize translations and CMS data (Airtable/GraphCMS) are stored. I only thought about it after writing the above reply, but it'd be possible to go around the lack of Provider this way.

I'm glad you found the docs useful, as they were written for the purpose of teaching 😄

[thiagodebastos]

Storybook uses Emotion v10, and Emotion uses a css prop. That's probably related to the issue you've faced, it might be name clashing with different types assigned to the css property (one defined by Emotion, the other defined by Stitches).

Oh that's right! I recall resolving that issue with a few suggestions in issues on the Storybook repo. However that then led me to another issue with the ref prop. Something about Storybook resulted in the ref type coming from legacyRef instead - its taking time to reproduce but I will share it if I can.

The solution with the "config as JSON hardcoded in build" is something NRN already supports through https://github.com/ricokahler/next-plugin-preval. It's how Locize translations and CMS data (Airtable/GraphCMS) are stored. I only thought about it after writing the above reply, but it'd be possible to go around the lack of Provider this way.

It's good to know I'm on the right track then :) I will have more of a think about it. Stitches is great to use, but I am so cautious of burnout these days as getting these things to work can take so much time - as you say in your docs 😓!

[Vadorequest]

Yeah compatibility is harder the more tools you use, as you noticed with Storybook and Jest. One small change can break the DX completely.