Rust static site generators have split into recognizable jobs. One wants to build a conventional website from a single binary. Another turns Markdown into a book. A third treats connected notes as the content model. Picking by programming language alone misses the useful distinction.
Rust (a systems programming language built around memory safety and compiled performance) can produce self-contained command-line tools that are convenient to copy into a build environment. A static site generator (a program that creates finished HTML before the reader requests a page) can therefore feel pleasantly small at deployment time. The public server needs the output, not the generator or a database.
Nine tools appear in the current list: Zola, mdBook, Zensical, Marmite, Cobalt, Typsite, Kodama, Dodeca, and Adduce. I would not put them into one ranking. Their stated purposes point at different projects, so the useful question is which one matches the shape of the content.
Start with the output, not the language
A blog, a software manual, and a linked-note collection can all become static HTML. They do not need the same authoring workflow. The first selection step is to describe the finished site without naming a generator.
Write down who edits the content, what source format they use, how pages relate to each other, and what the build must create. Markdown (a plain-text formatting syntax) is common, but it does not settle questions about navigation, tags, feeds, redirects, search indexes, or reusable page data.
A practical project brief should answer at least five points:
- Primary reader. Name the person using the published site and the task they need to finish.
- Primary editor. Identify whether authors are developers, technical writers, or occasional contributors.
- Content structure. Separate chronological posts, ordered chapters, reference pages, and linked notes.
- Build environment. Decide whether generation runs on a laptop, a hosted workflow, or both.
- Required output. List feeds, sitemaps, redirects, search data, and downloadable formats.
- Ownership horizon. Confirm who can rebuild the site two years from now.
That last point keeps a fun weekend tool from becoming an undocumented production dependency.
Nine tools mapped to nine project shapes
The source descriptions are concise, so I treat them as routing signals rather than complete reviews. Repository activity, documentation, operating-system support, and migration behavior still need checking before adoption.
- Zola for a complete website. Zola is a single binary with its main features built in and uses Tera, a template language for generating text from structured data.
- mdBook for ordered documentation. mdBook is both a command-line tool and a Rust crate (a reusable Rust package) for turning Markdown into books.
- Zensical for a general site. Its description places it in the modern static-generator category without narrowing the content type.
- Marmite for a blog. The stated focus is blog generation, which makes it the obvious candidate when posts are the core unit.
- Cobalt for a conventional build. It is described as versatile while remaining simple to use, a combination worth testing against a small mixed-content site.
- Typsite for Typst sources. Typst is a markup and typesetting system, and Typsite turns those source files into complete static websites.
- Kodama for connected notes. It targets Zettelkasten-style collections (a note method built around small records connected by links).
- Dodeca for incremental generation. A fully incremental generator aims to rebuild only the output affected by a change instead of regenerating everything.
- Adduce for a general custom site. Its description emphasizes versatility and speed, so it belongs in the broad-site comparison until a specific requirement narrows the field.
This map immediately removes several candidates from most projects. A manual with ordered chapters should test mdBook before a blog-focused tool. A Typst-centered publishing workflow should inspect Typsite before moving content into another syntax. A linked research notebook should start with Kodama instead of forcing backlinks into a conventional blog model.
Zola is the broad candidate I would test first for an ordinary site because the single-binary description reduces setup variables. That is not a verdict about quality. It is a way to begin the trial with fewer moving parts.
Run one small build before reading comparisons
Feature tables encourage imaginary requirements. A controlled build shows whether the tool fits the work you already have. I would give the two strongest candidates ninety minutes each and use the same source package.
The package should include a home page, four content pages, one image, one code sample, and two levels of navigation. Add one draft page that must not publish. Include a changed URL so you can test a redirect, even if the generator requires a manual file for it.
Measure the result with a short scorecard:
- First build. Record the minutes from download to working local output.
- Second build. Change one paragraph and measure how long the rebuild takes.
- Template edit. Add a footer link without touching content files.
- Broken input. Remove required metadata and judge the error message.
- Clean machine. Reproduce the build in a fresh directory or disposable environment.
- Final files. Inspect the generated HTML, links, images, and paths.
A generator that wins on an empty demo can lose on the second build because the content model fights the project. That is why I would include navigation, drafts, and one redirect. Those ordinary details expose whether maintenance will stay simple.
Build speed needs context too. Dodeca’s incremental design may matter for a large site where a full rebuild interrupts writing. On a twenty-page site that builds in a few seconds, incremental generation has little practical value. Measure before treating architecture as a requirement.
Match the specialist tools first
mdBook, Typsite, and Kodama state the clearest content models. I would evaluate them before the general-purpose group when the project matches their focus.
Documentation organized as chapters has different navigation needs from a chronological blog. mdBook begins from that distinction and accepts Markdown, so it can reduce the amount of custom structure a documentation team must invent. Confirm how it handles the specific needs in your manual, especially versioned docs, redirects, and nonchapter reference pages.
Typst users already made a source-format decision. Typsite offers a direct path from Typst files to a website, avoiding a separate conversion into Markdown. The test should focus on web output, not only whether the source compiles. Check responsive layout, links, code samples, images, and accessibility (whether people with disabilities can perceive and operate the result).
Connected-note projects should inspect Kodama’s Zettelkasten focus. Backlinks, note identifiers, and relationship views can be central to that work. A conventional generator can imitate them through templates and metadata, but every custom layer becomes code the owner must carry.
Marmite has the similarly clear blog signal. If the project is mostly posts with dates, feeds, and an archive, start there and compare against one broad tool. Do not make a simple blog prove that it deserves a documentation framework.
What I would verify before committing
A generator can have the correct concept and still be a poor operational choice. The short source list does not establish maintenance health, so adoption needs a current repository check.
Look at recent releases, open issues, documentation changes, and whether a clean build works on the operating systems your team uses. Check the license before integrating the tool into a commercial build. Search for an export path that leaves content in understandable files rather than trapping important data in generator-specific structures.
I would also test failure recovery. Delete the output directory and rebuild it. Remove the local cache. Move the project path. Run the build without internet access after dependencies are installed. Those actions reveal hidden assumptions that a normal successful build may never show.
Teams using hosted automation should pin a known version. A pin (a fixed version declaration rather than an automatically changing dependency) makes the build reproducible and gives the team control over upgrades. Record the update procedure beside the build command so the version does not remain frozen by accident.
Trade-offs
Rust-based generators can simplify deployment because the public result is static files and the generator may arrive as one compiled executable. The build side still has costs. Templates, extensions, and version changes need maintenance. A small community can mean fewer examples when an unusual requirement appears.
Specialization saves configuration and narrows future choices. mdBook can make a book-shaped manual straightforward, but a later demand for a news section may require extra work. Kodama can fit linked notes, while a conventional marketing page may sit awkwardly beside them. Typsite preserves Typst sources, but editors unfamiliar with Typst face a learning cost.
Migration time is concrete. I would reserve ninety minutes for each candidate trial, half a day to migrate a representative set of content, and another half day to document and reproduce the build. A project that cannot justify roughly one working day of evaluation should use the tool the team already knows.
General tools carry their own cost. Zola, Zensical, Cobalt, and Adduce can cover broader site shapes, but broader capability can mean more decisions about templates and structure. The freedom is useful only when the project needs it.
Bottom line
Match the specialized options first: mdBook for a book-shaped manual, Typsite for Typst publishing, Kodama for linked notes, and Marmite for a blog. Test Zola first for a conventional mixed-content site, then compare Zensical, Cobalt, Dodeca, or Adduce only when a stated requirement gives them a reason to be in the trial.
If you only do one thing, build the same six-page sample with two candidates before migrating real content. Ninety minutes of direct use will expose more than an afternoon of rankings, and the losing tool can disappear without taking your site with it.