[RFC] Mega Astro styling handling about astro HOT 8 CLOSED

Really appreciate how thought-through this is! Some thoughts:

Inlining

• bikesheddy: <style inline> vs. <style critical>?
• less bikesheddy: Should it really be the component user / composer who dictates if CSS is critical? I would love to explore some alternative designs here. For example:

// using config
criticalCss: ['./components/Hero.hmx', ...]

// using <script astro> (pages only)
<script astro>
  import Hero from '../components/Hero.hmx';
  export function setup({criticalCss}) {
    criticalCss([Hero, ...]);
  }
</script>

// using the component
<Hero css:inline />

// using some super out-there new syntax
<astro:inline component={Hero} />

Importing

• I don't think I 100% grok the distinction between Astro's @use support and Sass, but I think anything other than "if you want @use, use lang="sass"" would become very difficult to document, explain, and understand. "Oh, you're using @use! Wait, is it Css @use or Sass @use? Yes, I know you couldn't find documentation for Css @use, that's because..."
• Remember that you can rely on an optimization step to optimize the CSS for the final production build. I'm coming around to doing more bundling on our end as a part of building, outside of optimization. But, something like "bundle these otherwise totally valid @imports" is a perfect use-case for work to push off to the generic optimize step. Basically, I would push for this being valid ouput of our Astro build:

/* components/Hero.hmx */
@import '/foo.css';
@import '/bar.css';
/* ... (hero styles) */

/* components/Banner.hmx */
@import '/baz.css';
/* ... (banner styles) */

Dynamic components

• Yeaaaaaa that's an interesting problem, isn't it.
• It would be great if we could get away with: ":dynamic is all about dynamic JS, but the CSS has already been bundled into the head." But can we? I can't help but feel like getting rid of all CSS loading concerns/complexity in dynamic components on the page would be AMAZING. Like, a valuable feature in its own right.

from astro.

<style inline> vs. <style critical>

🤷🏻 I’m open to either! Will think about it

// using config
criticalCss: ['./components/Hero.hmx', ...]

❤️ This is a really cool idea. I think it’d take some experimentation, and couldn’t be global, because the whole idea of critical CSS is only style things above the fold which would be page-specific, not component specific (🤔 should there be page-level config? routes? maybe!). But that said, I love the idea of making it more automatic.

I do want to err on the side of the user having control, because if we inline too much it quickly becomes a counter-productive effect of being worse than a giant .css file. But to your point, putting it 100% on the developer is hard, and is the reason more people don’t take advantage of it.

I don't think I 100% grok the distinction between Astro's @use support and Sass … But, something like "bundle these otherwise totally valid @imports" is a perfect use-case for work to push off to the generic optimize step.

That’s fair. I’m not a big fan of @use, it’s just a hedge to give the user control. Put another way, imagine a scenario where a user wanted to not bundle the @import statements. Or they wanted to bundle some (local styles), but for other requests leave the @imports fetching remote files (npm CSS). I wanted to give a user more control:

• @import works exactly like CSS. We will never hijack this.
• @use (or pretend it’s @bundle or something else) is made up (not CSS spec): only use this if you want a certain thing to happen.
• Sass explicitly moved away from hijacking CSS’ @import because there were a lot of headaches around implementing a spec feature…not to spec. I think there is a good warning there about not changing core language features (an example being print styles which require @import)

Lastly, I don’t know if we can use Snowpack’s optimize step for this. I think Snowpack optimize is currently scoped to using optimize: { bundle: true } which relies on esbuild + specifying entrypoints, right? And I don’t think that currently bundles @import statements; so even if we did use that we’d have to change Snowpack behavior.

How do you feel about improving Snowpack’s optimization vs just doing it in Astro for now?

from astro.

It would be great if we could get away with: ":dynamic is all about dynamic JS, but the CSS has already been bundled into the head." But can we? I can't help but feel like getting rid of all CSS loading concerns/complexity in dynamic components on the page would be AMAZING. Like, a valuable feature in its own right.

I think we can, at least for now. Drew’s opinion: bundling and webpack have been great for JS dev, but they’ve really set us back in terms of efficient style loading. It’s always been second-citizen, and been a turnoff for the CSS folks (Filament Group, et al).

I know that the “include dynamic CSS in head and JS loads later” isn’t a perfect performance story. But I think it’s loads better than “webpack’s default.” And the alternative gets into a JS runtime to inject styles. So I’m not saying this is the ultimate form, but IMO I think it’s a pretty good first cut! And obviously we can put it through its paces to test its limits.

I agree though that getting that right is a feature in and of itself, and an achievement within our reach! So I agree: let’s do this! But I would like to give that dedicated time and attention, after the initial release.

from astro.

the whole idea of critical CSS is only style things above the fold which would be page-specific, not component specific (🤔 should there be page-level config? routes? maybe!)

To clarify I meant criticalCss as some astro.config.js value, but I think you saw it as some return value from the setup() function which actually makes a lot more sense. It could also use the components directly:

// using <script astro> (pages only)
<script astro>
  import Hero from '../components/Hero.hmx';
  export function setup() {
    return {
      critical: [Hero]
  }
</script>

from astro.

Shared this in a message to you, but sharing here also: https://esbuild.github.io/content-types/#css

Since snowpack uses esbuild behind the scenes, we should be getting @import bundling by default when you go to optimize your final build. I think that gets you the behavior you were looking for, but some experimentation still needed.

from astro.

Dynamic components should probably work the same way as SSR components—include in bundle? On the fence about this

I'm too new to Astro to have a solution in mind, but I do want to express that this can be a pain point when hydrating components in Microsite. I'm using Fela on my personal site and csstag on a client project, and in both cases it can be difficult to get the dependency tree right to avoid bundling otherwise static styling (and the library dependencies!).

from astro.

in both cases it can be difficult to get the dependency tree right to avoid bundling otherwise static styling

Right! There‘s no universal answer that’s best for everybody. In general I think a good practice is to try and not load heavy styling libraries from a component; if something is very weighty then try and include it in your global bundle so it’s cached and globally-available. We’ll try and outline best practices in the future, and we‘ll try and walk that delicate balance between bundle most things but not everything, vs load things on-demand but not everything, either.

from astro.

Thanks all for the input! There will be plenty of room for more input going forward. But we at least have a starting point now.

from astro.