Comment by mikepurvis | Hacker News Reader

Comment by mikepurvis | Hacker News Reader

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...

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 :)

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.

Yeah it would probably be more efficient to do the templating as a build step in the derivation that parses the markdown. But after making nixidy[1] I wanted to have a crack at making a static site generator _in nix_. I'm open to expanding it though of course :)

[1]: https://github.com/arnarg/nixidy

Oh I can totally understand the impulse on that score. I guess going the way you have at the very least gets you out of some of the annoying handoffs of data between the two worlds, for example putting nix attrsets through toJSON so that they can be picked up on the Python side as template-fill variables.

The ROS 1 world was full of this kind of thing for getting values between Python and CMake and it's truly gross, eg: https://github.com/ros/catkin/blob/noetic-devel/cmake/templa...

Out of curiousity, having never worked in the business of making websites, what would be accessible to a designer? Jinja2?

I haven't for many years [1], but I think the current state of the art is stuff like webflow, silex, pinegrow. None of them _really_ let you directly open, say, django's template files and hack on them though, so there's still a gap where you've got a designer periodically exporting from a visual tool and then their changes having to be ported into the template representation. Obviously it's easy if all they touched was the CSS, but less obvious if markup is involved.

Honestly seems like there's a bit of a gap here. Would be an interesting case for copilot tbh— here, take the old export and the new export, and make me a PR applying those changes to the templates in this repo.

[1]: I was briefly an intern at a web shop in the late 00s and it was one guy doing Dreamweaver and the rest of us coding PHP around the assets it produced.

> I really wanted the templates to just be nix functions

This feels like Ruby template engines like haml† and slim†† a lot, or the various xml builders††† too

† https://github.com/haml/haml

†† https://slim-template.github.io

††† https://nokogiri.org/rdoc/Nokogiri/XML/Builder.html#class-No...

Groovy does something similar with MarkupTemplateEngine; I don't super care for it there either, at least as a mechanism for generating full webpages:

https://docs.groovy-lang.org/docs/groovy-2.5.3/html/document...

It can make a lot more sense as a way to prepare a smaller snippet of XML though, for example an xunit reponse.

As another Nix person who’s just made public a Nix -> HTML library (https://news.ycombinator.com/item?id=46139067 ), I’m curious what you think about a syntax like this instead?

    [ "div#main.container" { lang = "en"; } [ "h1" "Hello" ] ]

Would turn into:

    <div class="container" id="main" lang="en"><h1>Hello</h1></div>

I think I've hit the sweat-spot with the hiccup-inspired way of just using Nix data, and avoids a whole shebang of templating issues since it's not actually templates, just Nix data and expressions.

Reply on news.ycombinator.com