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

Seems to be thoroughly identical to Webby: http://webby.rubyforge.org/tutorial/

Or am I missing a trick?



And Jekyll

http://github.com/mojombo/jekyll

is static site generation a big pain point for a lot of people?


Static blogging is the new twitter client is the new dynamic blog as an app to implement your own version of?


don't forget the URL shortener


That is the part I'm not understanding. What does using one of these "static site compilers" save me from?

I guess being able to use layouts that get "baked" into each of the final static HTML files would be handy.


Mostly it takes you from thinking 50 requests per second is pretty good to being annoyed that you are only pushing 10,000 per second. It also tends to fail a whole lot less.


And hosting it for free at Github.


It also drastically lowers the amount of processing overhead per page served, after all, there's no dynamic code to process nor are there any database queries to execute.


I guess being able to use layouts that get "baked" into each of the final static HTML files would be handy.

They all do that.


I don't know, but I found Webby to be just fine... so I'm not sure why we need three static site generators that all seem to function more or less the same...


I would say the same about this conversation. My point being that I could pretty quickly find two previous Hacker News posts that discuss Jekyll and then quickly come around to the question: why do we need another <Webby/StaticMatic/Nanoc>?

http://news.ycombinator.com/item?id=411750

http://news.ycombinator.com/item?id=998411

One thing I know distinguishes Jekyll is that it uses Liquid which restrcts the templating in a way that makes it safer for some uses than giving the user access to ERB.

In answer to the more general question, I would ask how many scripting languages, text editors, email clients, etc. do we need? Programmers seem to love building things that work exactly as they want. So for all the talk about not reinventing the wheel, we get lots of overlapping toys. I don't think it's necessarily a bad things. More versions can lead to new ideas.


There is generally a lot of duplication in the open source software world, it's just the nature of the beast.


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.


After comparing nanoc and webgen a few years ago, I came away liking nanoc better because I found it more intuitive to extend.

Seeing that it's still being actively developed makes me want to take another look at it to see what's been going on.




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

Search: