profile picture of Keith BartholomewKeith Bartholomew

How I Run This Site

It's a well-worn cliché that developers overthink how to host their personal blogs, and I'm no exception to that. Web developers are a lucky bunch; if you gave us a pile of static HTML files and tolds us to edit them manually to maintain a website, we would get along just fine. That would be practical, but not very fun. And most of us aren't running personal websites out of necessity—we're doing it because it's fun! Developers want their websites to be complicated, because a personal website is a low-stakes place to experiment with new ideas and show them to the world.

A Brief History of my Website

Throughout the years, my personal website has been a reflection of my professional interests:

  • 2010: A combination of a hand-written PHP site and a WordPress blog which I decided should be brown for some reason. I bragged about my experience with jQuery and AJAX. The Wayback Machine didn't capture this version of the site very well, but I remember that I had traced a photo of myself in Adobe Illustrator to appear as a cartoon-like effigy of myself at the top of every page.

  • 2012: I redesigned the WordPress blog and expanded it to handle the entire site. I was doing lots of tiny web development posts and demos, much like I'm doing now.

    A snapshot of my website from 2012

  • 2013-2016: I somehow resisted the urge to completely redesign my website, only giving it a minor style refresh (skeuomorphism was going out of style around this time). The biggest change during this time was that I migrated all the content to the ExpressionEngine CMS. I was growing tired of trying to make WordPress work well as a generic CMS and wanted to give a "real" CMS a try. The experience landed me a job at an agency that specifically wanted ExpressionEngine experience, so I guess it worked!

    A snapshot of my website from 2014

  • 2018-2023: A mostly functional bash terminal emulator written entirely in JavaScript. Around this time I was less interested in blogging and more into development and systems work, probably managing Kubernetes clusters. I wanted my website to be more of a calling card, letting my work on GitHub speak for itself. Instead of making anything resembling an actual website, I made a full-screen terminal emulator using xterm.js and a bash-like terminal that I wrote from scratch. You ls to list files, cat files to read them, or open them to open links in a new tab or view images and markdown in a modal. You can even reboot to reload the website!

    A snapshot of my website from 2018

    I'm still very proud of how this iteration of my website turned out, but the single-page, interactive nature of it made me all but disappear from search engine results, leaving my arch-nemesis Keith Bartholomew from the University of Utah as the most findable Keith on the Internet.

  • 2023-present: Next.js, prerendered as a static site. I wanted to keep the terminal emulator look-and-feel, but have something that behaved more like a traditional website. As I mentioned in "Back to Blogging", I wanted to get back into writing because I noticed that many of the professional software developers I look up to are prolific writers.

The Frontend Stack

This is a Next.js site. I'm using the output: "export" setting to bundle the entire thing as static HTML files so I can host it on any static-site platform at nearly zero cost. My blog posts are all Markdown (MDX) files, and I use a small collection of packages to parse them and their frontmatter and scaffold out navigation for the site.

Next.js is a borderline boring decision to make in 2023. I could have used an even more boring static site generator like Jekyll, but Next.js gives me the opportunity to pivot this static site into more interactivity if I want to do that in the future. It's also what I'm using at work right now, so I'm very comfortable with it.

I'm using Tailwind to manage the styling. A big hurdle there was writing a bunch of @apply expressions with regular CSS selectors to apply the Tailwind utilities to the content in my blog posts, which usually get rendered without any inline styling.

The Hosting Stack

I made the boring decision with Next.js and Tailwind, so I had some room to be slightly less boring with the hosting. Hosting static websites is incredibly easy these days. Netlify, Vercel, GitHub Pages, and CloudFlare Pages will all serve static sites with a custom domain for free, with zero effort on my part.

But where's the fun in that?

My website has always been a way for me to experiment with my professional interests, and these days my interests are shifting more towards infrastructure, specifically on AWS. Boutique static hosting providers aren't always a great fit for large companies...can I build a similar experience using AWS?

AWS Amplify

I gave AWS Amplify a shot at first…it works well with both static and dynamic sites, and has integrations that let you add custom domains and distribute the site behind a CDN like CloudFront. However, I found that the only way to deploy a site to AWS Amplify is using their proprietary build system. This build system was a little difficult to use, and very expensive (you pay per minute of build time). In just a few days of testing, I had already racked up a bill larger than what I wanted to spend to host the site for an entire month.

Amplify is still an interesting product for applications that absolutely need server-side behavior, but it wasn't a good fit for my static-site needs.

CloudFront and S3

The obvious AWS tools for a static site are CloudFront and S3. Given how simple and common this use case is, I'm surprised at how much work it is to get a working site using them.

AWS recently announced the CloudFront Hosting Toolkit which is a CLI that claims to make this a lot easier.

← All Posts