Nathan Tebbs

Adding swag to my zero-dependency static website generator

Fri, 23 Oct 2026 00:00:00 +0000

A month ago I wrote about building this site with nothing but Emacs and Org mode. I called it a zero-dependency static website generator. This site now builds with a tool I wrote instead. It is called swag, short for Static Website Assembler and Generator. The switch made me count what the site really depends on, and the old count was wrong.

What changed

The posts are now Markdown files, and I write them in neovim. A single Go binary called swag turns the content/ directory into the docs/ directory that GitHub Pages serves. Every URL from the Org version still works, so old links and the RSS feed did not move.

The repository looks like this now:

content/    Markdown pages and posts
layouts/    HTML templates that wrap each page
static/     CSS, images and CNAME, copied as is
docs/       generated site served by GitHub Pages
swag.conf   site title, URL and description

The config is a plain key = value file:

site.title        = Nathan Tebbs
site.url          = https://vetr0s.dev
site.description  = Notes on software and the things I learn while building.
params.stylesheet = /style.css

Every post starts with a front matter block:

---
title: Adding swag to my zero-dependency static website generator
date: 2026-10-23
description: Swapping Emacs for a small Go program.
---

That is not YAML. Each line is a key, a colon and a value. swag has no YAML parser, and it doesn't need one.

Why I left Org Publish

My editor changed. I moved my day-to-day work from Emacs to neovim, and the build had to move out of the editor with it. The Org setup only ran inside Emacs, either through M-x or through a batch Emacs process. Keeping Emacs installed just to publish a blog felt backwards.

I also wanted a few things Org Publish made awkward:

A preview server that rebuilds and reloads the browser when I save.
A build that fails on a broken internal link.
Errors that name a file and a line, so neovim can jump to them.
Output that stays byte-identical between builds, so git diff docs/ shows only real changes.

I did not want a framework. swag has no plugin system, no themes, no tags and no pagination. It is about 2,200 lines of Go plus 1,400 lines of tests, and I can read the whole thing in an afternoon.

Counting dependencies honestly

"Zero dependency" was never literal. Here is how I count now.

Level 0 is the platform the generator runs on. Every option needs one. Before, the platform was Emacs. Org mode ships with Emacs, so I counted Org Publish as free. That was only true because Emacs was already my editor. Syntax highlighting also needed htmlize, which is a third-party package. Doom Emacs happened to install it for me, so I never noticed.

Now the platform is Go. Go compiles swag, and swag uses only the standard library. Its go.mod has no require lines:

module github.com/vetr0s/swag

go 1.27.3

A test fails if that ever changes. The compiled result is one 13 MB binary, and running it needs no Go toolchain.

That leaves one real addition, which is pandoc. swag contains no Markdown parser. For every .md file it runs a command from the config, writes the post body to that command's stdin, and reads HTML back from its stdout. The default command is pandoc:

render.md = pandoc --from=gfm --to=html5

Pandoc also does the syntax highlighting, so htmlize is gone. A site written in plain .html files would not need pandoc at all.

So the honest before and after:

before:  Emacs (platform) + Org (bundled) + htmlize
after:   Go (platform)    + pandoc

I swapped one platform for another and traded htmlize for pandoc. The count did not drop to zero. It stayed at one, and this time I can name it.

How I use it

Writing a post starts with swag new. It prints only the path of the file it creates, so it composes with the editor:

nvim "$(swag new 'Adding swag to my zero-dependency static website generator')"

The new file starts as a draft. While I write, swag serve runs in another terminal. It builds into a temporary directory, never into docs/, and serves the result on localhost. It checks for changes every 500 milliseconds and reloads the browser after each rebuild.

Inside neovim, swag build works as a make program:

:set makeprg=swag\ build
:make

Errors come out as path:line: message, so a bad date or a broken link lands in the quickfix list:

content/posts/about-me.md:3: invalid date "2026-13-01": use YYYY-MM-DD
content/posts/colophon.md: broken link "/posts/old.html"

A full build of this site takes under a second. Nearly all of that is pandoc rendering this post, which is the longest one. swag builds into a temporary directory and replaces docs/ only after every step has passed. A broken post can't leave half a site behind.

Publishing did not change. I run swag build, commit docs/ and push, and GitHub Pages serves the files.

The neovim plugin

Since writing this I added swag.nvim, a small plugin that runs swag from inside neovim. It replaces the makeprg setup above. It is about 150 lines of Lua and has no dependencies beyond swag itself.

It adds four commands:

:SwagNew {title}    create a draft post and open it (:SwagNew! makes a page)
:SwagBuild          build in the background; errors go to the quickfix list
:SwagServe          start the preview server
:SwagStop           stop it

While :SwagServe runs, every rebuild replaces the quickfix list with that rebuild's errors. A bad date shows up about a second after I save, and the list empties when I fix it. Broken links show up as warnings until I build for real. Every command runs swag from the current buffer's directory, so it finds the site from any file in it.

