4 ms·

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

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.

greghendershott 11y ago
Exactly. 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.
- davexunit 11y ago
  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. http://haunt.dthompson.us http://haunt.dthompson.us
  - greghendershott 11y ago
    Cool. Mine's in Racket: https://github.com/greghendershott/frog#frog https://github.com/greghendershott/frog#frog > (because there are so few of them and everyone needs their own) A million monkeys.... :)
    - davexunit 11y ago
      Oh, didn't know you were the frog author. Awesome!
deleted 11y ago
[deleted]
Tomte 11y ago
Have you had a look at Pollen, by Matthew Butterick?
- davexunit 11y ago
  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.
  - xrayspec 11y ago
    > 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).
MatthewPhillips 11y ago
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.

greghendershott 11y ago

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

davexunit 11y ago
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. http://haunt.dthompson.us http://haunt.dthompson.us
- greghendershott 11y ago
  Cool. Mine's in Racket: https://github.com/greghendershott/frog#frog https://github.com/greghendershott/frog#frog > (because there are so few of them and everyone needs their own) A million monkeys.... :)
  - davexunit 11y ago
    Oh, didn't know you were the frog author. Awesome!

deleted 11y ago

[deleted]

Tomte 11y ago

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

davexunit 11y ago
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.
- xrayspec 11y ago
  > 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).

MatthewPhillips 11y ago

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.