Astro Migration

Well this came out of nowhere!

When building my last blog post 2023 Redesign, loading the images with GatsbyJS was proving more difficult I anticipated. This was both frustrating and a little inspiring.

It was frustrating because loading an image from a Markdown file didn’t strike me as a very complex problem, but it seemed that Gatsby wasn’t able to do it simply for me. On the other hand, it was a little inspiring, because it finally gave me the drive to rebuild the site in a new tool.

Reasoning

For a while now, I’ve been disliking working with GatsbyJS. It seems that almost every time I try to work on this site, I’m plagued with obscure errors that both impede the development process and chip away at my drive to keep development going. Because of this, I’ve been looking into different options for a static site generator.

Hugo looked to be a good option for a while, but I was a bit put off when I was reading through their documentation.

Svelte Kit was another interesting option. I’ve been interested in building something in Svelte for a while, since its gained a lot of popularity and support over the last few years and it’s performance is nothing to sneeze at. I’m also quite drawn to how close to vanilla HTML, CSS and JS the development experience looks. However, I was left feeling like Svelte Kit was a bit too heavy handed of an approach for a simple static site like this.

Building with vanilla web APIs has been interesting to me for a while. Since I primarily work with React, it’s very easy to become a “React developer”, instead of a “Web developer” and I’m not too keen on getting stuck in that box.

Looking for something that had a great developer experience, TypeScript support, page generation from Markdown files and a vanilla-like API lead me to Astro. Reading through the docs it really stuck out to me as the option that satisfied the most of my preferences.

Process

The migration process from Gatsby to Astro was relatively straight forward, but there was definitely a learning curve.

My process for the migration began with using npx create astro@latest within the project directory to create an Astro project in a subdirectory. From here, I slowly copied over the components from the Gatsby project to the Astro one, converting them to .astro components. I also took the time to remove a few redundant and over-engineered components which helped to reduce the complexity of the codebase, clear some tech-debt and make the codebase a bit cleaner.

Since I was using Styled Component in the Gatsby project, I had to spend a fair amount of time converting the styles to vanilla CSS. This proved to be a fair amount of work due to how style cascading works in Astro (parent styles do not cascade to children), so I had to rework a fait amount of styles and separate them into scoped and “global” styles.

The page generation from Astro was a lot nicer to work with than the Gatsby implementation. Since Astro uses file-based routing (even for markdown files) very little work was required to set up the pages and routing within Astro.

Pros and Cons

Since I’ve only spent very little time with Astro, this comparison definitely won’t be exhaustive, but this is my experience so far.