The Zine Static Site Generator

April 22, 2026

The internet of my dreams has three characteristics:

People of any background should be able to publish their work. If I’ve written an important document that I want to share with the world, I should be able to share it. I should be able to share it regardless of my income or current technical know-how. Most people with worthwhile thoughts are not wealthy or professional web developers, and these should not be prerequisites for contributing to the public square.
Content is not centralized on any hosting platform. People should be able to publish their documents without going through some specific social media site, or some specific web hosting service. Your ability to publish should not be dependent on a powerful corporation, but that’s a low bar—it also shouldn’t be dependent on any third party that might cease to be willing/able to host your content. And if your current content is hosted by some third party, you should be able to pack up your content and leave, publishing it elsewhere.
Accessing content should be low-latency. If I click a link to a page, that page should load instantly. If it can’t load instantly, it should load as fast as current technology permits. If technology improves, the page should take advantage of that new technology to load faster.

I care about many other aspects of the internet, too. Data privacy, accessibility for those with impaired hearing, sight, or hands¹, the development of positive and healthy discursive communities—there’s a lot that I think the internet needs to get right.

Most of these things that I want from the internet can be accomplished with static sites, each of which is owned and produced by individual people.

Static sites are excellent, if you can get away with one. Sometimes you can’t. By definition, a static site does not allow for back-and-forth transfers of data between the user and a server, aside from a fixed collection of files that are sent to the user on initial page load. Furthermore, a static site will not perform client-side rendering², where either JavaScript (or WebAssembly + some minimal JS for DOM access) is used to construct the page’s content once the JavaScript/WebAssembly arrives at the user’s computer. If either of those architectural features are required for the content you’d like to make, then you cannot use a static site.³ But if you do not need those architectural features—and I think the vast majority of people do not—a static site will be strictly better for your purposes. Static sites are:

Faster for initial page loads. There is no website architecture which loads the user’s first page faster than making each page a single level 11 brotli-compressed⁴ and minified .html file, where all the CSS for the page is contained with that .html file. This isn’t the kind of static site I recommend most people use. But if your pages are sufficiently small in size and you expect people to visit only a single page of your website, with no subsequent navigations to other pages, then this is exactly the kind of architecture you need. It is particularly good if you don’t know which page of your site at which users will arrive, if you’re not using webfonts, or if you’re using webfonts but the content of your page is in one monospaced font.
Faster for subsequent page loads after the user is already on the site. There is no website architecture that makes navigating to subsequent pages faster than linking a single level 11 brotli-compressed and minified .css file in the <head> of every single page’s .html file, all of which are themselves level 11 brotli-compressed and minified. This is the kind of architecture you’d want if you expect people to stick around on your website for a while, and it works especially well if you want to use non-monospaced webfont(s) for your content. Some bloggers take this approach and I think it should be the default for most static sites.⁵
Incredibly easy to archive. The Wayback Machine wishes every single website were static. It would make their life significantly easier.
Incredibly easy for search engines to find and index. DuckDuckGo wishes that every website were static, too! I’m sure they fantasize about it constantly! And Google? I keep finding these presentations from Google web dev conferences where the presenters practically plead with their audience to make their sites more static. I’m surprised it hasn’t become a running joke by now.
Easy to host and easy to pack up and move. A content delivery network (CDN), like the one Cloudflare offers, provides an enormous boost to a site’s loading speed if it consists of static, cacheable content. Cloudflare Pages lets you host your site with them, for free, and then gives you access to that powerful CDN. However, what if you decide you don’t want to use Cloudflare anymore? If you’re paying for your own custom domain, then you can just start hosting it elsewhere. I’m not aware of any way Cloudflare can engage in platform lock-in.
Not utterly broken. Browsers have “back” and “forward” buttons. You can ctrl-f for words on a page. You can refresh pages. You can scroll up and down on a page. These are features so obvious that it’s easy to take them for granted. But if your website does anything remotely fancy, like has
- tooltips
- buttons that change the page
- dynamically loading images or content
then it’s remarkably easy to break these features.⁶ And that’s not even getting into how easy it is to break a site for people who rely on a screenreader. On a static site, all these browser features work out-of-the-box the way you expect them to. And if you add content (like tooltips) in the way that is most natural for a static site, they will continue to work as you expect.

The main downside of static sites is that they have been, historically⁷, hard to create and maintain. Accessible tools to do so haven’t existed until quite recently! But they do now.

In the last few years there has been an explosion of static site generators, made by passionate open-source contributors, for making personal websites. These are programs which operate on simple templating-and-markup language files written by you, the site designer, to output a static site. Hugo is the most popular, though I’ve also encountered some people who have used Zola or Eleventy. There are many, many others, and they have many, many subtle differences.

