FWIW, just a couple of weeks ago we started doing that for a new sqlite subproject: https://sqlite.org/wasm
With the exception of one page, all of them are markdown, rendered on demand by the Fossil SCM. The one exception is an HTML file, which we need in order to host a small JS application.
When you say rendered on demand, you mean by the client, as in a page request? Why not just rerender to HTML on developer change? Genuinely curious why rendering on demand is preferred in this case.
> Why not just rerender to HTML on developer change?
Because that's not how the Fossil SCM renders content. It has a cache, but only for certain high-CPU data like generation of zip files of the source tree. Caching markdown docs wouldn't work in all cases, anyway: when you link to a ticket, for example, it gets rendered differently depending on whether it's opened or closed. Thus the renderer has to know the current status of any fossil-internal constructs a doc links to. Of course, we could say "just update the cache of all docs which link to a ticket every time the ticket is updated," but That Way Lies Madness. In an Enterprise-level system that would possibly be worth doing. For the Fossil SCM it's overkill.
Though re-rendering on every page hit _sounds_ bad, we've been doing it in the Fossil SCM since it went into being and it has never caused us any undue performance issues. Every doc you see on <https://fossil-scm.org/home>, as opposed to the non-doc URIs, is served directly from the SCM db and all (or very close to all) of it is either markdown or Fossil's older/original wiki format, both rendered on demand. CPU load is minimal and rendering is "fast enough" for everything we've ever done with it.
With the exception of one page, all of them are markdown, rendered on demand by the Fossil SCM. The one exception is an HTML file, which we need in order to host a small JS application.