Replies: 1 comment 1 reply
-
working on it ! part of it is already released, wrote a bit about it here, available here currently in the middle of a huge refactor, wrote about it and the new featuers here, current PR is here |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I've been using vanilla-extract for a number of projects and it's working really well. However, one place where I have trouble is component libraries.
Often when a developer uses a UI component library, they are only using a handful of widgets. Ideally, the app's bundle shouldn't have to include a whole bunch of CSS rules for widgets that aren't being used. With regular app code, this is not such a problem, since generally anything that's not used in the app code gets deleted or at least is not included in the build. However, with a component library things are different, since the library author doesn't know which components are going to be needed.
Most bundlers consider stylesheets to be "side-effect-ful", which means that the stylesheet is included in the build output even if the importing module is tree-shaken out. Thus, even if you are only using 'Button', you still get the stylesheets for List, Dialog and so on.
This is exacerbated by the fact that most UI component libraries export all of the components as a top-level export - it's a burden for developers to have to individually import Button, Dialog and so on. (React-Bootstrap had this option and it was painful.) Thus, every component gets transitively included.
"Non-zero-runtime" CSS-in-JS frameworks like emotion and stitches avoid this problem by only generating styles that are actually used; however this introduces a number of additional problems, like the fact that your SSR page generation now has to be synchronous, since you want the styles to be in the page head (to avoid the FOUC) but you don't know which styles are being used until the page is completely generated.
There's also the "source scanning" approach used by Tailwind, UnoCSS and others - only emit styles that are actually being used by the source. It's hard to see how something like this would work for vanilla-extract.
Ideally, what we would want is some way to tell the bundler that the symbols in module A are dependent on the side-effects in module B, so if those symbols drop out then module B can be removed as well. However, I honestly don't see bundlers adding such a feature any time soon.
I'm curious to know if there are other approaches to this problem that I haven't thought of.
Beta Was this translation helpful? Give feedback.
All reactions