Neovim 0.12 has a built-in package manager, so installing it is one line in my config:

local gh = function(repo) return 'https://github.com/' .. repo end

vim.pack.add({
  gh('vetr0s/swag.nvim'),
})

There is no setup() call. If you want keys for the commands, map them like any other:

vim.keymap.set('n', '<leader>wn', ':SwagNew ', { desc = 'New post' })
vim.keymap.set('n', '<leader>wb', '<cmd>SwagBuild<CR>', { desc = 'Build the site' })
vim.keymap.set('n', '<leader>ws', '<cmd>SwagServe<CR>', { desc = 'Preview the site' })

Where it lives

swag is on GitHub at vetr0s/swag under the MIT license. The plugin is at vetr0s/swag.nvim, and the source for this site is at vetr0s/vetr0s.dev. If you have Go installed, this gets you the same binary:

go install github.com/vetr0s/swag@latest

I built swag for one site and one maintainer. If it fits your site too, take it.

Colophon

Fri, 18 Sep 2026 00:00:00 +0000

This website is written in Markdown in neovim and built into plain HTML by swag, a small static site generator I wrote in Go. Pandoc renders the Markdown and highlights the code. A small CSS file handles the presentation, and the pages use system fonts. There is no client-side JavaScript.

Posts and pages live in content/, the page templates in layouts/, and static assets in static/. swag writes the finished site to docs/, which GitHub Pages serves. I describe the setup in Adding swag to my zero-dependency static website generator. The Emacs and Org setup it replaced is in A zero-dependency static website generator.

The site intentionally has no analytics, tracking, comments, or cookie banner. You can follow new posts through RSS or reach me at nate@vetr0s.dev.

A zero-dependency static website generator

Wed, 16 Sep 2026 00:00:00 +0000

If Emacs is already your primary editor, you have a static website generator. Org mode and its HTML publishing tools ship with Emacs, so there is no separate generator to install, package manager to maintain, or application to run in production. Compared with adding Hugo or another tool to my setup, this site is effectively a zero-dependency build.

That does not mean the website depends on literally nothing. It means Emacs is the only build tool, and I already use it to write the source files.

Project layout

The repository separates source files from generated files:

content/    Org pages and posts
static/     CSS and other files copied without changes
docs/       generated site served by GitHub Pages
publish.el  Org Publish configuration

The files in docs/ are generated from content/ and static/.

Publish configuration

Org Publish already has the two operations this site needs: export Org files to HTML and copy static files. The configuration combines both into one project named blog.

(setq org-publish-project-alist
      '(("blog-pages"
         :publishing-function org-html-publish-to-html)
        ("blog-static"
         :publishing-function org-publish-attachment)
        ("blog"
         :components ("blog-pages" "blog-static"))))

The real configuration derives its directories from the location of publish.el. This keeps the build independent of the directory where Emacs starts. Org supplies a baseline stylesheet; the small site stylesheet loads after it and adjusts the reading width, links, and navigation.

Publishing from Emacs

My Doom Emacs configuration loads the project file:

