Building Sigil's Static Site Generator with the Standard Library
Sigil's website is generated by a static site generator written in Sigil. That decision was partly practical, but it was also a language test: if the standard library is supposed to be the default way to build real programs, then it should be able to support the language's own documentation site.
Why This Was Worth Doing
Static site generators are a good stress case for a small language runtime. They need file access, path handling, markdown parsing, HTML generation, sorting, frontmatter parsing, and a small HTTP server for local development.
In a typical JavaScript workflow, that often means choosing among several competing packages for each of those jobs. That approach is serviceable for general application development, but it is a poor fit for Sigil's goals. The language is trying to reduce choice at the point where everyday programs are written, especially for agent-driven workflows.
The site generator gave us a way to test a simpler claim: can Sigil ship enough standard functionality that a normal repo tool can be written without reaching for npm packages at every step?
The Design
The answer was to lean on a larger standard library surface rather than a package ecosystem.
The site uses:
§markdownfor markdown parsing§httpServerfor local serving§fileand§pathfor filesystem work§string,§list, and§timefor the remaining
transformation pipeline
That produces a simpler dependency story:
- the compiler and stdlib ship together
- rooted module references are canonical
- there is no library selection problem for the same task
The Markdown Case
The markdown parser is the most interesting part of the example because it is implemented in Sigil rather than wrapped from an external package.
That was a deliberate choice. A thin FFI wrapper around an existing markdown library would have been much less work, but it would not have exercised the language in the same way. Implementing the parser in Sigil forced the language to support a real piece of structured text processing with recursive descent, state tracking, and string-heavy transformation.
It also produced a canonical implementation inside the repo instead of pushing the question outward to "which markdown package should this project use?"
The HTTP Case
The local development server took a different path. Here the standard library wraps the host runtime instead of reimplementing networking from scratch.
That tradeoff made sense because the important part was not re-deriving Node's HTTP stack in Sigil. The important part was presenting one typed, stable, and small interface for Sigil programs that need to serve content.
In other words, Sigil's standard library is not trying to avoid all FFI. It is trying to provide one canonical surface above the runtime where that surface is useful.
What This Demonstrated
Building the site generator did not prove that Sigil should never use external packages. It did prove something narrower and more valuable: a language can ship enough batteries that ordinary repo tooling does not have to start with a dependency hunt.
That matters for Sigil because canonical rooted references and standard patterns are part of the language design, not just a packaging preference. The site generator is useful in its own right, but it also serves as evidence that Sigil's standard library is large enough to support real project infrastructure.