3 ms·

This is a good review of a fairly complex piece of software. But don't let this convince you that all static site generators must be complex. Out of laziness,

This is a good review of a fairly complex piece of software. But don't let this convince you that all static site generators must be complex. Out of laziness, most sites I run have their own 100-200 line Python static site generator that takes Markdown (if I'm really feeling it) or HTML files with Jinja templates and generates pages around them. The core generator code hardly ever changes year by year. Here's an example [0]. This isn't to say that everyone should always write their own. I am just a bit surprised by all the debate around each generator because they all produce the same thing and the only (or major) variables are the template language and what themes are built in (though of course you can always bring your own CSS). But _using_ a static site generator is a very good idea. If you have no other inclinations, I think the stack that makes sense for anyone with multiple contributors is to use WordPress for editing and then have a plugin that will generate static pages from it so not every request to your site hits the database. [0] https://github.com/eatonphil/notes.eatonphil.com/blob/master/scripts/build.py https://github.com/eatonphil/notes.eatonphil.com/blob/master...

Bayart 5y ago
Yesterday someone ran a thread where people posted tons of headless CMS options[1]. There might be a few ideas there for people interested in your comment. [1] https://news.ycombinator.com/item?id=27674105 https://news.ycombinator.com/item?id=27674105
nickreese 5y ago
Author here. At it's core most static site generators are just fancy "string concatenation" tools. In my experience playing with several generators before building Elder.js it isn't so much about the output that matters it is about how the static site generator lets you do non-trivial customization. Things that would be hard without a larger framework. More importantly, when building a major project on a static site generator, it is important to have an upgrade path beyond a static site generator should you require it. Elder.js was built with that use case in mind though I didn't cover that in the article. Being able to move to SSR should the project require it is a huge plus in my book.
- eatonphil 5y ago
  > At it's core most static site generators are just fancy "string concatenation" tools. I think that's a bit reductive (especially since template libraries themselves are already complicated, not in a bad way). To me a static site generator is: 1) a string template library, plus 2) a file system walker/trigger to generate from a template, plus 3) additional data to feed the templates, plus 4) the actual content. Then there's of course the additional features you may or may not need: a tagging system, a comment system, a subscription system, etc. Thankfully despite all these components you don't need to write much of the actual code since they all exist as builtin (file system walking) or major OSS (Jinja, Mustache.js, etc) libraries. The SSG is primarily glue.
susam 5y ago
> But don't let this convince you that all static site generators must be complex. Indeed! For example, https://github.com/sunainapai/makesite https://github.com/sunainapai/makesite is a simple and lightweight static site generator written in Python. It can be customized easily by modifying the Python source code and adapting it to one's needs. I like that when I need a new feature, I can add it quite easily by writing a few Python functions. It is meant to be programmer-friendly. Disclosure: My wife wrote this project. I am just a happy user of the project.
- mturmon 5y ago
  I used ```makesite.py``` as a template for a small site of 100-200 pages that I maintain. It has worked quite well. The animating idea ("use this as a template but don't be afraid to customize or reinvent certain parts") liberated me from feature-by-feature evaluation of a bunch of complex config/templating systems. For a small site like mine, getting the content right is the main thing and the site generator should mostly get out of the way. I update the site sporadically and don't want to re-learn a complex templating and config-file system every time I go back to it.
AndrewStephens 5y ago
> Out of laziness, most sites I run have their own 100-200 line Python static site generator that takes Markdown (if I'm really feeling it) or HTML files with Jinja templates and generates pages around them. The core generator code hardly ever changes year by year. I maintain my site exactly the same way (minus the Jinja) and it is a workflow that works for me. Simplicity is best, even beating flexibility) when it comes to tools that help you express yourself. Otherwise you spend all your time wrestling with your tools rather than creating.
jjjbokma 5y ago
Mine is just over 1KLOC :-) But it includes both a RSS and a JSON feed, support for Twitter card / Facebook sharing, a calendar view, and a tag cloud. Live demo: https://plurrrr.com/ https://plurrrr.com/ Code is available at github: https://github.com/john-bokma/tumblelog https://github.com/john-bokma/tumblelog
- jazzyjackson 5y ago
  The choice of using one markdown document to render all the pages is really interesting to me. Do you just edit the document in your terminal? Trying to imagine the usability of that, I guess if I was quick at jumping from one "page" to another it might be faster than opening and closing files.
  - jjjbokma 5y ago
    I use Emacs to edit the page in Markdown mode with some additional font locking I wrote. It looks very similar to the actual blog. Currently the input file is 1.4MB (828 blog entries) which Emacs can handle without any problems. Searching works very fast. I keep the file open and writing a new entry is just adding stuff to the top of the file.