(load (expand-file-name "~/source/blog/publish.el") nil 'nomessage)

That registers the publish projects and defines vetr0s-blog-publish. I run it with M-x vetr0s-blog-publish. A prefix argument forces Emacs to rebuild every file.

The same project works in a clean Emacs session, without Doom:

emacs --batch -Q --load ./publish.el --funcall vetr0s-blog-publish

Batch builds always force a full rebuild. During interactive builds, Org keeps its incremental build cache in .org-timestamps/. If the optional htmlize package is present, source blocks get syntax colors; the site still builds without it.

Deployment

The build produces plain files under docs/. GitHub Pages serves that directory from the repository's main branch at vetr0s.dev. There is no application server, database, JavaScript runtime, or generator-specific deployment service.

Publishing means running the batch build, reviewing the generated files, and pushing them to GitHub. For a personal website, Emacs, Org, and a little CSS are enough.

About Me

Sun, 23 Aug 2026 00:00:00 +0000

Foundations

I grew up in Olympia, Washington. My first experience with programming was through Scratch block programming in a 7th-grade visual communications class. We were given an open-ended assignment where the objective was to create anything that interested us. I ended up creating a pretty simple Space Invaders clone with a couple of levels, a final boss, sprites, and a very rudimentary bullet-physics system. While most of the work was just learning from examples on Scratch's website, this first interaction with programming concepts made me want to keep exploring. My teacher was pretty impressed and invited me to join the 8th-grade robotics class. That class introduced me to competitive robotics, which became a major part of my high school experience.

Around this time I also discovered "real" programming languages. I made the naive mistake of searching the internet for "What programming languages are used to make video games?" This sent me down a rabbit hole of trying to use C++ without understanding OOP, C, or pretty much anything else that you would need to know to even start learning C++. The only reason I didn't give up instantly was that I was following a beginner tutorial and framework on YouTube.

Shortly after, I had successfully set up Visual Studio 2017 and created a basic game. It opened a window, rendered individual putPixel(x, y) calls to form a crosshair, and polled keyboard arrow input to move the crosshair between set locations. However, I soon realized that I was in over my head, both academically and technically.

This inspired me to research more entry-level paths to programming, which led me to learn the basics of HTML, CSS, JavaScript, and Python.

I have not lost my passion for "lower-level" development or game development. I still enjoy working close to the machine through projects like Mach/mach.h, and I want to spend more time exploring compilers and programming language implementation.

Work experience

Cloud Computing Preceptorship

During spring 2026, I worked as a teaching assistant for CSc 346: Cloud Computing at the University of Arizona.

Every week I held office hours where I helped students debug projects and development environments. The course covered cloud fundamentals through hands-on projects using services like AWS, EC2, S3, and Lambda.

Helping teach the course was just as valuable as taking it myself, if not more so. Debugging with students taught me to explain problems clearly and improved my technical communication skills.

Sound Psychiatric Services

I have worked as a contract software engineer for Sound Psychiatric Services since January 2021. I met the business owner through community outreach I was a part of in my high school robotics program, and they asked me to build the practice's public website. The site directs existing patients to its electronic medical record, payment, and telehealth portals. It also gives prospective patients the information they need before a visit. The initial design and implementation loop took about a month, and then my role shifted toward occasional maintenance tasks.

Once I started college, I wanted to do more than just front-end development for the practice. Initially, I identified that the practice was subscribed to a business web hosting package that was overkill for the simple static site. So I moved the website from the paid plan to free static hosting via Cloudflare Pages. More importantly, the transition was seamless for the business because the migration kept business-critical features such as domain and email services in place.

I also support custom in-house software for the practice that deals with non-confidential data. For example, I built a tool that reads serial data from a medical scale, displaying live weight on the doctor's PC. I built this after the scale's original display failed.

Work like this has taught me how to change small systems without disrupting the people who depend on them.

Education

I graduated from the University of Arizona in May 2026 with a B.S. in Computer Science. Before Arizona, I earned my associate's degree alongside my high school diploma through Washington state's Running Start program.

High School Robotics

For four years, I was part of Olympia Robotics Federation 4450, an FRC robotics team. I joined as a freshman when the team was quite small; four of us became its dedicated core that season. By the time I graduated, the team had grown to nearly 50 members. During my final two years on the team, I served as Safety Captain and Build Team Lead. This gave me direct responsibility for shop, robot, and event operations and safety.

FRC shaped how I think about engineering more than almost anything else I've done. I entered high school wanting to study computer science in college. I left knowing I wanted a career built around difficult technical problems, small teams, and building things that make a real impact.

Egypt expedition

During my third year, one of our mentors connected us with a mother whose son attended a STEM school in Cairo that used LEGO-based robotics. We decided to help bring metal-based competitive robotics to the school since FTC had yet to expand to the region.

Over the next 10 months, our team raised around $60,000 through community outreach. The following summer, 17 of us traveled to Cairo with several FTC kits, a custom curriculum, and an accompanying end-of-week challenge that I helped design.

Students and mentors with one of the FTC robots in Cairo.

The following season, our team also reached the FRC World Championship in Houston to compete for the Impact Award because of the team's outreach efforts in Egypt.

Our shared pit at the FRC World Championship in Houston.

HackAZ 2026

In April 2026, I spent 24 hours with three teammates building GridWise Energy at Hack Arizona, the University's flagship hackathon, for the AI Environmental Sustainability track.

GridWise is a personal electricity carbon-footprint tracker for Arizona residents. Users log high-draw appliances such as HVAC systems, EV chargers, pool pumps, and dryers. The app estimates their emissions using their local grid's energy-source mix, tracks the grid's carbon intensity, and encourages users to shift heavy loads toward periods where solar and Palo Verde's nuclear generation are supplying more of the grid's energy.

We shipped it at griddaddy.us.

The GridWise team at Hack Arizona 2026.

We chose a less serious name in an effort to compete for the most creative or funny name, so we took inspiration from Scrub Daddy.

The stack included React, TypeScript, Vite, Tailwind CSS, shadcn/ui, Vercel serverless functions, Neon Postgres, and Auth0. For the AI portion, we used a Gemini-backed assistant for usage insights and trained a small ridge-regression model to forecast grid carbon intensity.

The name

vetr0s comes from the Italian vetri, plural of vetro, meaning "glass" or "windowpane." I enjoy having an online alias for development-related things for a couple of reasons. Growing up playing Xbox, gamertags were an essential part of my introduction to the internet. When I got older, I found that a lot of programmers I look up to use Latin-inspired aliases, such as nothings and Tsoding. I also just think the domain looks better than something like nathantebbs.com.