TL;DR: This is going to be a long post about the several iterations this blog has gone through, explaining how I recently finished migrating it to Astro.
Since its creation in January 2016 as a new year’s resolution, this blog has undergone several iterations. Recently, I finished migrating it to Astro, a new framework that has gained a lot of popularity and secured a top position in the latest State of JS survey. If you’re not familiar with Astro, it’s definitely worth checking out. The objective of this post is to describe the rationale behind choosing Astro for this project and my overall experience with the migration.
Astro on the map
Last January when the “State of JS” survey was released, I was eager to read it as usual. As I explained in a post some months ago, this online survey has been running since 2016, collecting and analyzing data from JS developers, and it is definitely a valuable tool for detecting current trends in the JS ecosystem and identifying upcoming ones.
One of the points that caught my attention in this issue, in the Rendering Frameworks section, was the popularity of “Astro”. In just one year, this young project has doubled the interest expressed by developers, so I decided to investigate a little more why it was so popular.
In the official documentation Astro defines itself as “an all-in-one web framework for building fast, content-focused websites.” But one of the key selling points is in the features section: “UI-agnostic: Supports React, Preact, Svelte, Vue, Solid, Lit and more.”. Perfect! That was exactly what I was looking for!
Evolution and why Astro
As previously mentioned, I started this blog in 2016 as a New Year’s resolution. Back then, I opted to use Google Spreadsheets as a “poor man’s” CMS due to its convenience in configuring various blog fields and preserving blog content, while also obtaining a nice JSON response. However, as time passed, the API response underwent changes, prompting me to create a small wrapper to align with the previous response format.
On the other hand, like many other developers around the world, I had the opportunity to work on a couple of projects with the amazing next.js framework, and while I was browsing some of the documentation and examples, I stumbled upon the very useful gray matter npm package.
To put it simply, this package enables you to consolidate both data and metadata into a single text file by utilizing a “matter” section at the beginning of the file, which can then be transformed into a JSON object.
As I was already crafting my posts in markdown format and generating JSON file outputs in my previous Spreadsheets version, it was a straightforward task for me to migrate all of my posts into separate markdown files using this package, and then I could combine these MD files into a single JSON file to be used as the “source” of this blog.
This was my approach for a period of time: I continued to utilize the same node.js express application, but with an alternate “static” JSON source that I could regenerate whenever necessary. However, given that this blog is essentially a static website, I had always entertained the notion of transitioning to a fully static site.
When I came across the Astro documentation, I was immediately convinced, because it aligned seamlessly with the problems I was attempting to address:
- To serve this blog fully static.
- To make the code more maintainable.
- To use a modern framework.
- To keep the existing look and feel (and reuse the CSS styles as much as possible).
- To reuse some of the existing vanilla JavaScript code.
- To add some nice reusable React components I had used in some other projects.
- To keep the nice JSX syntax I'm used to working with in React and Next.js.
Experience
Having spent a week on this migration, my general perception as a developer is highly favorable. Throughout the project, I found Astro to be remarkably versatile and capable of supporting the reuse of existing code, adding custom styles, and allowing component integration from other projects.
It is clear that the project is moving fast because some of the documentation I found on the internet was already outdated, but I found the official documentation to be of high quality overall. Most of my questions were promptly resolved through the official site without any problem.
I jump-started the project using the recommended npm create astro and adapted the generated template to my needs.
In the Project Structure Section the official documentation describes the purpose of the different parts of the application including Pages, Layouts and Components. I followed this recommended structure with a couple of additions:
Not including every single file, my final project looks more or less like this tree:
├── Astro.config.mjs ├── content │ ├── 100.md │ ├── 101.md │ ├── 102.md │ ├── 103.md │ ├── .... ├── public │ └── jc-logo-g.png ├── src │ ├── components │ │ ├── BlogPosts.Astro │ │ └── ... │ ├── layouts │ │ ├── BlogHomepage.Astro │ │ └── Layout.Astro │ ├── pages │ │ ├── index.Astro │ │ ├── p │ │ │ └── [slug].Astro │ │ ├── page │ │ │ └── [page].Astro │ │ └── tag │ │ └── [tag].AstroW │ └── utils │ └── extractAllPostsWithIds.ts
If you are familiar with next.js, the routing pattern associated with the pages directory will probably look familiar. On the other hand, Astro defines layouts as “Astro components used to provide a reusable UI structure, such as a page template.”
As discussed earlier, this migration was a really nice experience, and I would probably use Astro again for a static site!