When I first discovered Astro (thanks, Joey), it was a serious “aha” moment - like, this was the framework I had been waiting for.

I’ve been building websites for close to 10 years now. This very site has gone through a number of iterations, starting with just a static HTML/CSS/JS site built manually, moving to a WordPress project for a few years, then finally turning to a static site generator in Gatsby. Generally, it has served the role of being an experimental playground for learning new tech. Both the WP and Gatsby iterations helped me to learn those approaches to building sites, and spawned a nubmer of other projects using both of those platforms over the years.

Gatsby, in particular, was the one that excited me the most. It made building statics site fun and flexible by being able to use React and Graphql - I could easily use 3rd party content from a headless CMS, and leverage the reactivity of a JS framework to build my static site. How could it get any better?

Fast forward a few more years, and Astro comes on the scene with a focus on reduced JavaScript (afterall, how much do we really need in the end?) It uses a familiar component-style syntax that feels very much like JSX, like we would find in React, where we can pass props and everything.

Additionally, it is actually JS framework agnostic. This one took me a minute to wrap my head around… wasn’t this already a JS framework? Turns out, the answers was no. It’s really a front-end, HTML building framework, that only feels like a JS framework. In reality, it doesn’t care what JS you might want to use, and you can basically bring in React or Vue components (for example), directly into your HTML templates, and it “just works.” You can even mix and match if you really want to.

Making the Switch to Astro

Once I saw these benefits, I thought I would try and make the change from Gatsby to Astro for this present site, and see how it went.

With a few terminal commands, I had a scaffolded base project with basically nothing in it. I decided to leverage its Apline and Tailwind integrations, and I had it up and running with almost no configuration.

Next, I copied my blog posts (in Markdown) from the old site into the new Astro site. Since it supports Markdown out of the box, I didn’t need to write and Graphql queries to either retreive the data, or create the individual routes and pages like I had to do for Gatsby. Instead, sort of like a Next.js project, the file template for a single blog post looks like [slug].astro, where slug is a dynamic value. Inside the file, there is a getStaticPaths function (again, similar to Next) where all I need to do is call an Astro method that just knows about what’s in the project files.

export async function getStaticPaths() {
  const posts = await Astro.glob('../../posts/**.md')

  return posts.map(post => ({
    params: {
      slug: post.frontmatter.slug,
    },
    props: {
      post
    },
  }))
}

The value of “post” as a prop passed into the template is the content of the Mardkown file, from which I acccess the frontmatter, as well as the content directly. The only thing I needed to change was the path to the images that posts linked to, since they live in a different directory at the end of the day. Just a simple search/replace to change the file paths, and I was done.

All of this took a matter of minutes, and I had a functioning blog just like I had in Gatsby. I suppose the notable downside here was that I had to sort by date manually on the blog index, rather than leaning on Graphql to do that for me - either way, it’s something you have to do yourself. In this case, it’s just JavaScript, and so it felt pretty easy to use a .sort() methold on the returned Markdown posts returned by that Astro.glob() call.

Finally, I took advantage of the Alpine integration to layer in some minimal interactions for the mobile menu toggle, the dark mode toggle, and handling some basic form validation for the contact form on the home page. I also used the Tailwind integration to generate my CSS, again with almost no configuration, including its internal dark mode setup, and the typography plugin for easy styling for my blog posts.

What’s next with Astro?

It’s hard to say how this will affect my work in the future, but I anticipate leveraging Astro quite a bit. While it is friendly for simple static sites, it can also easily handle React or Vue components wherever I want, as well as SSR if I wanted to layer in a database to dynamically bring in content, like I would with something like Next.js., with a little less complication at the end of the day. Just like Vue, you can start with the basics and gradually introduce more complex or advanced features without much fuss. I’ll be looking for opportunities to use this as much as possible.