I just released v0.1.0 of hinoki, my static site generator :)
The README.md should explain usage, and you can also see how I ported my blog to it here.
This project started because I’m not entirely happy with Zola, which does not support customizing page paths much (e.g. /year/month/day/title/index.html style paths) and made some other design decisions that I wanted to explore alternatives to.
You can download the binary from GitHub releases, or cargo install it from git.
Any feedback is appreciated, here or in the GitHub issues!
I’ll try to fit in sampling it at some point in the near future as a candidate for building on.
I just decided to finally double down and do the work to switch away from WordPress to GitHub Pages and:
- Jekyll is still hell to get running locally for testing without erroring out during the install
- Pelican seems like it’d be more trouble than it’s worth to get what I want
- I insist that no links be broken in the switchover (Doing this to my standards was a big part of what I wound up procrastinating, since I basically need to install WordPress locally and then write something which spiders the entire site and verifies that each path is also present in the new site and the page’s contents are identical when run through a filter to cut away the site template and normalize any irrelevant rendering differences.)
- I already have a
pulldown-cmark-based CLI that I wrote a couple of years ago to render single documents and it’d be nice to retrofit it (or at least its features) onto something Rust-based for my blog. (Hell, just a couple of days ago, after implementing support for shortcodes, I got carried away implementing a complete set of shortcodes for rendering depictions of gamepad buttons like:btn-l-snes:within passages of text. Bit of a shame, though, that I’d have to either patchpulldown-cmarkor maintain the smart punctuation and strikethrough extensions externally, if I want to hook in shortcodes early enough in the pipeline to be able to implement Compose key-inspired ones like:'e:/:e':→ é or:~n:/:n~:→ ñ without breaking things.) - Since my plans for comments are, to the best of my knowledge, unique, I need something in a language I’m willing to hack on and potentially maintain my own fork of. (Jekyll would have been achieved via a preprocessor.)
- I want something where I’m at least willing to port the internal broken link detection from one of my old bespoke Python static site generators, which means either Python or Rust. (Ideally, I’ll also re-create the support for performing HTML and CSS validation on the generated output.)
- Given how many things I either have in my existing single-page renderer (eg. automatic ToC generation with a bespoke scrollspy implementation, Syntect integration,
```svgbobfenced code blocks which produce rendered diagrams,<price></price>tags which provide currency-conversion estimation tooltips with the exchange rate defined in a central location, etc.) or have plans for (eg. plotters-generated charts with some kind contributed extension equivalent to matplotlib’s xkcd mode because it’s important, Wikipedia-style infobox sidebars, etc.), I want to experiment with a WebAssembly-based plugin API so I’m not throwing the kitchen sink in.
Hey, only saw this now! Have you investigated some of the options already now?
Re. Jekyll, I have the same experience which is what got me to try Zola. I find it rather nice to use at least when you’re okay with its limitations – which hasn’t always been the case… missing flexibility for output paths has been an annoyance. What really led me to make my own Rust SSG instead of forking Zola is that I found Zola to be quite hard to hack on, and Tera (its templating lang) to be a little buggy / much less elegant than minijinja API-wise.
Re. link checking, have you seen lychee? When I found out about it, the priority of building my own link checker in my SSG (that was only an idea at that point, I think) basically dropped to zero :D
the
Have you investigated some of the options already now?
A bunch of other things came up, forcing me to put the project on the back burner.
(eg. Most recently (about a week ago), I had my 6-month-old boot drive go bad and it took me several days to rush-order a new NVMe drive, learn ZFSBootMenu, restore my backups, and redesign my backup strategy so that, when the original comes back from RMA, if the ZFS mirroring and snapshotting and the trick to mirror the EFI system partition isn’t enough to ensure high availability, a full, bootable backup of the NVMe pool’s contents can be restored in 2 hours or less with the sequential read performance of my first tier of backup being the bottleneck.)
missing flexibility for output paths has been an annoyance.
Hmm. We’ll see if I wind up using it. Avoiding deadlinks has been non-negotiable to the point where replicating my WordPress blog on a local httpd, spidering it, and logging the URLs I need to preserve has been one of the big hold-ups.
is that I found Zola to be quite hard to hack on
Hmm. Potentially a reason I’ll wind up making my own, given that I’ve written SSGs in Python before (eg. https://vffa.ficfan.org/ is on a homebrew Python SSG) and I’ve already got a single-page
pulldown-cmarkfrontend I’ve gone way overboard on the features for and a basic task-specific Rust SSG for my mother’s art website that I can merge with it and generalize.EDIT: Here’s a screenshot of what I mean by saying I’ve gone way overboard.
and Tera (its templating lang) to be a little buggy / much less elegant than minijinja API-wise.
Hmm. Noted. I think i’m using Tera for my mother’s SSG.
Re. link checking, have you seen lychee? When I found out about it, the priority of building my own link checker in my SSG (that was only an idea at that point, I think) basically dropped to zero :D
You accidentally re-used the link to the Zola issue tracker there. I have not yet checked out lychee and I’m getting a docs.rs error when clicking the examples link, so all I can say is that it’ll depend on how amenable it is to checking a site rooted in a
file://URL so I don’t need the overhead and complexity of spinning up an HTTP server to check for broken links.EDIT: Here’s a screenshot of what I mean by saying I’ve gone way overboard.
Wow! Impressive :)
You accidentally re-used the link to the Zola issue tracker there.
Oops, fixed.
it’ll depend on how amenable it is to checking a site rooted in a
file://URL so I don’t need the overhead and complexity of spinning up an HTTP server to check for broken links.Wouldn’t you want your SSG to include a dev-server anyways? Zola has
zola servewhich even does incremental rebuilds, but something less sophisticated should be easy to add to your own (only took me a weekend to add to hinoki including rebuilds, though mostly starting the build from scratch on changes).Wouldn’t you want your SSG to include a dev-server anyways? Zola has zola serve which even does incremental rebuilds, but something less sophisticated should be easy to add to your own (only took me a weekend to add to hinoki including rebuilds, though mostly starting the build from scratch on changes).
I don’t want the overhead of looping through an HTTP client and server implementation in places it doesn’t need to. I design my tooling based on a test target roughly comparable to the Raspberry Pi 4, performance-wise.
