5 ms·
Seems to be thoroughly identical to Webby: http://webby.rubyforge.org/tutorial/ http://webby.rubyforge.org/tutorial/ Or am I missing a trick?
by swombat 17y ago
Seems to be thoroughly identical to Webby: http://webby.rubyforge.org/tutorial/ http://webby.rubyforge.org/tutorial/
Or am I missing a trick?
- callmeed 17y agoAnd Jekyll http://github.com/mojombo/jekyll http://github.com/mojombo/jekyll is static site generation a big pain point for a lot of people?
- swombat 17y agoI 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...
- telemachos 17y agoI 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=411750 http://news.ycombinator.com/item?id=998411 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.
- henning 17y agoStatic blogging is the new twitter client is the new dynamic blog as an app to implement your own version of?
- callmeed 17y agodon't forget the URL shortener
- Legion 17y agoThat 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.
- swombat 17y agoI guess being able to use layouts that get "baked" into each of the final static HTML files would be handy. They all do that.
- hazexp 17y agoIt 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.
- brianm 17y agoMostly 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.
- compay 17y agoAnd hosting it for free at Github.
- tvon 17y agoThere is generally a lot of duplication in the open source software world, it's just the nature of the beast.
- ddfreyne 17y agoWhen 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!
- diligentdogs 17y agoAfter 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.