My Introduction to Astro

After refactoring a side project from an Eleventy-based site to one built on Next.js and writing a few thoughts on it, I came across an article by Josh Collinsworth in which he states his opinions on the aging of the React framework.

At the end of the article, Josh lists out a number of alternatives that he recommends trying out. Astro is one of those frameworks. After Stephanie Stimac rebuilt her site using Astro, I decided to give it a try.

Set Up

Astro is very similar to Eleventy so I was able to get through the set up instructions quickly. The "getting started" documentation is pretty good and reminded me a lot of the Next.js documentation. The step-by-step documentation gets you up and running quickly.

I prefer to manually set up my applications instead of using CLI commands. I find it helps me understand what's going on a bit better but I ended up jumping around the documentation a little. This contributed to some snags along the way, but nothing that took a lot of time to overcome.

I actually spent more time being confused by the official Astro extension for Visual Studio Code because it was detecting some weird problems and had some issues with syntax highlighting.

Project Structure

Astro has an opinionated project structure. I'm a picky person so I sometimes struggle with frameworks that have a particular structure but I think Astro has a good balance of structure and flexibility. Other than a few requirements and reserved folders, you're open to structure your project however you see fit.


One thing I really like about Astro is the component concept.

It's very similar to Next.js but you implement them similar to Eleventy templates with frontmatter and a template. This means that I can write my HTML as actual HTML and use tokens to inject the dynamic data.

The other thing that I liked was that the use of <slot> elements is the same as it is with web components. This compatibility with the native web platform is a huge upside for me since I am a fan using as much native web technology as possible.


Just like Eleventy and Next.js, routing is wired up through the folder structure. Similar to the Next.js Pages Router architecture, you use a pages folder to define your structure.

Because I organize my blog folder structure using a date pattern, I did encounter some issues with deep nesting when trying to import components. However, I am sure there are ways to build your project using slugs or other methods to remove that problem.


One of my disappointments with Next.js was the out-of-the-box output for static site generation. There was a lot of "junk" included that didn't need to be there. Astro didn't have any of that. It's output produces HTML and whatever client-side assets you need.

This makes sense as the framework was designed with content sites in mind.

The output was on par with Eleventy (which is to be expected since they are both SSGs) and gave me a simple set of files that can be deployed to any file server without additional configuration.

Final Thoughts

When I first looked at the documentation, I wasn't sure if I was going to like Astro as much as I liked Eleventy. However, once I started working on it, the structure and workflow really fit my preferences. It takes a lot of what I like about Eleventy and what I like about Next.js and combines them well.

The framework is built for content sites so converting my site to use Astro worked well. But even the Astro documentation says that it might not be the right choice if you want to build a "web application".

Overall, the core concepts of Astro fit in well with the way I like to build for the web so I really enjoyed working with it. I had a similar experience with Eleventy but I feel like Astro is a little more advanced while still keeps things simple and easy.

Return to Homepage