"Extract CSS File" seems misleading

[RussianCow]

First of all, thank you so much for your work in compiling this table! It's an awesome reference.

Now, my question: How do you determine whether a library supports CSS file extraction (under the "Extract CSS File" column)? As an example, aphrodite has a checkmark under that column, but this issue suggests that this is explicitly not a feature of the library. Other libraries that have that checkmark in the table, such as glamorous, don't suggest any way of accomplishing this.

Either I'm misunderstanding what that column means, in which case it might be a good idea to describe it in the readme, or some of these values are incorrect. If it's the latter, I would be more than happy to go through them and compile a list of which of these libraries actually advertise this as a feature.

Thanks!

[RussianCow]

A few minutes after writing this, I discovered that you have an example of CSS file generation in each of the example directories. My bad for not seeing that sooner. 😁 However, I think using the word "extract" here is misleading, because (at least to me) it implies something that statically extracts all the generated CSS into a file at build time (a la extract-text-webpack-plugin), whereas your examples generate a CSS file dynamically based on what was rendered by React. Maybe this is just my own personal bias showing (I've always used extract-text-webpack-plugin with LESS/CSS modules to generate static CSS files at build time), but the wording in the table seems misleading, because this method doesn't actually allow you to extract a full, reusable CSS file that you could use for the whole app, since it depends on what was rendered. An example of a CSS-in-JS library that does support the kind of file extraction I'm talking about is emotion (though admittedly, it's very limited in how you are allowed to use it).

Do you have any thoughts on how to make this more explicit?

[streamich]

Out of interest, why do you want to extract CSS into an external .css file?

[RussianCow]

Mostly performance reasons for server-side rendering. I'm working on a small project that has to support clients with JS disabled, so the app is "universal" (or isomorphic or whatever term you prefer 😉). Generating a static CSS file is a requirement because then it gets cached in the browser forever, rather than having to serve different CSS with every page load (which is what I would have to resort to with most CSS-in-JS libraries). I otherwise prefer the CSS-in-JS approach from a developer experience standpoint, so I was curious as to whether any libraries gave you the best of both worlds, and stumbled upon this repo in my search.

I understand my use case is probably not very common, so feel free to ignore me. 😁 I have just always seen the word "extract" used in the context of things like extract-text-webpack-plugin that extract the CSS statically at build time, so this threw me off a little bit.

[stereobooster]

so the app is "universal" (or isomorphic or whatever term you prefer 😉)

the word you are looking for is graceful degradation e.g. with SSR and extracted CSS browser will be able to render page even if JS is disabled

Extracting CSS and prerendering HTML (with SSR) improves First Paint significantly.

understand my use case is probably not very common

It is pretty common - I mean requirement to generate CSS as text upfront would it be separate file or inlined in HTML in header.

[streamich]

I was asking because I am currently working on nano-css and there all raw CSS is available as a string in nano.raw property. I think the general approach (especially for single page apps) is to inline that string into server rendered HTML, which should be faster than doing one extra request for .css, for example, Google AMP requires you to inline CSS.

You could actually serve that string on a server as a separate file, too.

A bit more problematic would be to extract all styles at build time. I am thinking, one could simply at build time require all .js component files, that would build static CSS in nano.raw and that can be saved to disk. Do you see any problems with that globbing for all files in /components folder and simply requiring them?

[RussianCow]

@stereobooster To clarify, when I said it's not common, I meant it's likely not common for people using CSS-in-JS solutions (at least, that seems to be my experience). This works just fine if you use plain CSS or a preprocessor like LESS or Sass, but I think most people who go the CSS-in-JS route are aware of the drawbacks and don't care about having all the CSS up front. In fact, you could argue that is one of the advantages of doing CSS-in-JS: it only renders the minimal CSS necessary for any given render in most cases.

@streamich I think simply requiring the components and pulling out nano.raw in a script would be pretty finicky, because if your JS relies on any preprocessing steps like babel, then that script would have to go through your build process before it gets run, which is one of those awkward meta things that's hard to deal with. A more general approach would be to write a babel plugin (or similar), as then the build system (e.g. webpack) can then extract that data as the files get parsed/compiled, instead of in a separate step. (This is how emotion does it.) However, this means all your style generation code has to be parseable statically, at compile-time, which limits what you can do with it (i.e. you can't have dynamically-generated styles that depend on runtime values). From a brief look at your library, I don't think this would be possible, at least not generally.

[stereobooster]

There is linaria - CSS is extracted at build time, no runtime is included

[RussianCow]

@stereobooster Awesome, that's exactly what I was looking for! Eventually I would have gone through the whole list, but that saves me a lot of time. :) Thank you!

[RussianCow]

To go back to the topic of this issue for a second, I just checked out your feature definitions here, and "zero runtime dependency" fits what I was looking for, I just hadn't thought of it that way. So if that page is representative of how the features of these libraries will ultimately be described, I think that solves this issue.

[stereobooster]

So if that page is representative of how the features of these libraries will ultimately be described, I think that solves this issue.

that was the idea, but we are not quite there yet

[streamich]

Just wanted to add here, that one of the main reasons to use CSS-in-JS is to be able to use component or render method variables in your CSS, like props. In that case I don't see how CSS can be extracted, or are there libraries that do that?

[RussianCow]

@streamich Agreed, I think that's the main reason people use these solutions, so it makes sense that static file extraction isn't a top priority for (or even supported by) a majority of CSS-in-JS libraries. Having said that, stereobooster pointed out that linaria is one library that does everything at build time, so there is at least one example.

Edit: To clarify, you can't have both simultaneously—either you have dynamic styles that are based on props and other runtime values, or you have static styles that can be extracted ahead of time. Although, a solution that let you mix and match the two approaches would be interesting. :)

[stereobooster]

is to be able to use component or render method variables in your CSS, like props

Yes, but most of the time this is not random value, but rather limited set of values which represent all possible states of application, like in Redux. So you can compile CSS-in-JS down to static CSS with limited number of classes which corresponds to all states

[streamich]

@stereobooster

So you can compile CSS-in-JS down to static CSS with limited number of classes which corresponds to all states

Has anyone done that? Or, at least, maybe just the default value could be extracted as external CSS.

[RussianCow]

@stereobooster But to do that you would have to somehow know every possible state of your application, which isn't possible (at least not generally—you could just render the app and grab the generated CSS, but that would only work assuming none of the variables ever change). Even Redux doesn't magically know all the possible states of the store, it just helps you be more explicit about state changes. That's why you're limited in what you can do if you want support for static CSS extraction.

@streamich I would be interested in a solution that combines the static and dynamic approaches, where it would statically compile as much CSS as it can, and dynamically load the rest. But I'm not aware of a library that does this, and it seems like that would take a lot of work to implement.