I’ve chosen Zine.

During development, Zine builds sites instantly as you edit them, giving you real-time feedback for each change you make. I’ve constructed two sites using Zine, and the site on which you’re currently reading this paragraph is one of them. I’ve found the development process to be fun and enjoyable.⁸

Zine is low-level. Its templating and markup languages, respectively called SuperHTML and SuperMD, give you fine-grained control over the actual files on your site. I can craft my pages to be as high performance as possible. I would not be able to keep my DOM as small, my CSS selectors as efficient, and my font loading strategy as effective if Zine did not expose these details directly to me. Exposure to those details also enables me to write accessible, semantic HTML.

Zine is also maintainable. Unlike raw HTML, SuperHTML templates let you write your HTML once and duplicate it across many pages, promoting reuse and encapsulation of logic the way that a good programming language does. Furthermore, the writing and programming aspects of web development are kept separate. SuperHTML handles the low-level details of your .html files, and SuperMD handles the actual content you write. You can program the plumbing of your site once, forget about it, and focus on your content afterward.

The creator of Zine, Loris Cro, is someone who shares many of my values for what I’d like the internet to look like. Their description of the problems an average person faces trying to put their content on the web, and why that problem is so important to solve, is pure poetry. I’d like to quote part of it below:

[T]he web doesn’t belong just to software engineers. The more we make the web complex, the more we push normal users into the enclosures that we like to call social networks.
Dont you find it infuriating when lawyers and accountants fail to clarify how their respective domains work, making them unavoidable intermediaries of systems that in theory you should be able to navigate by yourself?
Whenever we fail to make simple things easy in software engineering, and webdev especially, we are failing society in the exact same way.
This is not something that startups or big tech can solve for us, their economic incentives are just too misaligned, so I invite you all to help make the web more accessible, partially as a matter of taking pride in our craft, and partially because the web used to be more interesting when more of it was made by people different from us.

(The choice of where to bold text in the above quote is my own.)

Many other static site generators were clearly informed by a web developers’ worldview. You can feel it in how they present themselves, and in the kinds of assumptions their design decisions make about their users. Take a look at Eleventy, whose landing page states:

Eleventy requires a way to run JavaScript on your computer and we recommend Node.js (version 18 or newer). You can check whether or not you have Node.js installed by running node --version in a Terminal.

They provide a link, for people who don’t know what a terminal is, that explains how to use a CLI. I think it’s great that they provide that link! But the assumption that people are 100% okay with installing Node.js rubs me the wrong way. For every thing you ask people to install to use your program, you place a barrier to entry in front of them. Why was Eleventy designed such that it requires some way to run JavaScript on your computer? Well, to quote another section of the site:

BET ON JAVASCRIPT
Always bet on JavaScript. JavaScript gives you access to npm. The npm ecosystem is large. Crazy large. And it’s only growing in popularity. According to modulecounts.com, npm has almost three times the modules of its second place competitor, Maven Central (Java). When you want to add functionality, it’s a good bet that a module exists on npm.

I don’t want to opt into the npm ecosystem. It’s a necessity if you’re a web developer, but I dream of a world where JavaScript ceases to be a language that we rely on for anything at all.

Some excellent people use Eleventy, and I think it’s a fantastic project. Zach Leatherman, the creator of Eleventy, is someone I deeply respect. His writings on web fonts are some of the most informative educational resources the internet has to offer about the topic. And he fought hard to keep Eleventy up and running during some very dark times.

But which tools I use to make my own personal website is a pretty intimate choice—I’ll be investing time and energy into learning them, for years to come, and they should match my values. Eleventy doesn’t snugly fit into those values. Despite my admiration for its creator, I would feel sad using it. It wouldn’t be right.

Zine has never made me feel this way. It is written in Zig, a language that I think has extraordinary potential to improve the world of systems programming and beyond. Furthermore, because it is written in Zig, Zine has been compiled to a single static binary that I can run on my Windows computer. No installation of anything is required. I don’t even need to add Zine to the PATH if I don’t want to; I can just place it in the directory of my personal website and run it from there. These are staggeringly low barriers to entry.⁹

Unlike many other static site generators, Zine’s source code has been written without AI contributions. I think many people in the software industry underestimate just how much of a draw that can be.

But Zine isn’t perfect yet. At the time of writing, Zine is still alpha software. It has several rough edges to be polished, and I’d like to help make it better.

I’ve been keeping track of any pain points I’ve experienced with Zine, and written them in an article that I plan to update as they are fixed. For any that seem actionable, I plan to promote them to issues on GitHub.

