Podlite Web
a folder of files, and that is the whole site
Point Podlite Web at a directory and get static HTML you can host anywhere. The page you are reading came out of it.
Where does a site keep its settings
Most generators answer with a config file, and then the folder holds two kinds
of thing: the pages, and the file that explains the pages. Podlite Web answers
differently. The settings sit on the root block of index.pod6, in the same
markup as everything else:
= :favicon<./photo.png>
= :url<https://example.org>
= :globalStyles("./page.styles.css")
= :theme<product>
One file kind, one syntax, nothing beside the content explaining the content.
Build it
docker run --rm -v /path/to/content:/app/pub podlite/podlite-web:latest \
bash -lc "mkdir -p /app/built && yarn export ./pub -s 'https://example.org' --preset pubdate"
The result lands in /app/out inside the container. Every .podlite file
becomes a page — the older .pod6 extension is read too — media/ beside
them becomes images, and the output is a folder of static HTML. No database, no
runtime, no build server.
A date decides when a block goes out
Publication is an attribute, not a workflow. A date in the future holds the block back, and it appears on the first build after that date passes.
What makes this more than a scheduler is where the date can sit. On the whole document it publishes a page. On a single paragraph it publishes a note. On a heading it publishes everything down to the next heading of the same level. Three sizes of publication out of one mechanism, and the draft and the published version stay in the same file.
Your own components
A site can ship its own React components. Put a .jsx file beside the content
and reference it by relative path:
=useReact ProductCard from './components/product-card'
=begin React :component<ProductCard>
=end React
No package manifest, and no changes to Podlite Web itself.
Sites built with it
podlite.org — this site
the Raku knowledge base — over ten thousand pages out of one corpus