I use Nikola. On the tech side the developer decided to model it as a series of tasks such as render photos, render posts, build rss etc. Those tasks are also implemented to run incrementally. For example if you add a new post then only that new post gets rendered to the output directory.<p>While this sounds fine in principle, it soon gets messy. A configuration change may require everything to be rebuilt. But if you rename or delete a source file it didn't track how that ended up in the output directory so you end up with a slow accumulation of crud. It turns out to be fairly easy to confuse all the incremental logic and end up with messy builds. Add poor decisions like using the datestamp of items in the output directory to build the sitemap (they don't set output directory datestamp to that of the input items) and you get important failings.<p>In my opinion, incremental builds should give the same results as full clean builds or you have a fragile non-repeatable build - something that is very undesirable. I wrote a bit more at <a href="http://www.rogerbinns.com/blog/on-nikola.html" rel="nofollow">http://www.rogerbinns.com/blog/on-nikola.html</a>
It would be nice to have a more detailed feature comparison to get some idea of why I should choose one over the other.<p>I'm currently trying out Pelican just because I'm comfortable with Python and Jinja2 already, but I really have no idea if it's actually the best choice for the kind of site I'm trying to build.
Is there a static site generator with support for multiple authors and multiple languages?<p>e.g. with archive pages like /<author>/<lang>/<yyyy>/<mm>/
and category pages like /<lang>/<cat>/<subcat>/<p>I fail to see any. I've tried to configure many of the available generators, but no one seem to have the same itch I have.
In 2004, RosCMS was one of the first open source static site generators with an web CMS.<p>The ReactOS.org website survived several Slashdot effects with a 500 MHz web server, back 2005 til 2013 (though old server was replaced in ~2007). The website has been translated into more than 27 languages.<p><a href="http://old.reactos.org/en/roscms.html" rel="nofollow">http://old.reactos.org/en/roscms.html</a><p>Screenshots & video tutorials: <a href="http://old.reactos.org/en/tutorial_roscms.html" rel="nofollow">http://old.reactos.org/en/tutorial_roscms.html</a><p>Source: <a href="http://svn.reactos.org/svn/web/tags/RosCMS-3_LastVersion/web/" rel="nofollow">http://svn.reactos.org/svn/web/tags/RosCMS-3_LastVersion/web...</a> (2009)<p>RosCMS interface was one of the first AJAX websites back in 2005 - back then GMail still used hidden iFrames to emulate AJAX.<p>(historical information)
Seriously, who came up with the idea that you should have to scroll down at least one full screen page in order to see just the tiniest bit of actual content?<p>On the home page - okay, if you need to do so. But why, just <i>why</i> on content subpages? Do you really believe that your purple banner with Roboto is <i>that</i> incredibly beautiful that I want to just stare at it for a minute before scrolling down to the meat, each single time that I click on a link?<p>"The computer industry is the only industry that's more fashion-driven than women's fashion." Damn, Ellison was so right about that.<p>Don't get me wrong, I am actually a typographer, and I am the last person on earth who wouldn't value appropriate white space. But ... seriously, find the right balance!
What's the difference with <a href="http://staticsitegenerators.net" rel="nofollow">http://staticsitegenerators.net</a> ? Why another one ?
It's kind of a relief to see this. At my work, I don't have html files to build, but thousands of config files to build and the solution has been a home grown configuration generator. For us, cluster configuration is a simple binary blob + config, so it's a relief to see that the path I've gone down doesn't appear to be too crazy.
Metalsmith (metalsmith.io) actually uses consolidate.js as a template manager. consolidate.js supports 24 separate template engines (<a href="https://github.com/visionmedia/consolidate.js" rel="nofollow">https://github.com/visionmedia/consolidate.js</a>). So Metalsmith's "templates" entry that only lists "Handlebars" is extremely misleading.<p>I suspect there are other generators on staticgen.com that also use consolidate.js and suffer the same misrepresentation. (I just don't know the other generators well enough to know off the top of my head which ones use consolidate.js.)<p>Of course, an error such as this makes me doubt all the other information presented on staticgen.com
PySiteCreator is a small tool I wrote a while ago. It lets you create a web site by writing it in Python.<p>It's not meant to be a full-fledged static site generator, and has only a few features. I first wrote it as a tool to create wikis programmatically (and hence called it DSLWiki), but then realized that it can be used to create general web sites, so renamed it to PySiteCreator.<p>Blog post about it:<p><a href="http://jugad2.blogspot.in/2009/11/early-release-of-pysitecreator-v01.html" rel="nofollow">http://jugad2.blogspot.in/2009/11/early-release-of-pysitecre...</a><p>PySiteCreator on Bitbucket:<p><a href="https://bitbucket.org/vasudevram/pysitecreator" rel="nofollow">https://bitbucket.org/vasudevram/pysitecreator</a>
I noticed the list didn't include any static site generators written in PHP, so I googled and found a couple:<p>* <a href="https://sculpin.io/" rel="nofollow">https://sculpin.io/</a><p>* <a href="http://phrozn.info/" rel="nofollow">http://phrozn.info/</a>
Octopress is a "built out" blogging example built on top of Jekyll. Showing Jekyll (a static site generator) and Octopress (a good example of how to build stuff on top of Jekyll) is a little misleading/confusing.<p>Splitting hairs maybe...
I've found a lot of these tend to be blog-centric, which seems odd to me considering the primary use case I've found with static site generators (Punch in my case) has been creating one-off content sites for clients in scenarios where we don't need a CMS. Folks seem to be really fixated on building these as blog engines, which I find baffling
Using Pelican for almost everything under <a href="http://exentriquesolutions.com" rel="nofollow">http://exentriquesolutions.com</a> - have tried Jekyll, but somehow Pelican seems much more pluggable.<p>Can't recommend Pelican enough - if you're still looking for one, do give Pelican a try: theme support, Jinja templating, plugins and much more.
As I was doing some Rails work anyway I used Rails plus a little bash script and wget to crawl the site which I then deploy. It has it's limitations but I was able to get it all built quite quickly and didn't need to learn any new syntax (I've got the hang of Markdown since so I might do it differently if I did it again).
I told my friend he should list his, Zodiac, on there. <a href="https://github.com/nuex/zodiac" rel="nofollow">https://github.com/nuex/zodiac</a>
Heh, I was working on a SSG early last summer for my own stuff in Common Lisp. It's easy to make a bad and overcomplicated one. I know - I did it. :)