Scheme is not where most people start when they need a website. That is exactly why these four static site generators are interesting. They treat publishing as a programming problem, not as a dashboard full of settings, and they make the most sense when the person maintaining the site already enjoys Scheme.
A static site generator (a program that turns source files and templates into finished HTML before visitors arrive) removes the database and server-side rendering from the public request path. The result can be copied to basic hosting, served from object storage, or kept in a Git repository. Scheme adds a different idea: the site itself can become a program made from small functions and structured data.
That is useful for the right project and unnecessary for most others. I would not choose one of these tools because Scheme sounds clever. I would choose it when the language makes the publishing rules easier to express and maintain.
Why Scheme changes the shape of the project
Scheme is a small member of the Lisp language family. Lisp languages commonly represent code with nested lists, often called S-expressions (a parenthesized notation where the structure of the program is also data the program can inspect). That design makes Scheme comfortable for building a DSL (domain-specific language, a small language designed for one narrow job), such as describing pages, navigation, or collections of posts.
The appeal is not raw page speed. Any static generator can produce HTML that a web server sends quickly. Scheme earns its place when the rules behind the pages are unusual. A documentation project might generate several indexes from one set of records. A research notebook might connect notes by tags and citations. A small organization might need the same structured information rendered as pages, feeds, and downloadable files.
Using a general programming language for those rules gives you precise control. It also means the maintainer needs to understand real code, not only a theme configuration file. That is the first decision gate.
Before picking a generator, I would write down four facts:
- Content shape. Decide whether the site holds posts, documentation, linked notes, or mixed records.
- Maintainer skill. Confirm that at least one person can read and change Scheme code.
- Output needs. List every required page, feed, index, and asset.
- Hosting limit. Identify whether deployment means copying files or running a build service.
- Handoff plan. Name who can repair the build when the original author leaves.
A project that cannot answer the last question should use a tool with a larger pool of maintainers.
The four tools in plain English
The available list is short, which helps. Each option points toward a different relationship with Scheme rather than pretending to be a universal publishing system.
- Haunt. Treats websites as Scheme programs, making it the clearest fit for someone who wants the site’s logic to live directly in Scheme.
- Hyde. Uses Chicken Scheme, a Scheme implementation that can compile programs to native code, and presents itself as a static site generator.
- sph-web-publish. Targets Guile, the GNU project’s Scheme implementation, which makes it relevant when a project already uses Guile tooling.
- alley-cat. Provides a Chicken Scheme library for generating static websites, so it reads more like a component to build with than a finished publishing product.
That summary is intentionally narrow. A name and one-line description do not establish current maintenance, theme availability, plugin support, or compatibility with a particular operating system. I would check those facts in each project’s documentation and repository before committing content to it.
Haunt has the strongest conceptual pitch of the four: the website is a Scheme program. That can reduce the distance between an idea and its implementation when the maintainer already thinks in functions and data transformations. It can also turn a simple blog into a software project when the maintainer only needed posts and an RSS feed.
Hyde and alley-cat both connect to Chicken Scheme. The choice between them starts with desired abstraction. A generator usually gives you an established build flow. A library gives you parts that you assemble. The library route can fit a custom publishing job, but the team owns more decisions about file discovery, templates, assets, and command-line behavior.
sph-web-publish belongs in the Guile conversation. Existing language choice matters because switching Scheme implementations can change available libraries, package commands, and deployment assumptions. If a team already maintains Guile code, adding another Guile-based tool is easier to justify than introducing Chicken for one website.
A two-hour selection test
I would not compare these tools by reading feature grids. I would give each serious candidate the same small build and stop after two hours. The test should be boring enough to expose workflow friction rather than reward a polished demo.
My sample project would contain five pages, one list of posts, one tag index, a stylesheet, and a feed. It would also include a filename with a space and one broken internal link. Those details reveal more than a screenshot because they force the generator to handle normal maintenance work.
The scorecard would cover:
- Setup time. Measure the minutes from an empty directory to the first local build.
- Content clarity. Check whether a future editor can understand where titles, dates, and body text live.
- Template clarity. Change the page shell without touching each content file.
- Error quality. Break a template on purpose and judge whether the message identifies the problem.
- Incremental work. Edit one page and see how much of the site rebuilds.
- Deployment size. Inspect the files that must reach the host.
Do not award points for features the project will never use. A built-in server, syntax highlighting, or elaborate theme system has no value if the site is a small reference manual with one stylesheet.
I would also open the generated HTML directly in a browser. That catches absolute asset paths, missing links, and assumptions about a development server. Static output should remain understandable after the generator finishes. If the only way to inspect the result is through a special runtime, the project is carrying more machinery than I want from a static build.
When a Scheme generator makes sense
Scheme is a sensible fit for a site maintained by Scheme programmers, a teaching project that uses publishing to exercise the language, or a custom knowledge base where page generation depends on unusual data transformations. Haunt seems like the first candidate for a site-as-program approach. Hyde deserves a look for a Chicken-based generator. sph-web-publish fits a Guile-centered toolchain. alley-cat makes sense when the goal is to assemble a custom generator from a library.
Skip the category when the site belongs to a rotating communications team, when nontechnical editors need a visual workflow, or when the requirements are a home page and twenty ordinary posts. A common generator with broad documentation is easier to hand off, even if its language is less interesting.
Anyone publishing customer-facing material should also separate content ownership from build ownership. Writers need a stable way to edit text. Developers need tests for templates and generated links. Operations staff need a deployment method they can rerun without reconstructing one person’s laptop.
A small Scheme site can satisfy all three groups, but the project has to design that division. The language does not provide it automatically.
Trade-offs
The largest cost is familiarity. A developer who already knows Scheme might produce the first working template in an afternoon. A developer learning Scheme, the generator, its package system, and static publishing at the same time could spend several days before reaching the same point. That learning time is hard to defend for a plain marketing site.
Community size creates another cost. Four listed tools mean fewer obvious escape routes than a category with dozens of actively compared generators. Documentation may be thinner, examples may assume Scheme knowledge, and integrations may require local code. I would budget at least half a day for a migration spike before promising a delivery date.
Control is the upside. A library such as alley-cat can become exactly the publishing component a custom workflow needs. Haunt’s program-first model can keep transformation logic close to the content model. That control pays off only while someone can maintain it.
Hosting remains inexpensive because the public result is static files. Build maintenance is not free. Dependencies need review, generated links need tests, and a new maintainer needs enough documentation to reproduce the output from a clean machine.
Bottom line
Start with Haunt if the phrase “website as a Scheme program” describes what you want. Start with Hyde when Chicken Scheme is already part of the project, choose sph-web-publish for an existing Guile toolchain, and inspect alley-cat when you need a library rather than a finished workflow.
For everyone else, run the two-hour test before moving any real content. If the Scheme version does not make the site’s unusual rules clearer by the end of that test, use a more common generator and spend the saved time on the writing.