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.
