Why one single css file? Shall we bundle it with webpack or keep seperate?

[AdarshJais]

I'm seeking to deepen my understanding of web development practices, particularly regarding the bundling of CSS files. In JavaScript, we often split bundles as code grows to optimize performance. However, when it comes to CSS, I notice that many projects output a single CSS file including pandaCss and stylex

1. Can someone explain the rationale behind creating a single CSS file as output in web development? Is it primarily to minimize network calls for improved performance, or are there other factors at play, isn't the big bundle size of CSS is major concern compared to the multiple small bundle fetching, bundle splitting also creates a separation of concern among modules.

2. In the context of Webpack, I understand that CSS is bundled with JavaScript by default. Does this bundling approach have any performance impact compared to having a separate CSS bundle? How does it affect loading and caching strategies? What is the stylex recommendation for this?

I'm keen to hear from developers with insights into these considerations and how they impact web development practices.

Thank you!

[nmn]

Re: 1 we have a whole section explaining this design decision: https://stylexjs.com/docs/learn/thinking-in-stylex/#one-small-file-over-many-smaller-files

TLDR; With atomic CSS, we can generally ensure that the singe CSS file never gets too big.

isn't the big bundle size of CSS is major concern

No, because it's not a big bundle at all. It's a single small bundle.

---

In the context of Webpack, I understand that CSS is bundled with JavaScript by default.

This is not the case. Our Webpack plugin (and also NextJS) generates a separate CSS file.

[AdarshJais]

Hey @nmn, Thanks for the quick response.

Regarding the CSS getting bundled with JS is the case I can see it with Panda CSS but yes not with Sylex. What's your take on this, which approach should one consider and why?

Does bundling together have any pros/cons compared to having it separate, can bundling together with a JS bundle create any runtime overhead, or it could be better in terms of code splitting? since it is bundled with the JS and the JS could be easily split and load on demand?

Does bundled CSS with JS also cause a recalculation of styles for the entire page (something similar that you mention here (https://stylexjs.com/docs/learn/thinking-in-stylex/#one-small-file-over-many-smaller-files) ??

Also, I was looking for a comparison between PandaCss and Stylex. It seems both are solving the quite same problem for CSS-IN-JS but choosing between one over the other is very unclear in terms of features or problems they solve as of now.

[nmn]

@AdarshJais I'm not an expert in PandaCSS so I can't speak to their approach. Within StyleX we aim to have the most efficient result after compilation as possible. This is also documented on the website: https://stylexjs.com/docs/learn/thinking-in-stylex/#low-cost-abstractions

TLDR; As long as styles are defined and used locally within a file, StyleX has zero JS overhead. When using style composition across files, we generate static objects that map keys to classNames and use a heavily optimized runtime to merge the classNames. Think of this as a more reliable version of classNames function that you may be familiar with.

Another way to think about it is that StyleX is as fast or faster than Tailwind. If you're not using style merging it's exactly equivalent. If you're using style merging, StyleX is much faster than using twMerge.

We're working on a StyleX CLI which will make what StyleX generates more transparent and make it obvious how StyleX has little to no overhead. The only time there is an overhead at all is when merging styles which is either impossible with other solutions, or much slower (twMerge).

---

Take the following with a spoonful of salt as I'm not an expert on how PandaCSS works, but from what I understand:

1. PandaCSS works via code-generation and not compilation. From what I understand they generate a static CSS file as well, but also generate a lot of JS to access the classNames. I don't know how big the generated JS is.
2. PandaCSS has a large API surface, so I expect that the amount of JS generated depends on the APIs and "recipes" you use.
3. Panda supports many of the same features as StyleX but I see two big differences:
   1. PandaCSS doesn't have a type-safe API like for creating and theming CSS variables StyleX's defineVars and createTheme.
   2. PandaCSS support style merging, but I'm fairly certain it'll have edge-cases where the merged styles won't be entirely predictable. I'm working on a blog post explaining how StyleX ensures that style merging is 100% consistent and predictable.

---

For understanding StyleX, the "Thinking in StyleX" page should explain our goals and guiding principles for StyleX.

TLDR; The most important benefits of StyleX from our perspective are:

1. Small, easy-to-read, familiar, API
2. As fast and efficient as possible. We match the best-in-class runtime perf of Tailwind or exceed it.
3. Style Composition (aka merging) that is 100% reliable, predictable and intuitive while staying fast. (This is the most unique thing about StyleX IMO)

---

What's your take on this, which approach should one consider and why?

Why even bother asking me such questions? You can know my opinion on any such question by seeing the design decision in StyleX and the "Thinking in StyleX" page.

can bundling together with a JS bundle create any runtime overhead...

You're missing some nuance here. Runtime injection of CSS is one of the worst things you can do for performance when it comes to CSS. This is why solutions like Emotion and Styled-components are particularly bad for perf.

AFAIK, PandaCSS does not rely on runtime style injection either. Their JS is only working with classNames that have been generated at compile time. There is some runtime overhead to this as with any client-side JS, but I don't know how much overhead Panda introduces.

or it could be better in terms of code splitting?

The JS code can still be code-split if you're using StyleX. We only want a single CSS file. We're not enforcing any such rule for JS or HTML.

Lazy loading JS does not have the same issues as lazy loading CSS as only the JS that runs causes things to happen. CSS causes the browser to do stuff simply by existing as it's declrative language.

Does bundled CSS with JS also cause a recalculation of styles for the entire page

I assume I already answered this.

It seems both are solving the quite same problem for CSS-IN-JS but choosing between one over the other is very unclear in terms of features or problems they solve as of now.

I feel like I've answered this already as well.