I would like to contribute to Zine’s development as much as an inexperienced-with-open-source-contributions, time-constrained academic researcher can, and this is the first place I can start.

In choosing Zine, I join others who feel similarly optimistic about the tools Loris is building. Zine is the tool I intend to recommend to others in my social circle who want to make a website for themselves. I’m excited to see this community get bigger, and I’m excited to see the internet get better as it does.

That’s me! I have protanopia, a form of red-green color vision deficiency. I also have a neurological condition called focal hand dystonia that severely impacts my ability to use a computer, though through lots of effort and specific exercises I’ve improved my condition to a point where I can type, write, and regularly click a mouse again.

↩

I really don’t like the term “client-side rendering,” but I’m using it here anyway because it’s what everyone calls this kind of architecture. For what it’s worth, I think the word “rendering” in the terms “client-side rendering” and “server-side rendering” is misleading, because we already use the word “rendering” to mean two other, much lower-level concepts that are involved in displaying web content on a monitor. First, there’s the kind of “rendering” that occurs with the prerender speculative loading type, in the up-and-coming Speculation Rules API (and in the now-defunct prerender keyword for the rel attribute of the <link> HTML element). Second, we use the word “rendering” to refer to the entirety of the process for getting pixels on the screen, up to and including the actual scanout of a frame.

Aside from the lack of technical precision, the term “client-side rendering” also makes the process of using JavaScript to dynamically construct the DOM much more impressive-sounding. Is it a wooshy-wooshy computer-y thing, where your code does something complicated with the hardware that no mere mortal could understand? No! Constructing the DOM with JavaScript is like building a little sculpture out of Play-Doh. The concepts involved are simple, the thing you create is kind of lumpy and will sort-of look right even if you make a few mistakes, and young non-computer-scientists pick it up as a skill all the time. HTML + CSS -> JavaScript -> React bootcamp sequences are, for a lot of people, literally their first entrypoint into the tech industry, and they can be taken by people with no prior programming experience.

Actual rendering is a very complicated process. I don’t think this other thing we’ve decided to call “rendering” deserves the name.

↩

If I had wanted to make a non-static site, the tool I would have turned to would be Leptos. It’s one of the most exciting projects in web development today. I intend to write at least one blog post about it in the future.

↩

Brotli compression at level 11 achieves the lowest compression ratios on HTML of any compression algorithm. It’s better than gzip and even outperforms more modern compression algorithms like Zstandard. The main benefit Zstandard offers over Brotli is its compression speed at very high compression levels, not its decompression speed or compression ratios. I would like to do a more comprehensive review of this topic in the future—expect a blog post at some point.

↩

If you’re using HTTP/3 and have optimized the heck out of your CSS, I would ballpark this method as taking around 1.5 times the time to load the first page of your website as an architecture that places all CSS inside your .html files. In exchange, you get significant bandwidth savings across subsequent navigations and larger pages will still load in a single round trip. However, literally the only time I’ve ever seen someone actually benchmark the comparative loading times of these two architectures, they found that subsequent page loads were actually faster when all the site’s CSS was placed inside its .html files. They then handwaved these results away as if they weren’t deeply confusing and worthy of additional investigation to find out what was going on. So take my “ballpark estimates,” which run counter to the only experimental evidence I could find, with extreme skepticism.

↩

This blog post isn’t intended to be a technical analysis of single-page apps (SPAs), but they are the kind of site most responsible for breaking conventional browser features and I’d very much like to write a technical analysis of them at some point. The SPA is a relic of an earlier era, and I hope it disappears from the internet entirely within the next decade.

Anecdotally, sites consisting of a bundle of JavaScript are far more bug-prone than static sites. There are absolutely ways to make a SPA that doesn’t break basic browser features, yet they so rarely get used. And sure, some SPAs are better than others, but it’s very rare that my experience with them has been good.

↩

In the earliest days of the internet, all sites were static sites. So when I say “historically” here, I mean “in recent years with modern-day tools.”

↩

That isn’t to say it’s been perfect. At the time of writing, the development server is finicky on Windows. It sometimes crashes, and other times resources on the page fail to load. Even restarting the dev server doesn’t always fix these problems—you sometimes have to kill the dev server, open the development page in a new browser tab, and then restart the server again. All of the other benefits of Zine more than make up for these frustrations, and I’ve found the development process fun despite them. Nevertheless, Zine definitely feels like alpha software. It feels like alpha software because it is: the docs openly inform the user about Zine’s alpha status.

↩

Though I would prefer it if Zine’s quickstart page explained what a terminal and a CLI were, like Eleventy’s quickstart page does. It’s a small thing, but it goes a long way toward preventing non-technical users from bouncing off the tool.

↩