Open-Source Static Site Generators
staticgen.com
staticgen.com
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.
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 http://www.rogerbinns.com/blog/on-nikola.html
Nikola takes the same approach as Sphinx - for example defaulting to rst content and using conf.py for configuration. It also has reasonably complete functionality like blog posts, regular pages, arbitrary content, galleries, comment system integration etc.
Unfortunately the engineering choices over incremental builds as well as some others (eg choosing javascript/lightbox plugin that doesn't support swiping on mobile even though I pointed to one that worked exceptionally well) means I am on the lookout for an alternative. Worst case I'll probably write something that uses the Nikola file structure but makes better choices.
BTW I used Google+ for a while until they frustrated me by making it harder and harder to actually read content, plus not supporting things like RSS feeds and killing Reader. http://www.rogerbinns.com/blog/all-change.html
We don’t force it. You can easily get rid of it in your own theme.
[full disclosure: co-developer of Nikola here.]
The problem here is generating a sitemap using timestamps from output files (which are volatile) instead of the input content file. Since it tries to do incremental builds that means there are files already there that it didn't generate with the current build so nothing is known about them other than what can be gleaned from the filesystem.
Or the sitemap can use the input files to get the timestamps in which case the timestamps of files in the output directory won't matter. They would affect if-modified-since so it is preferable to have them deterministic.
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.
I must admit, one thing about Middleman that makes me roll my eyes is the use of "Hand-crafted" in the description of the project.
Jekyll has a very simple, convention driven feel to it. Templating is based on Liquid which can be a limitation in some cases.
Middleman feels more like Rails for static sites. Out of the box templates are ERB, which is messier but more flexible than Liquid.
StaticGen.com is built with Middleman, and that made it easy to add a Github extension that would pull in all the repository statistics from Github during the build and make this available to the views.
Ironically the folks at Meteor have pushed this approach the most: https://www.discovermeteor.com/blog/three-middleman-hacks-we...
[1] https://github.com/icambron/isaaccambron.com/blob/master/con...
So far, what I can tell is that Middleman provides a more efficient workflow than the database-driven CMSes I have used in the past.
e.g. with archive pages like /<author>/<lang>/<yyyy>/<mm>/ and category pages like /<lang>/<cat>/<subcat>/
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.
You could probably just arrange your posts in src/documents in this format, and let your layout do a lot of work for you such that each of the files in src/documents/<lang> contains little more than the blog text in its respective language.
And using something like Prose, multiple non-technical authors can update a Jekyll site: http://prose.io/#about.
It seems that so far the best approach would be to write a dynamic web app that does what I want, and save the content with wget. Seriously, it seems easier than any of the hackery I need to do.
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.
http://old.reactos.org/en/roscms.html
Screenshots & video tutorials: http://old.reactos.org/en/tutorial_roscms.html
Source: http://svn.reactos.org/svn/web/tags/RosCMS-3_LastVersion/web... (2009)
RosCMS interface was one of the first AJAX websites back in 2005 - back then GMail still used hidden iFrames to emulate AJAX.
(historical information)
On the home page - okay, if you need to do so. But why, just why on content subpages? Do you really believe that your purple banner with Roboto is that 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?
"The computer industry is the only industry that's more fashion-driven than women's fashion." Damn, Ellison was so right about that.
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!
I was thinking of just letting it lapse, but after using staticsitegenerators.net myself, I found I wanted a list that was a bit more strict, in the sense of not including anything that's not a static site generator (flat file CMSs like Kirby or even hosting services like BitBalloon or Fjords).
Also wanted some more details on the list, and there's a lot of potential to do more with a site like this in the future: more meaningful comparisons, guides to picking the right static site generator, etc...
Apart from that it was also just fun to redo the site with Middleman :)
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.)
Of course, an error such as this makes me doubt all the other information presented on staticgen.com
I do think it says something for the philosophy + out of box experience.
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.
Blog post about it:
http://jugad2.blogspot.in/2009/11/early-release-of-pysitecre...
PySiteCreator on Bitbucket:
Splitting hairs maybe...
We do this. I do this. We like to decide "how cool it'd be..." and do something. There's nothing bad in that, as long as we don't start coming up with invented reasons for its reasons to be.
When asked to quickly name a tool, most people say "hammer". When asked to quickly name a site application, most people think "blog". The focus on blogs inadvertently tells you that these authors were scratching their own itch of making the generator itself, and focused on the first application they could think of, and not responding to real needs. I remember when the coolest thing was for everyone to make their own web framework, everyone focused on making frameworks where blogs were easy to set up and demo. Notice a pattern?
In the end though, all sites need a machine to be put on, a server to serve them, and the arbitrary goal of pre-generating basic things like header and footer includes externally has little real value to offer when it comes to business needs ("business" used in a wide sense, as in people's real reason to have a site in the first place).
Any non-static site can maintain a static cache when performance is needed, and any non-static site can be as simple (and therefore as secure, by function of its complexity alone) as you need it. Maybe your non-static site "engine" can just do basic includes and support a contact form, and nothing else. It's easy to secure this, and you draw the line. But there's no need to ever cross that specific line where your site is 100% static. You have nothing to gain from it.
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.
(Disclaimer: I'm biased, I wrote one).
Or drop a link here :)