TL;DR: New Pelican blog! You can email-subscribe via https://list.evanchen.cc.

If you’re reading this, that means I’ve successfully moved my blog from WordPress to Pelican! If you want to see how this website was made, you can see the entire source repository. There might be some things off with the migrated old posts; open a pull request if you spot any and I’ll be grateful.

See the subscribe page if you want to subscribe.

1. New features for readers

Really the primary motivation for the migration is easier maintenance for me. But readers might notice a few nice things:

• A new skin that’s more minimalist.
• Sidenotes.
• Server-side LaTeX rendering instead of the hacky WordPress images.
• Cleaner URL scheme: this post will be blog.evanchen.cc/pelican instead of the old URL scheme with the dates. (The old URL’s will still be redirected.)
• You can now view the source version by clicking the pencil icon. (And submit pull requests when you find typos.)

2. Motivation

If it ain’t broken, refactor it anyway.

I made my blog on WordPress when I was still a teenager and didn’t use Git much yet. Now that I’m wiser, I’ve been itching for a long time to switch to a headless static blog that’s built directly out of a Git repositoryThis may be a bit immodest, but I also want to set a good example for kids. By which I mean, I’m sure many of my students will start a blog one day. And a few of them will use this blog as a reference while exploring software options. So I better do it right!. A list of things that bugged me about dynamic site:

2.1. Having to uglify data for a server I don’t control

I always draft my posts in Markdown or LaTeX. But after my post was done, I would have to run it through either my LaTeX uglifier or Markdown uglifier to get it to be HTML. Then I’d have to manually insert images and check the preview.

That always felt hacky and hard to maintain. For example, to fix a reported typo, I would need to:

1. Fix it in my local copy in Markdown.
2. Run the uglifier script to get some HTML I could paste into WordPress.
3. Re-add any images manually, because the uglifier couldn’t handle those.

The core problem is that I had to maintain another copy of every post in a brittle format on a server I don’t own.

2.2. Having a server at all

Look, this is a blog. All I need is to serve static webpages. Having to use an entire server just to do that is just unnecessary bloat. (I never touched most of the stuff in the WordPress admin panel.)

Even for personal aesthetic reasonsI’m not kidding about “personal aesthetic” being a motivator. I think a blog should reflect the personality of the owner. And using WordPress is just not-Evan on so many levels., I want to KISS. I think the website should be single repository of posts in Markdown format, plus as little code as needed to generate the output I want. Much more portable and maintainable.

The blog is the repository now.

2.3. Lack of control via arbitrary code

Sometimes I do want to change or add something, like the layout, the default URL format, the LaTeX rendering engine, or sidenotes. And I have no problem writing codeOr having an LLM write the code. It is 2026. for that. So I wanted a system that lets me write arbitrary code.

2.4. Markdown is a better data format

For example, now I can use rumdl to detect Markdown issues, and codespell to automatically find typos. And people can directly make corrections with pull requests. I can search more easily with grepOkay, that’s a lie, I use ag and rg.. And so on.

2.5. Cost

I was paying 84 bucks every couple years for a WordPress plan so that I could use the blog.evanchen.cc domain name, and I think that didn’t even let me use plugins. Cloudflare FreeI have never understood how CloudFlare Free lets you do so much., which deploys the site, costs me nothing. And if that ever goes away, static sites are easy to move to other places.

3. Comments

I thought about enabling comments but decided not to. Sorry. I always had trouble checking the WordPress comments anyway, and sometimes the comments are really things that should be email questions to me (often completely unrelated to the post).

Never mind we’re going to try out isso-supported comments for a bit and see how it goes lol. Trust.

4. Why Pelican?

There are a lot of different static site generators out there. For this blog, I ended up going with Pelican because I wanted to work with Python for the customizations I wanted. I do pay for it in compilation speedThe slowest part of the rendering is actually the LaTeX, which isn’t Pelican’s fault. I think the server-side KaTeX rendering is done in Node, and that’s like 80%-90% of the build time. To be concrete, right now with 160ish pages, building the whole blog takes about 4 seconds without KaTeX and about 25-30 seconds with KaTeX..

That actually need more DIY than I would’ve liked. The scripts/ directory is the result of that. None of those scripts are used for the compilation itself. They’re all QoL improvements for my editing experience, like a script to scaffold a new post, or having a dev server only compile posts for the last year-ish in order to speed up the compilation time for previewing posts.

I think for websites where I didn’t need arbitrary code customization as much, I’d go with Zola; in fact my microblog wall.evanchen.cc is on Zola. I’m also using Zensical for some other projects I haven’t shown anyone yet.

(By the way: Why do so many SSG websites start with get in their domain name? Like getpelican.org, getzola.org, getlektor.com, getnikola.com, …. Is that secretly a pun on HTTP GET requests? Because if so that’s genius.)