Gator: Yet Another Static Site Generator

This morning I woke up screaming and crying because I realized that there just weren’t enough static site generators out there. It’s ok now, I made another one. You can thank me later.

Now, why is my static site generator better than yours? It all boils down to two things: I sacrificed performance for convenience, and I need features specific to my usecase.

Use Python for templating

I feel popular SSGs have made very bizarre choices to squeeze as much performance out as possible. This is just a minor gripe, but Hugo doesn’t even have binary operators — all binary operators are functions.

｛｛  $output := or A (add B C) ｝｝

Their target audience is probably professional blogs who have thousands of pages they need to render, but I’ll probably never even reach 100. I’m ok waiting 3 seconds more for my website to render if writing pages is more convenient.

Additionally, I don’t like having to memorize all the quirks and functions for a superfluous tool I only use once every few months.

Gator just you use Python to programmatically generate content. This means that you can use all of the python libraries you’re already familiar with.

My name is ｛｛ $name ｝｝.
Today's date is ｛｛ datetime.now().strftime("%m/%d/%Y") ｝｝.

Since we’re using the Python interpreter, you can use all of Python’s convenient language features (for example, x if y else z) and functions (s.lower(), s.strip(), etc).

More flexible templating

Most SSGs have severe restrictions on their templating engine in the pursuit of having the fastest benchmarks. For example, in Hugo, you can’t use shortcodes within your template files or within other shortcodes. It’s annoying.

Server-side math rendering

Most blogs require you to download a heavy javascript file like KaTeX which searches for and renders math blocks in your browser. My SSG renders math blocks while generating the site. No client-side Javascript necessary.

Custom Markdown dialect

I frequently use certain components (mermaid diagrams, sidenotes) but using them as a shortcode was not good UX. I extended the markdown language to give them first class support.

.ipynb support

Writing using Python notebooks is a very convenient and natural format for programming blogs, but almost no SSG supports them because most SSGs are designed to be general purpose. I made including notebooks as easy as any other markdown file.

I used to have this weird workflow where I would have to write python code to calculate numbers or create matplot graphs. Once I was done, where would I keep that code if I want to make changes later? I felt python notebooks were the best and most natural way to keep my code and writing together.