Performance metrics of Astro with different framework integrations

[uncut vault]

Is there any data regarding how the different frameworks affects bundle size and/or performance with regards to which front end framework we use with Astro (Solid, React, Vue, etc)?

I’m creating a product that is very eco-friendly oriented so I’m curious about these statistics. I know Solid is likely the leader but I don’t know if Solid being one of the lightest/most performant frameworks automatically means it wins the prize in the context of Astro as well. I figure there could be some behind-the-Astro-scenes things that affects the scores.

[vernal cedar]

The overhead of Astro’s hydration logic (which is pretty small) is the same for any framework, so it’s basically the same question as when comparing the frameworks without Astro involved: Preact & Solid are very small, React much bigger.

[uncut vault]

Awesome, thanks!

[hollow arch]

To add to what's already been said, you could go even slimmer than Preact or Solid by just using plain JavaScript. There's some really good guides here: https://docs.astro.build/en/guides/client-side-scripts/#common-script-patterns (The webcomponents one is 🔥)

[vernal cedar]

Definitely true if you only have a couple of interactive components that need JS. But vanilla JS can sometimes be pretty verbose so for more complex sites the small overhead of a UI framework (Preact is 3kB for example) may be a worthwhile trade-off.

[uncut vault]

Thanks for pointing out this possibility, @hollow arch! I would definitely consider this but I will be building a companion app that will require some SPA functionality so I'm planning on building all the UI out with Solid so I can easily share components between the projects (likely in a monorepo).

Speaking of, does anyone know if there is a downside to building everything out in a UI framework and avoiding using .astro components unless needed? Of course I wouldn't opt-in to client-side interactivity unless needed (but "static" components would be Solid ones instead of an Astro ones). Does that affect performance in a meaningful way? Or is it "better" to reverse it and use Astro components everywhere I can and only my Solid components specifically if I need client-side interactivity? This would make me need to recreate some stuff for each project (examples being "cards", profile avatars, etc).

[vernal cedar]

The main advantage of staying in .astro as long as possible is it’s in Astro files you can opt in to hydration. That said, you can pass children into hydrated components, so can do stuff like this in a .astro file and only load the client-side JS for <SolidCTA>:

<SolidCard>
  <h1>Title</h1>
  <p>Some text</p>
  <SolidCTA client:load>Click me!</SolidCTA>
</SolidCard>

The new Astro site uses a lot of Solid components in exactly this way if you’re looking for inspiration. For example, all these icons are written in Solid to make them easy to use from both other Solid components and in .astro files: https://github.com/withastro/astro.build/tree/main/src/icons

[uncut vault]

Thanks for that tip! That's exactly what I'm looking for.

Hmm. If I'm mixing Solid and Astro components a lot, I figure I'll run into places where I have text content in both types of components. What is the strategy for i18n/localization? Do I need to basically use two i18n setups? One for Astro and one for Solid? 🤔

[vernal cedar]

In docs I landed on always passing labels from Astro into Preact components to avoid pulling in all the translation dictionaries into the client bundle

Something like:

<h1>{t('page.title')}</h1>
<Search labels={{ search: t('search') }} client:load />

(where this is a .astro file, so we load translations server side but then only pass exactly what we need to the interactive component)