I used to use Hugo but now I’m writing my own static site generator in Zig. Yes, it’s an elaborate way to procrastinate actually writing blog posts. But I’m having fun. It generates my whole blog in 3ms, and when I tested with 10k posts it was about 125 µs per post (nothing shows up in the profiler except syscalls). So far I’ve built a templating system and Markdown renderer, next will be code highlighting and converting TeX to MathML.
whoa, you did a whole markdown renderer from scratch, complete with tests. That’s a lot more dedication than I have, I would definitely read about your challenges on creating this.
Hugo unfortunately doesn’t have a good tutorial available, but it’s pretty good for the task of just cranking out a simple static site once you learn it. It comes with a built in image resizer, so you don’t need imgproxy as long as you keep your images in the repo.
The big gotcha with Hugo is that they don’t really follow semantic versioning, so make sure you keep a note of which version you built your site with! After getting burned once or twice, I started checking the binary into my website repo.
Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
I think this highlights the conflict between the stated primary goal of semver (reducing/ending “dependency hell”) and how end users actually use semver packages (to enable quicker/easier updating to minor and patch releases).
I’m not a Hugo maintainer and wouldn’t presume to tell them how to manage their project’s versions, but they seem conscientious about highlighting breaking changes in release notes and not committing semver’s cardinal sin (releasing a breaking change in a post 1.x.x non-major version). This is far better than packages that claim to use semver but refuse to create major versions for breaking changes because of hauptversionsnummernerhöhungsangst.
I use Netlify, which lets you pin the version as a config variable. In general, Hugo has binaries on GitHub, and you can just download those as eg a build step in Docker.
Yes, I noticed the image resizing feature way too late, it’s a great feature to have builtin! I agree, once you learn it, it’s a good, fast, always working builder. I think I just like simpler file.html is /file structures without pre-assumed folders/files needed.
This is a fun article! There’s a lot that goes into “simple” sites. Also TIL about Plim, that’s great. I love “write HTML, but simpler” and so it’s great to see a python option.
Also, I noticed the author and I have the same circuit board background on our homepages:
Shameless plug for my own shell based static site generator mkws.sh as a lot you know. Might not be the fastest to generate, but really fast and simple at development and deployment.
My static site is built using ikiwiki, a static site generator so old it predates that term. It’s (by modern standards) fairly awkward in many ways but I’ve paid that technical debt already, and extremely flexible in ways that none of the newer SSGs seem to be, so I’ve failed to escape from it.
Could be because they did not finish resizing in time. imgproxy resizes and converts images on the fly, which then get cached on the CDN somewhere near your location. Maybe a refresh fixes it?
I used to use Hugo but now I’m writing my own static site generator in Zig. Yes, it’s an elaborate way to procrastinate actually writing blog posts. But I’m having fun. It generates my whole blog in 3ms, and when I tested with 10k posts it was about 125 µs per post (nothing shows up in the profiler except syscalls). So far I’ve built a templating system and Markdown renderer, next will be code highlighting and converting TeX to MathML.
whoa, you did a whole markdown renderer from scratch, complete with tests. That’s a lot more dedication than I have, I would definitely read about your challenges on creating this.
That’s nice to know, maybe I’ll write about that as my first new post once I finally finish it!
Hugo unfortunately doesn’t have a good tutorial available, but it’s pretty good for the task of just cranking out a simple static site once you learn it. It comes with a built in image resizer, so you don’t need imgproxy as long as you keep your images in the repo.
The big gotcha with Hugo is that they don’t really follow semantic versioning, so make sure you keep a note of which version you built your site with! After getting burned once or twice, I started checking the binary into my website repo.
Since Hugo has never released a 1.x.x version, aren’t they technically following semvar? https://semver.org/#spec-item-4 :
I think this highlights the conflict between the stated primary goal of semver (reducing/ending “dependency hell”) and how end users actually use semver packages (to enable quicker/easier updating to minor and patch releases).
I’m not a Hugo maintainer and wouldn’t presume to tell them how to manage their project’s versions, but they seem conscientious about highlighting breaking changes in release notes and not committing semver’s cardinal sin (releasing a breaking change in a post 1.x.x non-major version). This is far better than packages that claim to use semver but refuse to create major versions for breaking changes because of hauptversionsnummernerhöhungsangst.
I use Netlify, which lets you pin the version as a config variable. In general, Hugo has binaries on GitHub, and you can just download those as eg a build step in Docker.
Yes, I noticed the image resizing feature way too late, it’s a great feature to have builtin! I agree, once you learn it, it’s a good, fast, always working builder. I think I just like simpler file.html is /file structures without pre-assumed folders/files needed.
This is a fun article! There’s a lot that goes into “simple” sites. Also TIL about Plim, that’s great. I love “write HTML, but simpler” and so it’s great to see a python option.
Also, I noticed the author and I have the same circuit board background on our homepages:
Small world 😁
Wow - great article. You put a lot of work in by showing all the different languages and options (like the haml, vs slim, etc)
Also, the site is super clean - good typography, use of color, etc. everything looks balanced
Thank you, makes me happy to hear that!
Shameless plug for my own shell based static site generator mkws.sh as a lot you know. Might not be the fastest to generate, but really fast and simple at development and deployment.
Saved this to read more into it later. I wanted to say that I like the theme/color-scheme though. I want to tweak my site’s theme a bit more now…
Hey thanks! For my notes website, I ported part of the style as a single
stylusfile, in case you want a starting point: https://notes.alinpanaitiu.com/common.stylIt’s mostly large because of the
.chromasyntax highlighting classes and the color variables at the top. The core is easily editable.Ah interesting. Not familiar with “stylus” files. Lots to learn!
My static site is built using ikiwiki, a static site generator so old it predates that term. It’s (by modern standards) fairly awkward in many ways but I’ve paid that technical debt already, and extremely flexible in ways that none of the newer SSGs seem to be, so I’ve failed to escape from it.
Some images (and all of the images on your brother’s website) show as broken (blue placeholder rectangle) on my iPhone.
Could be because they did not finish resizing in time.
imgproxyresizes and converts images on the fly, which then get cached on the CDN somewhere near your location. Maybe a refresh fixes it?