pjc50 5y ago
I've become convinced that it's easier to write a SSG than understand someone else's, and it's definitely quicker than trying to evaluate the market and pick one.
- schwartzworld 5y ago
  This is absolutely true. My "SSG" is basically just pandoc paired with a script to update the index on the main page and add the new post to the RSS feed.
_tom_ 5y ago
My last site’s generator is 71 lines of JavaScript. Just enough to walk the directory and run mustache over each file.

Bayart 5y ago

Yesterday someone ran a thread where people posted tons of headless CMS options[1]. There might be a few ideas there for people interested in your comment. [1] https://news.ycombinator.com/item?id=27674105 https://news.ycombinator.com/item?id=27674105

nickreese 5y ago

Author here. At it's core most static site generators are just fancy "string concatenation" tools. In my experience playing with several generators before building Elder.js it isn't so much about the output that matters it is about how the static site generator lets you do non-trivial customization. Things that would be hard without a larger framework. More importantly, when building a major project on a static site generator, it is important to have an upgrade path beyond a static site generator should you require it. Elder.js was built with that use case in mind though I didn't cover that in the article. Being able to move to SSR should the project require it is a huge plus in my book.

eatonphil 5y ago
> At it's core most static site generators are just fancy "string concatenation" tools. I think that's a bit reductive (especially since template libraries themselves are already complicated, not in a bad way). To me a static site generator is: 1) a string template library, plus 2) a file system walker/trigger to generate from a template, plus 3) additional data to feed the templates, plus 4) the actual content. Then there's of course the additional features you may or may not need: a tagging system, a comment system, a subscription system, etc. Thankfully despite all these components you don't need to write much of the actual code since they all exist as builtin (file system walking) or major OSS (Jinja, Mustache.js, etc) libraries. The SSG is primarily glue.

susam 5y ago

> But don't let this convince you that all static site generators must be complex. Indeed! For example, https://github.com/sunainapai/makesite https://github.com/sunainapai/makesite is a simple and lightweight static site generator written in Python. It can be customized easily by modifying the Python source code and adapting it to one's needs. I like that when I need a new feature, I can add it quite easily by writing a few Python functions. It is meant to be programmer-friendly. Disclosure: My wife wrote this project. I am just a happy user of the project.

mturmon 5y ago
I used ```makesite.py``` as a template for a small site of 100-200 pages that I maintain. It has worked quite well. The animating idea ("use this as a template but don't be afraid to customize or reinvent certain parts") liberated me from feature-by-feature evaluation of a bunch of complex config/templating systems. For a small site like mine, getting the content right is the main thing and the site generator should mostly get out of the way. I update the site sporadically and don't want to re-learn a complex templating and config-file system every time I go back to it.

AndrewStephens 5y ago

> Out of laziness, most sites I run have their own 100-200 line Python static site generator that takes Markdown (if I'm really feeling it) or HTML files with Jinja templates and generates pages around them. The core generator code hardly ever changes year by year. I maintain my site exactly the same way (minus the Jinja) and it is a workflow that works for me. Simplicity is best, even beating flexibility) when it comes to tools that help you express yourself. Otherwise you spend all your time wrestling with your tools rather than creating.

jjjbokma 5y ago

Mine is just over 1KLOC :-) But it includes both a RSS and a JSON feed, support for Twitter card / Facebook sharing, a calendar view, and a tag cloud. Live demo: https://plurrrr.com/ https://plurrrr.com/ Code is available at github: https://github.com/john-bokma/tumblelog https://github.com/john-bokma/tumblelog

jazzyjackson 5y ago
The choice of using one markdown document to render all the pages is really interesting to me. Do you just edit the document in your terminal? Trying to imagine the usability of that, I guess if I was quick at jumping from one "page" to another it might be faster than opening and closing files.
- jjjbokma 5y ago
  I use Emacs to edit the page in Markdown mode with some additional font locking I wrote. It looks very similar to the actual blog. Currently the input file is 1.4MB (828 blog entries) which Emacs can handle without any problems. Searching works very fast. I keep the file open and writing a new entry is just adding stuff to the top of the file.

pjc50 5y ago

I've become convinced that it's easier to write a SSG than understand someone else's, and it's definitely quicker than trying to evaluate the market and pick one.

schwartzworld 5y ago
This is absolutely true. My "SSG" is basically just pandoc paired with a script to update the index on the main page and add the new post to the RSS feed.

_tom_ 5y ago

My last site’s generator is 71 lines of JavaScript. Just enough to walk the directory and run mustache over each file.