Refreshing This Site

I’ve been building personal websites for myself for the vast majority of my life. At first, when I was still in early middle school, I used WSIWYG editors (nowadays, the most popular option is Squarespace, but back then I used Yola and Wix). In middle school, my main driver to make websites was to embed popular Flash games to bypass my school’s firewall settings — can’t block a website they don’t know about!

Over time though, and especially as I got into college, my reasoning for maintaining a personal website changed; it was no longer for play, but as a tool to market myself and share my ideas — some mixture of professional portfolio and social media.

Originally, I built this site to as a requirement of my time in the University of Cincinnati Honors Program (UHP). They required that we build some sort of web portfolio to showcase the projects we did as part of our experiences in college. As I left UHP (on my own accord, not due to academic issues), the strict requirements for my site were no longer in place, but its utility remained. And so, for fun, I rebuilt it using a cool static site generator (Jekyll) and a template (Minimal Mistakes) to make it look significantly nicer. It was fun, but the (extremely well made) template really reduced my incentive to actually learn how the site generator worked, and so I was left with a website I could add content to easily but otherwise didn’t really understand how to modify.

So, after a couple years, realizing that my lack of understanding had demotivated me to continue posting to my site, I realized I needed to make a change — I needed to rebuild the site from the ground up.

Goals

So, having decided to redo the site, what were the considerations I found important?

1. Most importantly of all, I wanted the new site to be 100% mine. No templates, no themes (caveat below); I should have a complete understanding of how it was put together and how to change it.
2. Whatever framework (if any) I choose to use should be modern, fun to use, and encourage best-practices by default. In web frontends, I know enough to be dangerous, and I want the tooling I’m using to guide me to the correct answer and feel “fun” to use. (“Fun” in programming often boils down to “straightforward” and “well documented”.)
3. The site should remain “content driven.” That is, once the technical bits are settled, it should be easy for me to write new blog posts, post images, and so on. Ideally, it should also be easy to reuse content in multiple places without manually duplicating things.

Astro

Given my goals above, it seemed relatively obvious to me that remaining in the realm of static site generators (of which my previous website used Jekyll) was going to be essential. There’s no need to reinvent the wheel even though I am taking a more hands on approach — I just need to find one I like to use and that’s easy to learn.

Fortunately, months prior to deciding to go down this route, I’d become a relatively frequent viewer of Kevin Powell — he’s a great resource for CSS tips. He’d made a video demonstrating the basics of Astro, and it came back to mind when I was choosing how to proceed for my site. Pretty instantly on rewatching the video and browsing some of their (excellent) documentation, I was sold.

Astro has many nice features, and I won’t get into a huge sales pitch, but it does feel worth demonstrating at least some of the quality of life improvement it’s provided. One example, to me, is its more “natural” template language.

On my old site, because it was made using Jekyll, it required the Liquid template language, and I just always felt like it was cumbersome and “weird”. I’m sure it’s not, and I did learn to read and use it perfectly fine, but it felt visually out of place in my HTML or Markdown content. I wanted something more akin to normal HTML to import components, and Astro delivers, both in .astro files as well as via easy integration with .mdx Markdown. As an example, consider importing a gallery of images into a blog post both in Jekyll vs. what I’ve built in Astro:

Before (Jekyll):

{% include gallery id="gallery" caption="A test caption." %}

After (Astro):

<Gallery galleryName="gallery" caption="A test caption."/>

They’re the same, sure, but one looks more natural to me — and that effect adds up across an entire site. Another oddity of the old site was its use of “inline attribute lists” in kramdown to style Markdown content, such as notices. Now, I can make notices in my Markdown using the same HTML-based templating structure instead.

Before (Jekyll / kramdown):

This is an info notice, which would be a blue-background box with text inside.
{: .notice--info}

After (Astro):

<Notice type="info">
   This is an info notice, which would be a blue-background box with text inside.
</Notice>

Going Forward

So, now that you’re reading this, you’re on the new site, and hopefully you like it. Was I successful in my goals? I think I was on all 3 fronts:

1. I built the whole site myself, leaning on my old site’s template for styling decisions, but otherwise working pretty independently.
2. I love working with Astro to build the site.
3. I’m writing this post in Markdown just like I would have on the old site, but with the slightly nicer syntax I explained above. And I’ve built components to reuse the same content collections, so my photo gallery pulls its content directly from the same images I’ve used in other blog posts.

This revamp has left me feeling invigorated to continue posting to my site and to continue making improvements to it over time. For the first time in years, I’ve got multiple blog post ideas floating in my head, and I’ve also got a long list of features I’d like to add to the site that weren’t part of the minimal viable product I needed to replace my old site. It feels good, and expect more to come soon. (Hint: birds.)