2026.01.06

dear confidante,

when i started lostlamb one of its little rules was that it wouldn't host a blog — too intimate, too trite, too something — but i'm missing the space. i reach for it instinctively; a phantom limb. oh well.

the lostlamb ssg is now operational. initially i didn't want to use one, but as this site grows, a proper ssg makes things much easier.

i haven't liked any static site generator i've tried to use before... i value freedom with the html i write, i value ease of customizing structure/styling for each page, i don't like being exclusively bound to templates. and i absolutely do not want to write a markdown façade over html instead of writing the html itself. i like html, fortunately.

i've understood my desires with an ssg to be: (1) to limit writing repetitive html, (2) by storing metadata about a page, (3) without compromising writing the important html. maybe discussing lostlamb's ssg will guide like-minded webmasters...

here's what i'm looking at as i write this:


<template>letter</template>
<date>2026.01.06</date>
<body>

<p>when i started <i>lostlamb</i> one of its little rules was that it wouldn't host a blog — too intimate, too trite, too something — but i'm missing the space. i reach for it instinctively; a phantom limb. oh well.</p>
<figure>
	<img src="to_owned.png">
</figure>
<p>the <i>lostlamb</i> <abbr title="static site generator">ssg</abbr> is now operational. initially i didn't want to use one, but as this site grows, a proper ssg makes things much easier.</p>
<aside>
	<p>i originally used a small program to keep reused parts of a page up-to-date, but i still had to edit marker comments whenever i wanted to update the page layout.</p>
</aside>
<p>i haven't liked any static site generator i've tried to use before... i value freedom with the html i write, i value ease of customizing structure/styling for each page, i don't like being exclusively bound to templates. and i absolutely do not want to write a markdown façade over html instead of writing the html itself. i <a href="https://html.energy/" rel="external" target="_blank">like html</a>, fortunately.</p>
<p>i've understood my desires with an ssg to be: (1) to limit writing repetitive html, (2) by storing metadata about a page, (3) without compromising writing the important html. maybe discussing <i>lostlamb</i>'s ssg will guide like-minded webmasters...</p>
<p>here's what i'm looking at as i write this:</p>

</body>

this is this post's source file. the ssg converts this into the page you see now.

the format is derived from a previous iteration of a blog in which i stored posts as xml files. (i've shed the xml. no more escaping ampersands and explicitly ending void elements... thank you...)

here's the design model:

a page is a set of properties. the highermost elements each encode a "property" of the page. the properties are passed to a template and the final result is written to file.
- properties are just text. nothing fancy.
- properties are always optional. any properties unrecognized by the template are ignored.
- the template a page uses can be changed with the template property.
templates are functions, not files. this makes them extremely extensible and capable of any kind of data transformation without overhead.
- many ssgs introduce entirely new markup languages for template files and it's just... i understand you're catering, but you're doing too much.
- since templates are functions, reused components are functions too. this provides the same benefits.
the ssg is optional. it reads .src.html files. don't want to use the ssg for a page? just don't write its .src.html file.
- .html and .src.html files are right next to each other. separate src and dst directories for something as simple as this seems a bit much.

i like a system that works around me, rather than the other way round. this is working well so far. it's written in rust; since i picked it up in early december it's quickly become a favorite language of mine.