Experiments in Astro

Enter Astro

Lately, at my day job, we’ve been talking a lot about performance. Our marketing site and blog have been maintained nearly a decade and for one reason or another there are sets of pages that don’t perform as well as the others. The site is currently built on Gatsby JS which may be dead depending on who you ask so we’re starting to look into alternatives.

One of these is Astro - “a JavaScript web framework optimized for building fast, content-driven websites.” The framework is piqued my interest for a few reasons:

• It is framework agnostic. You can use any UI framework you want (React, Vue, Svelte) or none at all and compose component files using their .astro syntax which can be described as a mix of HTML/JSX with JS-charged frontmatter.
• They pioneered what they call islands architecture. To summarize, Astro hydrates your components individually or as needed avoiding the need to load a large page bundle on load. Performance gains!
• It was built with handling large amounts of content in mind from a variety of sources.

Blog Rewrite - An Experiment

What better way to familiarize myself with this static site generator than to completely rewrite my personal blog? As of the date of this post, I’ve completely migrated from 11ty to Astro and pushed the changes live. The site more or less looks the same with minor style changes. Frankly, I don’t think my site benefits much from any performance gains (if any) but it was a great learning experience to see where optimizations could be made if my site wasn’t already minimal.

Developer Experience

Astro wins here. As much as I like the bare-bones nature of 11ty, I’m more comfortable in the modern JS framework workflow Astro provides. I have the option to expand upon any of my existing pages with any UI of my choosing and have better control of my components using props. I do use my site from time to time as a testing ground for passion projects so Astro allows me to easily achieve this. The frameworks options are nice, but I haven’t felt limited by the native .astro files yet. That said, Astro is PROBABLY overkill for my blog right now it was nice to at least lay down the foundation for the future.

Writing JS for Static Site Generation

Having been in the React ecosystem for so long, I had to adjust for writing code for the server and really think about whether the component code I’m righting needs to run at build time or runtime. Client APIs like window are not available at build time and data fetching happens only at build time. For interactivity, Astro instructs you to write your event handlers, client-side data fetching, and other client-side JS between <script> tags.

Deduplication of Local Style Sheets

Astro favors component scoped styling which isn’t normally an issue, especially on my site, but I quickly realized on my production build things weren’t quite right. My top level reset.css file was overriding component styles, seemingly breaking the rule of specificity. As it turns out, Astro will try to de-duplicate any style sheets it finds. In my case, reset.css was being imported into two different page templates - one for my main site layout, and one for a part of my site reserved for experiments. In doing so, it can include that style sheet in a different location in the production bundle causing styling conflicts.

The Future

All in all, this proved to be a valuable learning experience (I’m kind of stuck with it now). It will be interesting to see how Astro fares against the more established frameworks over time.