Sukr: A minimal static site compiler in Rust with zero-JS output

very nice. I wrote my own ssg for my blog, which works in a similar way. I tried to open source it as a library that encouraged you to add your own spice rather than just use some cli but after it didn’t really catch on I quit maintaining it and moved the code back over.

mine never supported latex or mermaid, which might both be useful features worth copying…

Sounds like something I have half-built and not yet published because the last few months have been messy. I'll have to see if it's possible to deduplicate any of that effort.

Granted, a few things do differ:

1. Your chart seems to indicate you see having a single binary as superior to minimizing the number of only-relevant-to-certain-sites dependencies in core instead of in sandboxed WebAssembly plugins, while I'm writing this as an alternative to picking Pelican specifically because I want a plugin API to do extremely site-specific things with.
2. Mine's currently a single-page generator because it originated as a minimal-hassle way to render my Christmas wishlist with some extensions to what a tool like cmark-gfm would offer like <booklinks isbn="..."></booklinks> and I have more pressing changes to make first.
3. Breaking out the hard-coded template is still a work in progress, since, at the moment, I mainly use it where other people would use Google Docs or LibreOffice.
4. I spent a lot of time building a library of shortcodes for things like game controller button icons and now I'm about to evaluate switching pulldown-cmark out for Comrak since my shortcode hack for pulldown-cmark doesn't play nice with turning on the definition list extension pulldown-cmark recently gained, while Comrak's parser seems to natively support both in the manner I need. (Main hold-up: Finishing converting my syntax reference document from a de facto regression suite into something machine-checked.)
5. I'm still on syntect instead of tree-sitter for syntax highlighting, since I had syntect integrated long before Arborium came on the scene, splitting codeblock highlighting out into plugins was literally the most recent thing I did, and I haven't had time to whip up a plugin for Arborium yet.
6. I do my MathML via latex2mathml, which should be much more lightweight than KaTeX and seems to cover a much broader range of syntax constructs than I ever needed while going for my degree.
7. The diagramming I support so far is ASCII/Unicode art to SVG via svgbob and GraphViz dot via layout-rs with plans to add plotters and explore the viability of implementing something like matplotlib's xkcd-style graph renderer for it (because they're important. See also). (Also, thank you for drawing my attention to the "Rust bindings for mermaid" in mermaid-rs's README being misleading. I still thought it would emit JavaScript... though, given that it's literally bindings to run the JavaScript version in a headless chrome instance and I'm not up to porting an entire JavaScript project like mermaid to Rust, I think I'll continue to evaluate options such as Emscripten-ing tools like mscgen.)
8. There's a touch of JavaScript in mine because, last I checked, Firefox support wasn't yet there for pure-CSS Scrollspy.

Overall, I think the three big differences are:

1. Mine began as a single-page renderer and I've mostly been adding features which are immediately useful to that case instead of preparing for multi-page use.
2. Mine began as a sloppy rush-job and I've been prioritizing using the move to plugins as an opportunity to clean it up. (i.e. splitting out all the extensions like syntect and svgbob into WebAssembly plugins and iterating on a minimal-trust plugin API along the way.)
3. You seem more willing to accept much heavier dependencies than I do for similar roles (eg. KaTeX vs. latex2mathml, mermaid-rs vs. stuff like layout-rs and/or svgbob-rs).

At the moment, I'm a little blocked on how bad wasmtime and wasm-bindgen are at documenting how to import shared APIs like percent_escape and html_escape into WebAssembly worlds and have a .wasm file implement one or more mutually independent worlds for things like CodeblockRendererPlugin and TagRendererPlugin without just taking out the macro_rules sledgehammer and duplicating more and more code under disjoint namespaces until it stops complaining. (At the moment, each plugin vendors its own copy of crates like html-escape.)

I do eventually plan to use mine for my blog... though one of the hold-ups is hunkering down, setting up a local instance of my existing WordPress in a VM, and spidering it to get a complete list of all the URLs I'm ideologically opposed to 404ing so I can migrate them over.

This is really cool.

I built my own SSG (for my website) as well called Alteza: https://github.com/arjun-menon/alteza

I built a tempting language for it as well called pypage: https://github.com/arjun-menon/pypage

I’d love to have a similar tree-sitter based highlighting support as well.

I’m wondering if I can use your highlighter, and just change the syntax / grammar definition to match mine. Is it a piece / module of sukr that’s reasonably easily separable?

As a user of both hugo and zola (hopefully soon to migrate to zola-only, but currently I've got one static site with each), looking at my configs:

1. I can definitively confirm that zola does not require any js by default.

2. The theme I'm using for my hugo site uses a little bit of javascript for syntax highlighting. I don't see any other place where hugo would pull that in, if I hadn't chosen that theme.

I got tired of hugo updates breaking my stuff so I wrote my own ssg. It was honestly a breeze to assemble with go, goldmark and a-h/templ.