Hacker News new | past | comments | ask | show | jobs | submit login

The reason I like static site generators so much is because it allows me to treat my website as a program that outputs a website. Take some posts in whichever format you prefer, write a program to parse them as a tree of HTML nodes, insert them into templates for HTML pages, Atom feeds, etc. It's all just plain text code and markup, no stateful database with a dynamic web application in front doing everything.


There's a spectrum of evaluation strategies from eager to lazy. Programs may mix various flavors.

Lazy evaluation combined with memoization is a sexy and elegant approach to some problems, as are dynamic web sites. On the other hand, whenever possible to do so, it's hard to beat the speed and simplicity of handing over a precomputed answer like "42".

A (very loose) analogy:

Static generation of HTML is roughly like using Lisp macros to evaluate some things before runtime (at "expand time" or "compile time").

The resulting transformed code could be a simple literal like "<html> ... </html>". Or the code might need further evaluation at runtime -- which is roughly like the precomputed HTML containing JavaScript to do things at runtime.

Funny that you mention Lisp. I am writing my own static site generator (because there are so few of them and everyone needs their own) in Scheme.


Cool. Mine's in Racket:


> (because there are so few of them and everyone needs their own)

A million monkeys.... :)

Oh, didn't know you were the frog author. Awesome!

The downside to static site generators is that you are constantly recreating the entire site, even for pages that won't change (which is most of them, most of the time) every time you run it. It's a function of:

   template(data) -> html
I'm a fan of the inverse of this. The template and the output (html) are the same thing; I don't separate them. Instead I just update the html when something changes. The function is:

  update(html, data)
Where update is a function you write that modifies the html in place.

The upside to this is that generating new content is cheap, you only ever update the things that need updating.

The downside is that your html output and updating function are tightly coupled; you can't change the structure of your html without also changing your update function.

I think that's ok though. Changing templates are infrequent enough to warrant the increased cost of fixing everything when you do change them.

Have you had a look at Pollen, by Matthew Butterick?

Yes. I like Butterick's "Practical Typography" a lot, and the rationale behind using Racket. That said, I don't actually like Pollen because it's just a string-based templating system. Instead, I want to use something that is based around s-expressions. My static site generator, Haunt, works with SXML trees instead of raw strings which is much nicer to work with.

> just a string-based templating system

Not sure what you mean. Pollen is derived from Racket's text-based DSL, Scribble. Like Scribble, Pollen lets you embed Racket-style S-expressions in your documents. Moreover, Pollen documents compile into X-expressions (= the Racket equivalent of SXML).

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact