About This Website

05/06/2026        

This post aims to answer two questions:  why I created this website in its present form, and how this website (and associated components) were built.

Why a website?

A lot of devs, in my opinion, throw up a website as what is essentially a prettier version of a resume. I explicitly think that those kinds of websites don’t mean much, with website templates and AI making the creation of good sites not a great indicator of technical talent.

Rather, I believe that there’s a lot a LinkedIn crawl or resume overview doesn’t tell you about a person. This website, above everything, is meant to provide context about who I am and what I do. I’m not much of a social media guy, so consolidating my thoughts onto one platform will be, I hope,  useful for anyone curious about me.

How’d I build this site?

First, we should answer a question– why build a site like this at all? Why not use Substack or Medium or some other platform, and just spit out ideas?

  1. I wanted to create a flow that allowed me to directly write from a Google Docs as “source material”. I made a companion extension that propagates changes from a master doc to this website, which makes my specific workflow of editing and publishing easy

  1.  I wanted to build a software product that I myself use, to give myself the experience of maintaining a long-term tool.

  1. I felt like it. I see this website as an application of both my interests in the humanities and software engineering. I hope you enjoy exploring it as much as I enjoyed creating it.

Now, let’s get into the technical bits:

  • I built this website on the Astro framework. This was largely because I wanted to compare it to Next.js (which I’m more familiar with), and because Astro is explicitly better at building websites that are as JS-light as this project was going to be. It ended up being a good choice– the only page that really used JS was the homepage, which I could hydrate specifically.
  • I only use HTML + CSS + JS, no React. There was honestly no need.
  • From the beginning, I knew that there were going to be three main components of my writing process– drafting on Google Docs, previewing locally, and deploying the site properly. The site itself handles the latter two steps, but the Docs -> Local Preview pipeline is handled via a Chrome extension and lightweight local server that runs along with local dev launch. This is the only
  • I hosted the site on Cloudflare pages. Pretty default, wasn’t going to rock the boat there.

Diagram of website flow

In all honesty, most of this project was fairly boilerplate. The tagging + sorting system is particularly inefficient because it’s a straight linear sort for each combination of tags, and the changing text component is a simple JS script. In practice, the only interesting component is the extension and local server.

The extension does almost no work itself. It just detects the current Google Doc and active tab, then POSTs docId and tabId to. The compiler server does the real work.

  What content.js does:

  • checks the Google Doc title with document.title
  • renders a floating Compile Tab button
  • on click, sends metadata to the server

The compiler is an Express server in compiler/server.js. In dev it is started by the root npm run dev script in package.json, alongside astro dev.

  It exposes a series of localhost endpoints for the Chrome extension and authentication process (server can read the Google Doc, but not edit it).

  The compile path is:

  1. Extension sends docId and tabId
  2. Compiler fetches full doc structure from Google Docs API
  3. Compiler extracts metadata from tab plain text
  4. Compiler renders HTML for the tab body (Google API command)
  5. Compiler downloads/relinks images
  6. Compiler cleans exported metadata from the body
  7. Compiler converts HTML into markdown with frontmatter
  8. Astro reloads and serves/builds from those generated files

I’d say the biggest lesson learned through this entire process is to not duplicate work. A lot of effort is put into relatively ‘hidden’ systems that you can 100% leverage if you ever want to customize a workflow or build out a tool. There’s no reason to define a new Doc to HTML pipeline when one exists, nor is there a reason to say, make text editing software when Google Docs is what I’d prefer regardless. On the other hand, it’s 100% necessary to build out certain tools if the equivalent doesn’t exist and you need it badly enough– i.e. this website.