Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

When I wrote nanoc about two and a half years ago, webby, staticmatic, jekyll, … did not exist, and I was looking for a way to publish a web site on a VPS with very limited resources.

I didn’t find anything that fit my needs. There were only very few static site compilers back then, so I decided to write my own (yes, I realise this expression is way too common). Soon after I released v1.0 in april 2007, other static site generators started popping up: StaticMatic and webby had their initial release a few weeks later.

Yes, there indeed is a lot of duplication in the static site compilation world. On the “about” page on the nanoc site, I give a list of static site compilers written in Ruby. The list is likely incomplete, even though I try to keep it up-to-date as much as possible. It also only contains site compilers written in Ruby, and omits site compilers written in other languages. The list currently contains the following:

* Hobix

* Jekyll

* Middleman

* nanoc

* RakeWeb

* Rassmalog

* Rog

* Rote

* RubyFrontier

* StaticMatic

* StaticWeb

* Webby

* webgen

* Yurt CMS

* ZenWeb

The diversity in static site compilation tools is huge. Static site compilation newbies are likely to be overwhelmed, and this is not a good thing. Can we fix this, please?

About a year ago (I don’t recall the exact moment), I informally contacted Tim Pease, author of Webby, and asked whether he would be interested in combining our efforts and merge nanoc and Webby. He unfortunately had no interest in doing so at that time (I’m not sure why).

I believe that combining the individual developers’ efforts is the way to go here. Every static site compiler out there has its own strengths and weaknesses. If we want to get rid of those weaknesses and combine those strengths, these projects need to be merged and individual developers need to work together. There are three goals that can be achieved this way:

1. Combine the individual tools’ cool features.

2. Get rid of weaknesses by seeing how other developers approach the issue.

3. Reduce diversity and make it easier for newbies to jump in.

I have no plan of action describing how to approach this problem yet. I have little experience as project lead for open-source projects; few of my open-source projects have dedicated contributors. Given that the other static site compilation tools are one-man efforts as well, I suppose that their developers have little more experience than myself (apologies if I’m wrong).

So, if you are the developer of a site compilation tool and you’re inspired, do contact me (you can find my e-mail address at stoneship.org/about) and we’ll see how we can tackle this problem. Time for some brainstorming!



First, thanks for sharing your work as open-source.

In response to this post, though, I have to say that I never quite understand why (in the world of open-source software) people often think that merging is somehow good or necessary. We don't think that in other areas (merge Apple and Microsoft?, merge Honda and BMW? merge Scorsese and Fincher?).

I was recently one of the static site compilation newbies you mention. I wasn't overwhelmed. I was delighted to have so many options to choose from. I looked over a bunch of the different platforms, and then I made a choice. It was easy, and again I liked having the options.

So my serious response to you as a user of open-source tech is stop worrying about the other projects. Make yours as good as you can with whatever time you choose to devote to it. There's no reason to merge.


I agree that merging doesn't seem to be necessary. Probably they will be selected out until a few winners emerge.

Currently Ikiwiki seems to be the most feature-rich to me, so i use it. The downside is an ugly template language and Perl.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: