6 ms·

Nixtml: Static website and blog generator written in Nix

81 points by todsacerdoti 11mo ago

JoelMcCracken 11mo ago
neat! I've been moving my site over to heavily use emacs/org for the authoring format and nix for the tooling infrastructure. I'll keep this in mind as a possible tool to help; I don't precisely know what I may still need to do that won't be easily doable with emacs.
Y_Y 11mo ago
Cool. After using Nix for a while I got pretty fed up with the (subjective) unintuitiveness of the language†. It wasn't even that I thought it was a bad language, I just couldn't het it to click (and doubly so after the advent of flakes). All the same it seems to me like if you grok it it's a great fit for constructing recipes for building things reliably that are part of huge dependency trees, and so it's natural that it would be a good website generator too. † Luckily others shared this issue, and the result was Guix which solves that problem while introducing its own.
- lillecarl 11mo ago
  It's a pretty special language, lazy evaluation and very basic types. However after spending the time to learn it to an intermediate level I think it's pretty great. Flakes are not great however, they're what happens when you "overdo it", sadly the momentum is behind flakes because some UX/DX improvements came along with them (lockfile in repo). I think the stdenv being built on bash is worse than Nix language. Module system errors can be very hard to troubleshoot because of lazy eval, sadly I can't see a reasonable solution without worse tradeoffs :(
  - Hnus 11mo ago
    The flakes were the main UX/DX improvement for me. Before them I honestly could not do anything. The learning curve was so incredibly steep it almost felt like the people behind Nix were being malicious or intentionally gatekeeping. You finally stumble onto something you can at least partly understand, but then the powers that be throw two last obstacles at you like, First, flakes are "experimental", so you have to enable them. Back then there were like three slightly different CLI commands to do it, and it felt like none worked from like 5 tutorial tabs I had open, putting it `experimental-features =` into flake you are trying to switch to does not work obviously. Then you hit the classic situation where your flake is not committed or staged, so Nix refuses to see it. And instead of telling you that, it prints this abomination of error message "error: path '/nix/store/0ccnxa25whszw7mgbgyzdm4nqc0zwnm8-source/flake.nix' does not exist" (https://determinate.systems/blog/changelog-determinate-nix-331/#untracked-files https://determinate.systems/blog/changelog-determinate-nix-3...) I would not wish learning Nix from zero on my worst enemy, and I say that as someone who uses nix-darwin, devShells, deploy-rs and so on every day. The UX/DX is really bad, but nothing else comes close to its capabilities. Sorry for rant but without flakes I would not make it.
    - entropie 11mo ago
      > your flake is not committed or staged That has nothing to do with flakes. When I add a "module" to my repos its the same. I have to add it the git repos or nix does not "see" it. And yes, its pretty unintuitive.
      - Hnus 11mo ago
        It actually is specific to flakes. Classic nix commands can see untracked files just fine. Flake evaluation behaves differently because of how it decides which "scheme" to use: > If the directory is part of a Git repository, then the input will be treated as a `git+file:` URL, otherwise it will be treated as a `path:` url; This is why untracked or unstaged files disappear when using flakes: https://github.com/NixOS/nix/blob/ec6789f9dafce41011418fe6fcc5215e4b50e1e5/src/nix/flake.md?plain=1#L115 https://github.com/NixOS/nix/blob/ec6789f9dafce41011418fe6fc...
        entropie 11mo ago
        Interesting.
        embedding-shape 11mo ago
        What's more interesting, is how confident your original comment read, but turned out to not be correct at all. Of course it has always been true, but excellent reminder that even humans hallucinate.
        entropie 11mo ago
        I tried to edit my comment but not possible. I could have sworn that I had this issue without using flakes. The start with Nixos was really bumpy; I must have mixed something up.
    - Tt6000 11mo ago
      [dead]
  - nothrabannosir 11mo ago
    I’m convinced when people say they “love flakes” , 95% of them just love fetchTree and lock files. (Which is totally valid btw)
    - Hnus 11mo ago
      Fair, another thing I really like is you can do `nix flake show templates` and try to `nix flake init -t templates#trivial` and be like ahh so thats how its supposed to be done or init `full` and be like ok this flake thing can do a lot of things I didn't know it could do, you can then edit, delete and experiment.
NewJazz 11mo ago
Not to be confused with Nixtamal, the processed corn food. https://en.wikipedia.org/wiki/Nixtamalization https://en.wikipedia.org/wiki/Nixtamalization
- hardwaregeek 11mo ago
 I was wondering if the logo would be a tortilla
 - granra 11mo ago
 haha I'm afraid it was a total coincidence that it kind of looks like it :D
- toastal 11mo ago
 I am already working on this <https://darcs.toastal.in.th/nixtamal/trunk/README.rst https://darcs.toastal.in.th/nixtamal/trunk/README.rst>
mikepurvis 11mo ago
As a nix person, I like this a lot and could see myself using it. My only criticism would be I don't love this kind of thing: "<!DOCTYPE html>\n" + html [ (attrs.lang metadata.lang) ] [ (head [ ] [ (partials.head context) ]) (body [ (attrs.classes [ "font-sans" "bg-white" ]) I understand that this is very flexible and powerful, but it immediately makes the templates highly non-portable and requiring of hand-authorship— fine for a personal blog by a code nerd, but a non-starter for when a designer is involved who will want to use visual tools. I see that right below that there's also a "normal string templating" option that's closer to conventional jinja2 or the like, but it's ultimately still pretty nix-ified. It might be worth some ifd [1] to allow a step that pre-processes conventional html + tags template files into the form that can be consumed by nixtml. [1]: or the still-experimental dynamic derivations: https://fzakaria.com/2025/03/10/an-early-look-at-nix-dynamic-derivations https://fzakaria.com/2025/03/10/an-early-look-at-nix-dynamic...
- granra 11mo ago
 I'm the author of nixtml. It's already doing IFD by using python to parse markdown content + metadata and superhtml to format the final HTML (a bit unnecessary, but I liked it while developing it). I really wanted the templates to just be nix functions. It shouldn't be an issue to pass the context to an external program with `pkgs.runCommand` or something and then read the result (IFD like you mentioned). Edit: I'm glad to hear you like it :)
 - mikepurvis 11mo ago
 Yeah, it feels like the more conventional way would be doing the template-filling as a build step, so it's Nix just for the overall structure managing a fixed build graph, and then a per-page Python run to actually fill templates and generate the snippets/pages. However, if you did want it to be nix all the way down and get more of that juicy dependency granularity, it could be more of a model where content and templates are transformed upfront into Nix source, which is then transformed and combined during evaluation. Obviously this is fairly slow in an IFD world where all that pre-work has to be serialized, but it would be interesting to experiment with what it looks like in a dynamic derivations context.
rnhmjoj 11mo ago
There's a more cursed one here: https://rgbcu.be/blog/htmnix https://rgbcu.be/blog/htmnix. It hijacks the Nix search paths syntax (e.g. import <path> {}) to create html tags.
- JoelMcCracken 11mo ago
 oh my god, what a horrible but incredible idea
- granra 11mo ago
 I had seen a few of those `__findFile` hackery articles lately and did actually consider doing that but I think having a nice way of adding HTML attributes would've been clunky :p Edit: although looking at this article it seems to be supported.
bigbuppo 11mo ago
I don't want to shit on this project, because that's not my intent. My biggest gripe with static site generators in general is that for some reason they require the author to write their pages in something other than plain HTML. It's literally a machine-readable format and yet they all want to mix json, yaml, or something with markdown. And "but the output html would overwrite the input html" isn't really an excuse since they all tend to output to a build directory. And before someone says, "well you can work on your dream static site generator yourself", rest assured, I am, but I'm also very lazy and usually stop once it gets to a "good enough" state for my own use, but isn't quite ready to share with others.
- granra 11mo ago
 Generally I think you have a point when making landing pages or things of that sort. I however basically only use static site generators for blogging and I think markdown/asciidoc/whatever + metadata is nicer for writing content than directly in HTML. I made nixtml and I take no offence :)
 - bigbuppo 11mo ago
 I think part of my take stems from the fact that I'm old enough to remember when SGML was supposed to solve all our problems.
- thangalin 11mo ago
 > My biggest gripe with static site generators in general is that for some reason they require the author to write their pages in something other than plain HTML. Being the author of KeenWrite, a Markdown editor that uses YAML variables (for content and metadata), I'm biased, but here's my take: 1. Writing tags for every paragraph gets tedious. 2. Markdown is succinct (**bold** vs. bold). 3. Content is easier to edit when not surrounded by angle brackets. 4. Content is more robust against markup gaffs (e.g., missing closing tags, tag typos). 5. HTML mixes structural markup with content, making design changes harder. 6. Markdown's simpler format is more portable to other output formats (PDF, ePub). 7. Markdown diffs are easier to review, and likely have fewer merge conflicts. 8. Non-technical contributors are more comfortable with Markdown. 9. Embedding metadata through meta tags is messier and harder to parse using raw HTML. Here are a couple of blog posts written in Markdown and converted to HTML using my software: * https://keenwrite.com/blog/2025/09/08/feature-matrix/ https://keenwrite.com/blog/2025/09/08/feature-matrix/ * https://keenwrite.com/blog/2025/10/15/creating-catchy-cover-letters/ https://keenwrite.com/blog/2025/10/15/creating-catchy-cover-... The user manual is a set of Markdown documents converted to PDF (note how the words TeX and ConTeXt and LaTeX are typeset; try to do that with HTML): * https://keenwrite.com/docs/user-manual.pdf https://keenwrite.com/docs/user-manual.pdf
badmonster 11mo ago
[flagged]
grim_io 11mo ago
I may be an unreasonable outlier, but I absolutely refuse to learn a complex config language. YAML/TOML? These are the maximum of punishment I'm willing to deal with, as they are quite universal and useful in many situations. If you need a complex touring complete config, you better use a reasonably popular general purpose language, or I'm not touching it.
- MangoToupe 11mo ago
  > you better use a reasonably popular general purpose language Most languages are horrible at templating, so that's its own world of pain.
  - grim_io 11mo ago
    What kind of templating are we talking about? HTML or in general? If we take python, for example, you could use jinja for HTML and composition/inheritance for the general stuff. That's all django does, and it does it well. I don't see what nix is doing so much better. Prefer JS/TS? You can have JSX, which is superior in any way compared to this nix-based abomination.
jebronie 11mo ago
this could have been a couple of lines of simple and maintainable php
- granra 11mo ago
  Too bad I don't write PHP then
jaredramirez 11mo ago
the name nixtml is so great

81 points by todsacerdoti 11mo ago

neat! I've been moving my site over to heavily use emacs/org for the authoring format and nix for the tooling infrastructure. I'll keep this in mind as a possible tool to help; I don't precisely know what I may still need to do that won't be easily doable with emacs.

Y_Y 11mo ago

Cool. After using Nix for a while I got pretty fed up with the (subjective) unintuitiveness of the language†. It wasn't even that I thought it was a bad language, I just couldn't het it to click (and doubly so after the advent of flakes). All the same it seems to me like if you grok it it's a great fit for constructing recipes for building things reliably that are part of huge dependency trees, and so it's natural that it would be a good website generator too. † Luckily others shared this issue, and the result was Guix which solves that problem while introducing its own.

lillecarl 11mo ago
It's a pretty special language, lazy evaluation and very basic types. However after spending the time to learn it to an intermediate level I think it's pretty great. Flakes are not great however, they're what happens when you "overdo it", sadly the momentum is behind flakes because some UX/DX improvements came along with them (lockfile in repo). I think the stdenv being built on bash is worse than Nix language. Module system errors can be very hard to troubleshoot because of lazy eval, sadly I can't see a reasonable solution without worse tradeoffs :(
- Hnus 11mo ago
  The flakes were the main UX/DX improvement for me. Before them I honestly could not do anything. The learning curve was so incredibly steep it almost felt like the people behind Nix were being malicious or intentionally gatekeeping. You finally stumble onto something you can at least partly understand, but then the powers that be throw two last obstacles at you like, First, flakes are "experimental", so you have to enable them. Back then there were like three slightly different CLI commands to do it, and it felt like none worked from like 5 tutorial tabs I had open, putting it `experimental-features =` into flake you are trying to switch to does not work obviously. Then you hit the classic situation where your flake is not committed or staged, so Nix refuses to see it. And instead of telling you that, it prints this abomination of error message "error: path '/nix/store/0ccnxa25whszw7mgbgyzdm4nqc0zwnm8-source/flake.nix' does not exist" (https://determinate.systems/blog/changelog-determinate-nix-331/#untracked-files https://determinate.systems/blog/changelog-determinate-nix-3...) I would not wish learning Nix from zero on my worst enemy, and I say that as someone who uses nix-darwin, devShells, deploy-rs and so on every day. The UX/DX is really bad, but nothing else comes close to its capabilities. Sorry for rant but without flakes I would not make it.
  - entropie 11mo ago
    > your flake is not committed or staged That has nothing to do with flakes. When I add a "module" to my repos its the same. I have to add it the git repos or nix does not "see" it. And yes, its pretty unintuitive.
    - Hnus 11mo ago
      It actually is specific to flakes. Classic nix commands can see untracked files just fine. Flake evaluation behaves differently because of how it decides which "scheme" to use: > If the directory is part of a Git repository, then the input will be treated as a `git+file:` URL, otherwise it will be treated as a `path:` url; This is why untracked or unstaged files disappear when using flakes: https://github.com/NixOS/nix/blob/ec6789f9dafce41011418fe6fcc5215e4b50e1e5/src/nix/flake.md?plain=1#L115 https://github.com/NixOS/nix/blob/ec6789f9dafce41011418fe6fc...
      - entropie 11mo ago
        Interesting.
        embedding-shape 11mo ago
        What's more interesting, is how confident your original comment read, but turned out to not be correct at all. Of course it has always been true, but excellent reminder that even humans hallucinate.
        entropie 11mo ago
        I tried to edit my comment but not possible. I could have sworn that I had this issue without using flakes. The start with Nixos was really bumpy; I must have mixed something up.
  - Tt6000 11mo ago
    [dead]
- nothrabannosir 11mo ago
  I’m convinced when people say they “love flakes” , 95% of them just love fetchTree and lock files. (Which is totally valid btw)
  - Hnus 11mo ago
    Fair, another thing I really like is you can do `nix flake show templates` and try to `nix flake init -t templates#trivial` and be like ahh so thats how its supposed to be done or init `full` and be like ok this flake thing can do a lot of things I didn't know it could do, you can then edit, delete and experiment.

NewJazz 11mo ago

Not to be confused with Nixtamal, the processed corn food. https://en.wikipedia.org/wiki/Nixtamalization https://en.wikipedia.org/wiki/Nixtamalization

hardwaregeek 11mo ago
I was wondering if the logo would be a tortilla
- granra 11mo ago
  haha I'm afraid it was a total coincidence that it kind of looks like it :D
toastal 11mo ago
I am already working on this <https://darcs.toastal.in.th/nixtamal/trunk/README.rst https://darcs.toastal.in.th/nixtamal/trunk/README.rst>

mikepurvis 11mo ago

As a nix person, I like this a lot and could see myself using it. My only criticism would be I don't love this kind of thing: "<!DOCTYPE html>\n" + html [ (attrs.lang metadata.lang) ] [ (head [ ] [ (partials.head context) ]) (body [ (attrs.classes [ "font-sans" "bg-white" ]) I understand that this is very flexible and powerful, but it immediately makes the templates highly non-portable and requiring of hand-authorship— fine for a personal blog by a code nerd, but a non-starter for when a designer is involved who will want to use visual tools. I see that right below that there's also a "normal string templating" option that's closer to conventional jinja2 or the like, but it's ultimately still pretty nix-ified. It might be worth some ifd [1] to allow a step that pre-processes conventional html + tags template files into the form that can be consumed by nixtml. [1]: or the still-experimental dynamic derivations: https://fzakaria.com/2025/03/10/an-early-look-at-nix-dynamic-derivations https://fzakaria.com/2025/03/10/an-early-look-at-nix-dynamic...

granra 11mo ago
I'm the author of nixtml. It's already doing IFD by using python to parse markdown content + metadata and superhtml to format the final HTML (a bit unnecessary, but I liked it while developing it). I really wanted the templates to just be nix functions. It shouldn't be an issue to pass the context to an external program with `pkgs.runCommand` or something and then read the result (IFD like you mentioned). Edit: I'm glad to hear you like it :)
- mikepurvis 11mo ago
  Yeah, it feels like the more conventional way would be doing the template-filling as a build step, so it's Nix just for the overall structure managing a fixed build graph, and then a per-page Python run to actually fill templates and generate the snippets/pages. However, if you did want it to be nix all the way down and get more of that juicy dependency granularity, it could be more of a model where content and templates are transformed upfront into Nix source, which is then transformed and combined during evaluation. Obviously this is fairly slow in an IFD world where all that pre-work has to be serialized, but it would be interesting to experiment with what it looks like in a dynamic derivations context.

rnhmjoj 11mo ago

There's a more cursed one here: https://rgbcu.be/blog/htmnix https://rgbcu.be/blog/htmnix. It hijacks the Nix search paths syntax (e.g. import <path> {}) to create html tags.

JoelMcCracken 11mo ago
oh my god, what a horrible but incredible idea
granra 11mo ago
I had seen a few of those `__findFile` hackery articles lately and did actually consider doing that but I think having a nice way of adding HTML attributes would've been clunky :p Edit: although looking at this article it seems to be supported.

bigbuppo 11mo ago

I don't want to shit on this project, because that's not my intent. My biggest gripe with static site generators in general is that for some reason they require the author to write their pages in something other than plain HTML. It's literally a machine-readable format and yet they all want to mix json, yaml, or something with markdown. And "but the output html would overwrite the input html" isn't really an excuse since they all tend to output to a build directory. And before someone says, "well you can work on your dream static site generator yourself", rest assured, I am, but I'm also very lazy and usually stop once it gets to a "good enough" state for my own use, but isn't quite ready to share with others.

granra 11mo ago
Generally I think you have a point when making landing pages or things of that sort. I however basically only use static site generators for blogging and I think markdown/asciidoc/whatever + metadata is nicer for writing content than directly in HTML. I made nixtml and I take no offence :)
- bigbuppo 11mo ago
  I think part of my take stems from the fact that I'm old enough to remember when SGML was supposed to solve all our problems.
thangalin 11mo ago
> My biggest gripe with static site generators in general is that for some reason they require the author to write their pages in something other than plain HTML. Being the author of KeenWrite, a Markdown editor that uses YAML variables (for content and metadata), I'm biased, but here's my take: 1. Writing tags for every paragraph gets tedious. 2. Markdown is succinct (**bold** vs. bold). 3. Content is easier to edit when not surrounded by angle brackets. 4. Content is more robust against markup gaffs (e.g., missing closing tags, tag typos). 5. HTML mixes structural markup with content, making design changes harder. 6. Markdown's simpler format is more portable to other output formats (PDF, ePub). 7. Markdown diffs are easier to review, and likely have fewer merge conflicts. 8. Non-technical contributors are more comfortable with Markdown. 9. Embedding metadata through meta tags is messier and harder to parse using raw HTML. Here are a couple of blog posts written in Markdown and converted to HTML using my software: * https://keenwrite.com/blog/2025/09/08/feature-matrix/ https://keenwrite.com/blog/2025/09/08/feature-matrix/ * https://keenwrite.com/blog/2025/10/15/creating-catchy-cover-letters/ https://keenwrite.com/blog/2025/10/15/creating-catchy-cover-... The user manual is a set of Markdown documents converted to PDF (note how the words TeX and ConTeXt and LaTeX are typeset; try to do that with HTML): * https://keenwrite.com/docs/user-manual.pdf https://keenwrite.com/docs/user-manual.pdf

badmonster 11mo ago

[flagged]

grim_io 11mo ago

I may be an unreasonable outlier, but I absolutely refuse to learn a complex config language. YAML/TOML? These are the maximum of punishment I'm willing to deal with, as they are quite universal and useful in many situations. If you need a complex touring complete config, you better use a reasonably popular general purpose language, or I'm not touching it.

MangoToupe 11mo ago
> you better use a reasonably popular general purpose language Most languages are horrible at templating, so that's its own world of pain.
- grim_io 11mo ago
  What kind of templating are we talking about? HTML or in general? If we take python, for example, you could use jinja for HTML and composition/inheritance for the general stuff. That's all django does, and it does it well. I don't see what nix is doing so much better. Prefer JS/TS? You can have JSX, which is superior in any way compared to this nix-based abomination.

jebronie 11mo ago

this could have been a couple of lines of simple and maintainable php

granra 11mo ago
Too bad I don't write PHP then

jaredramirez 11mo ago

the name nixtml is so great