Recently I stumbled across a couple videos and Tweets about Astro, a framework (primarily) focused on generating static web pages. Astro is fundamentally a Multi Page Application (MPA) framework.

While Astro currently supports Server Side Rendering (SSR) it was created primarily for Static Site Generation (SSG) (e.g. NextJS), the former being a rendering technique where the server generates all the HTML on user request, whereas the latter is when the server builds all the HTML at compile time. This results in a much quicker response to the client (with the drawback being somewhat increased build times). There is another very popular alternative, Client Side Rendering (CSR) and Incremental Static Regeneration (ISR) are also options but are irrelevant to the topic at hand.

In my opinion, the crux of MPAs has been the user experience. When transitioning between pages, it would usually seem like a flicker. So while Astro may optimize page loads by preloading, there would still be a brief moment where the screen would be blank which would be perceived as a flicker. Recently, Astro added support for the View Transitions API for web browsers. View Transition honestly seems like magic. It takes an MPA and makes it behave like an SPA during page transitions.

Of course, there are still some limitations of Astro in comparison to SPA’s when it comes to the state, but if you’re building something like a blog where global state isn’t something that matters, Astro supports dynamic content with islands. In these islands, you’re allowed to call React, Solid, Svelte (and many more) framework components where they handle the dynamic content. I haven’t had the opportunity to use this feature so I won’t comment on it further.

Moving to Astro

After seeing the recent Astro changes I decided to revive this blog and build it using Astro. This was surprisingly simple.

I was moving from NextJS (React) app router code to Astro. I figured the difference would be large. When implementing it, however, I found myself mainly copying code and renaming className to class. Of course, there was a difference in the way my components were handled as well as layouts but those were minor. The ease of transfer made it more obvious that React was an overcomplication for something as simple as a blog site.

Moving from NextJS wasn’t the only change. I initially used PlanetScale’s MySQL database to store post data. While revamping the blog I decided that wasn’t required so I moved to a SQLite database. This worked for a couple hours but then I realized Astro had native support for Markdown so I decided to scrap the database altogether. Now all my content is just placed as a .md file in a posts/ directory. Using Astro.glob() along with Astro’s paginate() function I was also able to easily implement a paginated page for posts. The one caveat to this is that I need to push code whenever I change anything but that beats having to write an entire section of the app to publish and modify posts. Content management is simple. If, at some point, it becomes an issue, moving back to MySQL, or PostgreSQL would be simple so I’m not worried.

The one thing I’m still struggling with is Image optimization. I struggled with this in NextJS as well so that’s not much of a surprise. This is why you might get some layout shifts. I’m working on it so that shouldn’t be an issue for too much longer.

In summary, use Astro. It’s an amazing, easy-to-use framework. I migrated my blog in what was essentially one day. That’s coming from a position where I never used Astro before. It’s just that easy. Hopefully, I won’t make any more changes… I’d prefer to not take another weekend writing code and content :/

Thanks for stopping by!