I did some due diligence on static site generators at the beginning of the year, first writing down my desired attributes:
* Actively maintained
* Supports Markdown
* Written in Python
* Flexible templating system
* Supports RSS/Atom feeds
* Supports syntax highlighting
* Track history (been around for at least a year)
The above list seemed like a good place to start, and after going through all the various candidates, the one that met all my criteria was Pelican. I liked the project and its author enough to eventually join the team as a committer. Check it out at: http://getpelican.com/
Cactus looks interesting, but I prefer having a wider range of deployment targets (instead of just S3). I also prefer the Jinja templates that Pelican uses instead of Cactus' Django templates. Just my two cents, of course. All of the various static site generators bring something interesting to the table — the more the merrier!
A lot of you are probably familiar with Flask and its awesome Jinja2 templating system.
There's a well supported, officially approved extension called Frozen-Flask that generates static sites from a Flask/Jinja2 deployment:
http://packages.python.org/Frozen-Flask/
Assuming one were looking to create a simple static file from scratch (e.g. a personal blog), why would one select Frozen-Flask over a traditional static site engine?
If you are familiar with building sites with Flask, I can obviously see the appeal, but for someone unfamiliar with Flask, is there any advantage to going the Frozen-Flask route over simply using a static site generator and content stored as flat markdown? One of the selling points of static sites for me was not having to include a database layer for something as simple as a personal blog with a few dozen entries that I wish to serve.
Composer is framework for building your own static site generator. It's not opinionated about what kind of website you want, or which templates you want to use, or what kind of pre/post processing you want to do, etc.
For example, shazow.net is composed by pulling metadata from a git repo and using author/timestamps those as variables in each Mako template container for Markdown+Pygments processed text.
Composer comes with a bunch of pre-built filters for convenience (Mako, Markdown, Jinja2, RST, Pygments—adding your own is bordering trivial), a site compiler and auto-reloading server, and some other reusable components.
If you're interested in doing something completely custom, this might be a good starting point. I haven't worked on it in several months but I like the core philosophy and design—I think others might too. Forks and pull requests welcome.
I've been very happily using Blogofile. It's what Mike Bayer uses for SQLAlchemy. There's a built in blog engine, and it uses Mako templates, which are significantly better than the django ones.
It also by default will recognize multiple formats (e.g. markdown, mako, plain html) for rendering and you can embed markdown inside of the mako templates.
It would be great if someone (esp. the generator's authors or users) could comment on how this is different than the other Pythyon static site generators, such as Pelican. Based on the docs, it appears that it's built with easy deployment to S3 in mind.
Author here. I haven't looked too much at Pelican, but Cactus was built for designers (eg. be simple). The goal was to get them from nothing to a fully hosted site on s3 in under a minute.
I have a weird approach to this problem that someone might like. I use Brunch, which is a frontend assembler (like Yeoman but with more flexibility). I then use a Jinja2 watcher utility over the output directory. So one watcher does Stylus>CSS, Coffee>JS, minifying, concat etc., and the other one is for the template stuff. I wrote a simple utility for the templating part, which can output site translations too if you want. https://github.com/jokull/jinjet
Warning: Not good for blogging or anything you would like to update often.
I’ve also tried Flask-Freezer for static sites. All the benefits of regular frameworks.
Cactus has some nice things going for it, but some decisions are weird. May I suggest using Jinja2 for templating, Django is complete overkill and simply an inferior template engine. Oh and make it at least somewhat PEP8 compatible.
Do any of these static site generators support A/B testing (probably via some JS)?
That's the real thing that I see missing in a lot of CMS's. If I could setup A/B tests right in markdown and easily post the results somewhere(A bit tricksy, yes), that would simplify operations hugely for a great many people.
Agreed. This would be a killer feature.
Right now the options you have is to do everything server side (say django-lean) or use one of the commercial options (optimizely). Not ideal.
My money on the static site generator race is on docPad.
Nice work. I really like the simple deployment aspect.
I've been working on a static site generator as well, but with a twist. My issue has always been having to learn a brand new framework and set of commands to simply generate a static site. I already know Django very well, so I built a static site generator on top of it. I just use the Django test client (https://docs.djangoproject.com/en/dev/topics/testing/#module...) to dump the static content to a folder. I have some markdown helpers too, so all posts can be written in markdown and live in some folder at the root of the project. I have a few more things to finish with it, if anyone's interested I can throw it on Github.
I converted my WP hosted blog over to socrates last year. Very familiar and enjoyable environment being someone who does python, and served up using GitHub pages. :)
I personally use Jekyll for my own blog - because I spent a lot of hours setting it up, and now it just works.
However, for my homepage[0], I use Asciiweb[1], a - As a fan of ASCII art, I'm really happy with it. It's great for a static homepage, though not that great for blogging.
It uses a custom markup language that supports a couple of great features: optional per-page configuration, executing scripts through a nifty <exec> tag, and the script's output is placed in the web page. I use this to run a BSD fortune script[2]!
The major problem with all static generators is that, by design, they can't host comments. And using a 3rd party source for comments ain't exactly what I'd be looking for (self-contained)
The minor problem is that all the ones I used so far are a lot more complex to use that dynamic generators, for some reason. (Even thus I write templates, css, etc for the dynamic ones as well). It seems like a "it has to be complex" syndrome :p
> The major problem with all static generators is that, by design, they can't host comments. And using a 3rd party source for comments ain't exactly what I'd be looking for (self-contained)
It's written in Python using Flask. You might find it useful and I hope you'll be able to help me expand it, since I havent found much time to do so myself.
> The major problem with all static generators is that, by design, they can't host comments.
Very few sites are enhanced by allowing people to leave comments. I don't go to YouTube for the comments.
I agree at the sub-optimality of third party comment hosting. Maybe a solution is to encourage better discussion on aggregators, and better aggregators?
As a visitor, I despise self-hosted comment sections.
I rarely feel the need to comment, but when I do, I don't want to give you my e-mail address (what the hell are you gonna do with it, anyway?), wait until it's approved by the author or constantly go check your website if someone replied to my comment.
I'd like to see a static site generator that still runs some kind of administrative backend somewhere. Then I could have clients or friends I do sites for log in to one of my personal machines and enter new stories/content, and it would generate the pages and push the updates. That would combine the best of a simple CMS with the best of static generation. Does something like this already exist?
How's this compare to Ruby's Jekyll and Octopress?
I think static site generators are pretty great...especially if you have a decent grasp of JS frameworks. According to the recent HN front page submission, Obama's $250 million fundraising site was run off of Jekyll.
tldr: Wanted to mess around with internals, but rather than learn Ruby I switched to a Python-based platform instead. I've learned Ruby since then, but only at a surface level of comprehension.
[+] [-] SnowLprd|13 years ago|reply
* Actively maintained
* Supports Markdown
* Written in Python
* Flexible templating system
* Supports RSS/Atom feeds
* Supports syntax highlighting
* Track history (been around for at least a year)
The above list seemed like a good place to start, and after going through all the various candidates, the one that met all my criteria was Pelican. I liked the project and its author enough to eventually join the team as a committer. Check it out at: http://getpelican.com/
Cactus looks interesting, but I prefer having a wider range of deployment targets (instead of just S3). I also prefer the Jinja templates that Pelican uses instead of Cactus' Django templates. Just my two cents, of course. All of the various static site generators bring something interesting to the table — the more the merrier!
[+] [-] laktek|13 years ago|reply
It will fit into all your requirements and has been there for almost a year now.
[+] [-] Pfhreak|13 years ago|reply
[+] [-] borntyping|13 years ago|reply
[+] [-] akavlie|13 years ago|reply
[+] [-] semenko|13 years ago|reply
A lot of you are probably familiar with Flask and its awesome Jinja2 templating system.
There's a well supported, officially approved extension called Frozen-Flask that generates static sites from a Flask/Jinja2 deployment: http://packages.python.org/Frozen-Flask/
[+] [-] alsocasey|13 years ago|reply
If you are familiar with building sites with Flask, I can obviously see the appeal, but for someone unfamiliar with Flask, is there any advantage to going the Frozen-Flask route over simply using a static site generator and content stored as flat markdown? One of the selling points of static sites for me was not having to include a database layer for something as simple as a personal blog with a few dozen entries that I wish to serve.
[+] [-] shazow|13 years ago|reply
https://github.com/shazow/composer
Composer is framework for building your own static site generator. It's not opinionated about what kind of website you want, or which templates you want to use, or what kind of pre/post processing you want to do, etc.
For example, shazow.net is composed by pulling metadata from a git repo and using author/timestamps those as variables in each Mako template container for Markdown+Pygments processed text.
Composer comes with a bunch of pre-built filters for convenience (Mako, Markdown, Jinja2, RST, Pygments—adding your own is bordering trivial), a site compiler and auto-reloading server, and some other reusable components.
If you're interested in doing something completely custom, this might be a good starting point. I haven't worked on it in several months but I like the core philosophy and design—I think others might too. Forks and pull requests welcome.
[+] [-] JeffJenkins|13 years ago|reply
It also by default will recognize multiple formats (e.g. markdown, mako, plain html) for rendering and you can embed markdown inside of the mako templates.
And vaporfile works pretty well for uploading the finished site to S3: https://github.com/enigmacurry/vaporfile
[+] [-] akavlie|13 years ago|reply
[+] [-] koenbok|13 years ago|reply
[+] [-] jokull|13 years ago|reply
Warning: Not good for blogging or anything you would like to update often.
I’ve also tried Flask-Freezer for static sites. All the benefits of regular frameworks.
Cactus has some nice things going for it, but some decisions are weird. May I suggest using Jinja2 for templating, Django is complete overkill and simply an inferior template engine. Oh and make it at least somewhat PEP8 compatible.
[+] [-] spitfire|13 years ago|reply
That's the real thing that I see missing in a lot of CMS's. If I could setup A/B tests right in markdown and easily post the results somewhere(A bit tricksy, yes), that would simplify operations hugely for a great many people.
[+] [-] sdoering|13 years ago|reply
I tried it once and it was quite interesting... easy to setup and really easy to use.
Just my two cents...
[+] [-] urlwolf|13 years ago|reply
My money on the static site generator race is on docPad.
[+] [-] troymc|13 years ago|reply
Just add one line of HTML your <head> and you're good to go. (It loads some JS.)
https://www.optimizely.com/
[+] [-] laktek|13 years ago|reply
[+] [-] jordanmessina|13 years ago|reply
I've been working on a static site generator as well, but with a twist. My issue has always been having to learn a brand new framework and set of commands to simply generate a static site. I already know Django very well, so I built a static site generator on top of it. I just use the Django test client (https://docs.djangoproject.com/en/dev/topics/testing/#module...) to dump the static content to a folder. I have some markdown helpers too, so all posts can be written in markdown and live in some folder at the root of the project. I have a few more things to finish with it, if anyone's interested I can throw it on Github.
[+] [-] mrhonza|13 years ago|reply
Jinja2 templates; write in md, rst, textile; sphinx syntax highlighting; yaml config; compatible with s3 and github pages; atom feed.
[+] [-] thurloat|13 years ago|reply
[+] [-] peterjmag|13 years ago|reply
Very simple, but perfect for my needs. Granted, I haven't added a blog yet, but it looks like it'll be pretty easy when I get around it it.
[+] [-] hardik988|13 years ago|reply
However, for my homepage[0], I use Asciiweb[1], a - As a fan of ASCII art, I'm really happy with it. It's great for a static homepage, though not that great for blogging.
It uses a custom markup language that supports a couple of great features: optional per-page configuration, executing scripts through a nifty <exec> tag, and the script's output is placed in the web page. I use this to run a BSD fortune script[2]!
[0]: http://www.hardikr.com
[1]: http://tastytronic.net/asciiweb/aw.cgi
[2]: http://www.hardikr.com/aw.cgi?main=fortune.rfk
[+] [-] zobzu|13 years ago|reply
The minor problem is that all the ones I used so far are a lot more complex to use that dynamic generators, for some reason. (Even thus I write templates, css, etc for the dynamic ones as well). It seems like a "it has to be complex" syndrome :p
[+] [-] jwandborg|13 years ago|reply
I have initiated work on talkatv (http://talka.tv).
It's written in Python using Flask. You might find it useful and I hope you'll be able to help me expand it, since I havent found much time to do so myself.
[+] [-] DanBC|13 years ago|reply
Very few sites are enhanced by allowing people to leave comments. I don't go to YouTube for the comments.
I agree at the sub-optimality of third party comment hosting. Maybe a solution is to encourage better discussion on aggregators, and better aggregators?
[+] [-] waxjar|13 years ago|reply
I rarely feel the need to comment, but when I do, I don't want to give you my e-mail address (what the hell are you gonna do with it, anyway?), wait until it's approved by the author or constantly go check your website if someone replied to my comment.
[+] [-] unoti|13 years ago|reply
[+] [-] smacktoward|13 years ago|reply
http://www.movabletype.org/download.html
If you wait long enough, everything old becomes new again :D
[+] [-] danso|13 years ago|reply
I think static site generators are pretty great...especially if you have a decent grasp of JS frameworks. According to the recent HN front page submission, Obama's $250 million fundraising site was run off of Jekyll.
[+] [-] wting|13 years ago|reply
http://blog.williamting.com/posts/2012/05/30/migrating-from-...
tldr: Wanted to mess around with internals, but rather than learn Ruby I switched to a Python-based platform instead. I've learned Ruby since then, but only at a surface level of comprehension.
[+] [-] koenbok|13 years ago|reply
[+] [-] human_error|13 years ago|reply
[+] [-] nXqd|13 years ago|reply
[+] [-] mattwidmann|13 years ago|reply
[+] [-] danjessen|13 years ago|reply