Nanoc: a Ruby site compiler that generates static HTML | Hacker News Reader

Nanoc: a Ruby site compiler that generates static HTML

nanoc.stoneship.org

47 pointswallflower33 comments

Open articleView on HN

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.

Let's also not forget StaticMatic http://www.staticmatic.net/. It has great support for HAML and SASS.

A helpful tip with for all of these static generators - if you need PHP or other code, just put it in the static HTML and have your deploy script rename the files to .PHP before rsync'ing them.

Regarding your PHP 'tip', that kinda makes the whole point of using a static generator in the first place a bit useless. And when you decide to do it anyway, configure your apache (or whatever you like) to parse .html as php.

It doesn't make it useless as all of my site is static except the contact form. To utilize another option just for a few lines of code in a contact form didn't seem practical to me.

I'm sure open to suggestions though.

Thanks for the tip on configuring Apache... I may look into that next time. I've got my .htaccess set to rewrite the urls to extensionless, so it didn't make too much of a difference.

Interesting yes, but dynamic to static generators/caches are plentiful. Almost every framework/cms has something like this. I'm the current maintainer of Boost - file caching for Drupal. IMO Boost offers more to the site admin then Nanoc: it supports Apache, Nginx, Lighttpd, & IIS; Caches HTML, XML, CSS, JS, & JSON. In a test, the Nginx version of Boost is faster then Varnish. Boost is also tightly integrated with Drupal, offering smart flushing of the cache and a multi process crawler.

Nanoc in comparison seems to add more administrative overhead to your sites work-flow; it should try to be smarter to make the web admins life better. Also, not having a dynamic language on the web server severely limits what's possible; a simple contact form has to be handled separately, thus making any site built with this even more complicated IMHO.

I don't understand why we need to "compile" everything, computers are fast. I made/use Simple Web Schema (http://bennewhouse.com/open_source/simple_website_schema) which generates pages on the fly from an XML document using PHP - sounds nasty but it's quite elegant (imho). It does require PHP (and what cheap hosting doesn't provide PHP?) and response time for a reasonably sized site (mine) is around 7ms single threaded, and scales well because no locking is needed - no compiling needed.

One of the most successful projects I worked on used static HTML generation. It was a company-wide system status site, so it needed to be up no mater what, no matter what type of issues we were experiencing. Using this approach we didn't have to worry about database issues or anything. Just static HTML hosted by a CDN offsite.

Hmm yeah, my stuff doesn't use a database either (it uses XPath and DOM/XML doc). Is it standard for CDNs to run anything beyond a naked apache instance (like mod_php)?

It seems like a giant can of worms to introduce mod_php. Do you allow sessions? Replication? How do you handle caching? These are non-trivial problems at CDN-level loads.

Offering 100% availability is crazy difficult once you add dynamic content into the mix. If you could do it, I bet you could make a million bucks.

Availabity with dynamic content is easy (ok not easy, but it's a fairly routine straightforward process). The CAP theorem says you get 2 out of the 3 of consistency, availability, partition tolerance. Just getting availability and partition tolerance by themselves is just a matter of good engineering, nothing revolutionary.

Me too! http://www.loup-vaillant.fr/projects/ussm/

Not as polished, of course, but usable enough to make my web site. Improvements coming soon.

I've used nanoc for my blog for a while. It's ok, but the next time I do need static HTML generation I think I will just use rails that I host locally and then statically mirror the site with wget --mirror and rsync.

This is so very old hat. Has been time over time over time for years. Why is this so high up on HN?

Where can one host sites like these?I think anywhere where one can get shell access?

Just create them locally on your computer and use rsync or ftp to send them to your web host.

With static HTML, you don't need any databases and it doesn't matter what type of server or operating system your host is running.

But nanoc does not just output the static html, it gives just the files, with no side bars and all. I think the layout part is not there.

Realized my mistake here, sorry for the misinformation.

The website is painful to look at. We really need to nip the whole rotated screenshot trend in the bud. Here's to 2010.

Reply on news.ycombinator.com