---
post_date: 2026-07-12
---

# The great tjp.lol rebuild of 2026

Yesterday, I fully rebuilt the site hosted here at the base `tjp.lol` domain.

It was awfully quick and smooth for how ambitious the project was. I created a whole new design, built a whole static site generator to construct it, and back-ported old posts from my "gemini capsule" (a website in the obscure [Gemini protocol](https://geminiprotocol.net/)). A lot of this speed came down to using LLMs for the busy work of writing the bulk of the code.

> I will never publish AI-authored content on this site without a clear disclaimer

I'm ruminating on a post in which I'll lay out my stance on AI assistance with coding because it's a fraught topic with strong opinions on all sides, but I take a fairly nuanced view that probably won't satisfy anybody. The best I can probably hope to do is convince most people that I have at least taken the ethical questions around it seriously. But that's not this post. For now, suffice it to say that while I use AI assistance in coding, and I may even write on here about that experience, I will _never_ publish AI-authored content on this site without a clear disclaimer (and while my promise is just that I'll _tell you_, I also have no intention of using AI for prose on my personal site).

But I derived a lot of value from using AI tools to make this transition happen, and it came rather cheaply as well. The authorship of the static site generator ([`weft`](https://code.tjp.lol/weft.git)), the porting of my gemini capsule pages, and the initial design all were made dramatically faster with AI assistance.

Going forward, I'm happy to have a better showcase for my coding projects, I want to get back into writing more frequently, and I hope the public exposure of my notes will help spur me on to filling those out as well.

<!--
## weft - the site generator

The strategy for hosting this site is to use a pretty bog-standard web server ([Caddy](https://caddyserver.com/) in this case), and convert a pile of my hand-authored markdown into a pile of HTML.

Partly because it simply provides a better experience, and partly in protest of what the web has become, there's no javascript on this site either.

The constraints on weft came really from 3 kinds of pages I wanted it to render for me:

1. static/global pages: landing page, "About me", and so on
1. weblog posts
1. notes pages

In some of the static pages I wanted to have things like "most recent posts" automatically update as I created new posts. Other static pages should optimize for the authoring experience so should probably be sourced from markdown, but those are mutually exclusive, so I needed two kinds of sources. Also needing markup consistency between these two, it was obvious what the two source options would be: I was going to need a templating engine in place regardless, and markdown is the obvious human-friendly authoring format.

I went with go's `html/template` library, since it's pretty powerful, has strong injection protections, and is included in the standard library. For parsing markdown as far as I can tell [`yuin/goldmark`](https://pkg.go.dev/github.com/yuin/goldmark) is the gold standard - an easy dependency to accept.

My notes are already kept in markdown, and I've made an effort to avoid relying on client-specific features (so even though I use obsidian on android, I don't even use `[[wikilinks]]`, and certainly not any other obsidian-specific features), so they would remain forever portable. I can easily enough do the same with blog posts, though I do accept a few GFM-style enhancement over CommonMark.

Now, `weft` lets you set the html formatting for different page types in `html/template` templates, and write the content in markdown. There's a simple matching algorithm where by the name of the template you can specify the section of the site (by URL path prefix) it should be responsible for laying out.
-->