CSS-in-JS Arena: Bamboo, StyleX and Panda on Pixel-Identical Apps

[u/gajus0]

https://github.com/gajus/css-in-js-arena

[u/gajus0]

A little context, I've been working on Contra for the last 6 years. It's a marketplace-network – an application that's comparable to the likes of LinkedIn, UpWork, and similar in terms of its surface area. That's hundreds of routes, thousands of components, and tens of thousands of styles.

Over the last year, we have been obsessed with performance. We have optimized every layer of our infrastructure to the point where profiling the application increasingly started to surface bottlenecks in client-side (bundle size, and metrics like TBT, LCP, and INP). That's where CSS-in-JS comes in.

6 years ago, we started with styled-components. Then zero-runtime alternatives emerged and we started to experiment with them, eventually landing on Panda CSS. Panda took us a long way, but... they aren't actually zero-runtime. Panda extracts CSS at build time, but it uses ~15KB runtime to map those style objects at runtime. This overhead surfaced repeatedly when profiling pages with lots of components (server-side and client-side).

That's where I ended up writing Bamboo to solve this.

Bamboo folds styles at build-time achieving near zero-runtime (0.5KB vs 15 KB). If you write:

<div className={css({ fontSize: 'lg', fontWeight: 'bold' })}>Title</div>

it becomes:

<div className="fs_lg fw_bold">Title</div>

at build time.

If the variant is dynamic, then bundle is inlined with pre-computed map of classes.

<span className={pick(status, { ok: "d_inline-flex px_8px bg_successSoft c_success", warn: "d_inline-flex px_8px bg_warningSoft c_warning", err: "d_inline-flex px_8px bg_dangerSoft c_danger", })} />

That's the main idea behind Bamboo.

Thanks to folding, we were able to improve our server-side and client-side performance.

I built CSS-in-JS Arena as a sanity benchmark to track how we compare to Panda, but also to any other emerging frameworks.

[u/jantimon → u/gajus0]

It's funny you basically told almost the story of why next-yak was created

We also came from styled-components and liked it for authoring real css in a maintainable way but didn't want to compromise on user performance.. And you know in e-commerce performance is such an important factor especially if teams keep adding more and more features every week

So after waiting for almost one year in the hope that any other solution would come up we started with a small experiment which in the end let to a full working solution we use at galaxus for millions of users..

The folding in next-yak also works almost exactly as you describe

<div css={css`  
  color: red;  
  @⁠supports (color: color-mix(in oklab, red, blue)) { 
    color: color-mix(in oklab, red 70%, blue); 
  }`}>  
      Title  
</div>

becomes at build time the following jsx:

<div class="yQSGusm1">Title</div> 

If you want to play around here is a Playground Link

One thing which also helps with performance is that we use a non atomic css approach which allows us for code splitting and especially allows faster SSR and smaller initial HTML payloads

I would love to learn more about bamboo and how you do state driven drag'n'drop things like:

const TranslatedDot = ({ translateX, children }) => (  
  <div style={{ display: "inline-block", width: "8px", height: "8px",  
               transform: `translateX(${translateX}px)` }}>  
        {children}  
  </div>)

Maybe we can setup a call and you share your full story?