Why does it matter if they're called posts, pages, or bananas?

Static site generators take input, run it through templates, and produce html output. This seems to be, literally, what you want to do. Maybe try and implement what you want and you'll see they can do it.

I use Hugo to generate some static pages that sit inside a dynamic website. It's just Go templating, which is not too hard to learn. You can create individual pages that pull in multiple templates if you want. You can switch off RSS, change naming from posts to bananas, etc. Very few preconceived regulations.

Most of the static generators are used for blogs, that's probably why most examples they give are around blog posts. It doesn't mean the name 'post' actually means anything special.

My favorite static site generator is Org mode[1] for Emacs. Org files are written using a feature-rich lightweight markup language[2] that is much more powerful than Markdown (e.g., plain text spreadsheets). Org files can be exported to HTML[3].

The reason I prefer Org for static site generation is not because I already use Emacs. I actually started using Emacs about 20 years ago specifically to use Org mode.

[1] https://orgmode.org/

[2] https://orgmode.org/features.html

[3] https://orgmode.org/manual/HTML-Export.html

I think this is more a question of how you want to create and store your content and templates, like whether they exist as a bunch of Markdown files, database entries, a third-party API, etc. They're typically made to work in some sort of toolchain or ecosystem.

For example, if you're working in the React world, Next.js can actually output static HTML pages that work fine without JS... just use the pages router and a static export (https://nextjs.org/docs/pages/guides/static-exports). That still lets you use all the power of JS and expressiveness of React components, minus the interactivity, of course (if you don't want JS). But you could still pass in components and such. It's a bit like writing serverside includes in the PHP or Perl days. The benefit of using Next is its incredible popularity; probably whatever question you have, someone else has already asked and ten people have answered it. The downsides are its complexity and its frequent changes; answers from just a year or two ago are probably irrelevant to the current version, and there is a steep learning curve at first. But in SSG mode with the pages router, it's pretty straightforward, and the filesystem-based routing makes it very clear what the final directory structure would be.

For Markdown there's https://docusaurus.io/ and https://github.com/rust-lang/mdBook

Eleventy is another option for various templating languages: https://www.11ty.dev/

See also these lists:

https://jamstack.org/generators/

https://github.com/myles/awesome-static-generators

Try Hugo[1]. In depends on a template[2] you choose whether Hugo will generate a landing page, a website, a blog, etc.

[1] https://gohugo.io

[2] https://themes.gohugo.io

I recently used Astro [0] to make TrumpOrderTracker.com [1] and it was a great experience. It can definitely handle much more than just blogs.

[0] https://astro.build/

[1] https://trumpordertracker.com/

Agree on Astro. It's great for documentation/blog sites but quite unopinionated so can easily be used for varied site structures. Unlike certain other frameworks, there is no magic in Astro. It generates very straightforward HTML.

There is actually a fair bit of magic in Astro, like its proprietary use of its own frontmatter-like section, magic MDX parsing (but only in some parts of certain files), the way it handles componentization and imports, etc. Especially if you want to use it with islands for React/Vue/Svelte, or integrate web components. "Collections" are also magic, especially when used with the separate Gatsby-like documentation engine (Starlight: https://astro.build/themes/details/starlight/).

It works great for simpler sites and blogs. But for more complex setups, the magic often gets in the way of doing simple things in a way that more mature frameworks like Next figured out through trial and error and have documented, either officially or in user reports. Astro doesn't quite have the reach yet and the docs are minimal, so when you stumble into a situation, it's really hard to find help.

The lack of proper IDE debugging also makes it really really hard to step through errors on the server side.

Don't get me wrong, I'm very happy that Astro is an option, especially for simpler sites where Next etc. are overkill. But it's still a framework with a fair bit of magic, and for any moderately complex site, you'll likely eventually hit a use case where the magic gets in the way and there's no clear way to solve it.

You are correct about compile time magic. Runtime magic is minimal (the code runs when and where you think it does). And yes, Starlight is a foot gun IMO. It takes a framework that is designed to be easily learned and makes it even easier to use, but at the expense of the learning.

Mkdocs