Reflections on setting up a personal site • Aaron J Epel

The site is now live as of May 13! Honestly, this project was a fun, self-contained departure from my usual, and I enjoyed tinkering with it. Here are a few reflections on the development process:

Framework

I used Astro JS as a web framework for the site. This was a straightforward decision: I wanted a lightweight static website, and this was highly recommended on social media and various blog posts. Additionally, it has extensive documentation and is mature but actively developed and seems well-maintained.

I found that the developer tutorial alone was very comprehensive and easy to follow.

Template

After comparing several free Astro template options, I decided that SRLEOM’s astro-theme-resume template was a good starting point. The two main features of the site would be the “about” CV page and the blog, and this template had a resume layout that I liked.

One feature I wanted was a clean landing page in the style of the Astrogon template, which was straightforward to add to the starting point template. Otherwise, pretty much everything I wanted already existed in the astro-theme-resume template or just required some tinkering to restyle.

Package management

Before this, I had basically no experience with Node.js - all of my prior web dev contributions either involved Django or were limited to vanilla HTML/CSS. As per the Astro JS tutorial, I started off using npm to manage packages and found this very easy compared to e.g. pip or conda, and similar to uv.

One thing I wanted to do was upgrade all dependencies to their current versions as much as possible; the template uses Astro 4.4.15 but the current release is 5.7.10. Iteratively updating package.json and attempting dependency installs was relatively straightforward and fast.

As I got closer to live deployment of the website, I realized that the template was not ideally set up for npm, but rather pnpm. Migrating the workspace to use this was a little confusing at first but ultimately not so hard to figure out. As I understand it now, there’s little reason not to use pnpm from the start for future projects - is that right?

SVGs

One aspect where I spent too much time tinkering was with centralizing SVG assets for icons. The template (built in Astro 4.4.15) relies on the astro-icon extension, but as of Astro 5.7.0 image components can be automatically created for SVGs, and I wanted to use this built-in feature instead. This required some refactor of helper components in the initial template. The official documentation was helpful, but still required a little experimentation to perfect it.

One thing I wanted to do was use monochrome SVGs for the experience item icons on the About Me page, and have their color reflect the light/dark theme setting. Once I found the right, freely licensed images, this was as simple as removing the fill color from the SVG tag contents. Very convenient!

Tailwind

The only previous project where I’ve used Tailwind was inherited from other developers who incorporated it haphazardly. I get it, but I’m still skeptical of the philosophy of reimplementing CSS styles as classes and just composing them for each element. I can definitely see why this might be useful for constraining theming to be consistent across multiple front-end developers.

The template I started with defined the Tailwind theme in tailwind.config.js, but then injected colors as variables defined in a separate, global styles/app.css. It took me a little while to figure out which of these two files was the best place to e.g. implement a gradient background image. I’m not convinced it wouldn’t have just been easier to use a single CSS file, if I were to create this project from scratch instead of a template.

Deployment

I decided to use Cloudflare for my hosting and domain name registration. Specifically, I am using Cloudflare Workers to serve my site. The main factors leading me to choose Cloudflare were its free plan for static sites, in-house domain name registration, and DDoS protection on the free plan.

Whereas standing up a local webserver to preview the site was trivial, deploying live was the main challenge for me and where I learned the most. I suspect that this is because of my inexperience and not because Cloudflare is particularly difficult to use.

Domain registration was easier than I thought. I was surprised that www.ajepel.com was somehow available - I didn’t think I would be able to get a .com domain close to my name!
I started with the Astro official guide to deploying a static site on Cloudflare Workers through Github CI/CD, but found this wasn’t on its own sufficient to get my build to succeed and make the site accessible at my domain. Here are some of the steps I needed that weren’t obvious to me at the time:
- Pin the package manager in package.json for Cloudflare Workers CI/CD build to consume:
```
"packageManager": "pnpm@10.11.0"
```
- Add “routes” key to wrangler.jsonc including my domain and the custom_domain flag. I thought that this would be handled automatically by Cloudflare Workers once I added my custom domain in the UI, since the DNS entry was automatically added, but that may not have been the case.
```
"routes": [
    {
        "pattern": "www.ajepel.com",
        "custom_domain": true
    }
]
```
- Set static output in astro.config.mjs:
```
output: 'static'
```

After waiting for the DNS records to update for my domain, the site was live! I don’t think I’m ready to become a professional front-end developer… but I’m glad I set this up myself and learned about how lightweight sites like this are built and deployed.