Hacker News Reader

Comment by MatthewPhillips | Hacker News Reader

> Two different parts of the brain conflicting. When I’m writing, I don’t want to be in code mode.

This is one of the reasons why I think static site generators are really in their infancy. He describes Pelican as "Jekyll for Python". This highlights what is wrong. You shouldn't have to decide on a tool based on what language it is written in; you shouldn't need to know what language it is written in.

A static site generator should have a very simple folder structure, something like:

draft/

published/

site/

templates/

That's it. You write markdown files in draft/ and move them to published/ when you're done. The generator runs as a daemon and spits out site/ No config files. No `bundle install` nonsense.

View on HN

The reason many people care about the language is because of the install method (at least that's been my issue). I don't use Ruby, so when I tried to use Octopress the other day I found myself installing a bunch of packages, then realizing that Debian's Ruby version is slightly too old (1.9.1 instead of 1.9.3), then trying to set up rvm or renv (or whatever), then giving up.

I write a lot of Python, so if it had been Python, I would have had the tools to properly install it, no problem.

This is the general problem with distributing "programs" with systems that are really better suited to distributing "libraries" (like gem, npm, and pip). If I am downloading a library, I must be writing code in the language, so it's no problem to expect me to have a reasonable tool chain set up. But if it's just a program that I'm going to run, I shouldn't have to have a language-specific package manager (let alone a rvm/virtualenv-type system) installed and configured.

Debian (and Ubuntu) actually ships all of 1.9.x as 1.9.1, fwiw. On my Wheezy VPS, "ruby1.9.1" is actually 1.9.3p194, on Ubuntu 12.04.2 it's 1.9.3p0, on Squeeze it's 1.9.2p0. It's some kind of API compatibility thing that probably makes sense to the Debian Ruby packagers, but not necessarily to you or me.

Interesting, well there we go, another thing I had to know about the Ruby ecosystem in order to use Octopress properly. :)

This is what I was planning on doing with Gitpress [1]. It's Python-based, but you'd never know it unless you're making plugins for it.

[1]: https://github.com/joeyespo/gitpress

I like what I see, why did you stop working on it?

Thanks, Matthew!

I put it on hold to complete a side project, aggrenda.com - the Pinterest of calendar events.

Then I got married in May, moved, and was accepted into a local startup accelerator with a StartupWeekend project, spacefinity.com.

I do intend to continue after things slow down again =)

Nah. If you want it to be that simple, then you'd just use a hosted Wordpress. Static site generators are for people who like to tinker. Or at least have the option of tinkering. I use Jekyll because I want to know then when I need to do something different than they expected, I can make it happen without inordinate fucking around.

There's a whole lot of space between hosted Wordpress and hacking on Jekyll. Not that hacking on Jekyll is hard, but there is something to be said for a more portable and easily installable/cross-platform solution. For example if my dad wanted to start blogging I wouldn't want to point him to Wordpress, but there's no way he'll dive into Jekyll.

Sure, but I don't think there are many people to whom "simple" means a command-line interface, or even a local generator whose files you upload somewhere. A hosted solution with a simple edit box is much more in line with most people's notions of simple. I think that's what Medium is going for.

Jekyll has support for drafts. Write your post in _drafts, and then move it to _posts when you are ready to publish.

Even better, Octopress in Jekyll allows you to simply add a published: false flag at the beginning of the post to label it as a draft.

Jekyll is too complicated. First, it requires a .yml config file, which is unused outside of the Ruby community. So this fails my "you shouldn't have to know what language it is written in requirement". Personally I don't think there should be any config files at all, but if you're going to require a minimal one at least pick something universal and easy to understand, like an rc file or maybe json. Secondly it has the weird _ naming thing. Jekyll was clearly made for Ruby developers, which is fine I just think the world needs something much simpler than that.

YAML is a much better choice than the two you suggested.

"rc file"s have no defined format, and json is a poorer choice than YAML.

I loathe ruby and still use Jekyll because I never have to touch ruby code to use it. I use it specifically _because it is dead simple_.

You're making stuff up.

YAML is okay when used in a simple manner such as for a basic configuration file, but it has a seriously fucked up spec with all kinds of landmines waiting to blow your legs off. If you aren't generating your YAML with @ruby_object.to_yaml then sooner or later something bad will happen to you.

That's why I prefer TOML. I wish more projects would pick it up for config. https://github.com/mojombo/toml

> "rc file"s have no defined format

Why does that matter in this case?

YAML is unused outside of the Ruby community?

Wacky. I guess all my YAML configuration files in C++ and Java and .NET aren't a thing.

YAML is unused as a configuration file for end users. Or at least it should be.

I'm curious who are these end users that would be scared / turned off by yaml but are totally cool with markdown.

YAML was crafted to be usable by most mere mortals. Whether or not it achieves that in practice is another issue ... but I think most people who find themselves using a static-site generator could find their way around a YAML config file just fine.

That isn't Octopress doing it btw, that is a feature in Jekyll.

Please make this happen.

Bonus points if it's agnostic to markup format.

Please tell me you're kidding. This is already how 99% of static site generators work.

Give me a link to one then because I clearly missed it and could use your help.

The 1% of static site generators I've seen are written in scripting languages that require me to install an interpreter and related build tools. Then I'm stuck with their own custom template, markup, and configuration language. And I just don't really care to manage all of that. Even as a highly technical user.

I wrote one myself in the 90s in Perl (and have thankfully lost the source code). They're fun to noodle with if you have the time.

I currently run my site on Pelican (and even patched the WP importer so that it properly preserves WP formatting). It's great but terrible. I still have to keep around a virtualenv. I have to maintain templates that I'll never be able to reuse. It's still not quite good enough. It's a good thing I make my money programming in Python and am familiar with the developer tools.

I'd like something a little more hands-off and with fewer dependencies.

We do our best to make Pelican as user-friendly as we can, but of course there are areas we'd like to improve upon. Community contributions to that end are most welcome. (^_^)

I'm sorry, are you complaining that you have to have python/ruby installed to use programs written in python/ruby, then attributing that "problem" to static site generators?

It's probably already been done several times over. There are tons of homemade static site generators languishing out there.

It has been. Seems most people write one of their own at some point.

I found the OP's suggestion appealing because it sounds like a solution that wouldn't require me to install some interpreter, a bunch of supporting libraries and tools, write my templates in some custom template language, custom configuration language, scripts, yadda, yadda.

It would be nice to have a system that ran as a unix-y daemon or cron job that just took a single dot-file and did everything for you.

This approach wasn't quite good enough for me. Even markdown -- for that matter, anything in a text editor -- still feels like "code mode" to me.

My solution was to make an open-source cms with google docs as the editor. I can manage my site from docblogger.org, use the fantastic google docs editor as my wyswig, and can edit the code to do whatever I want, whenever I want.

Code's at https://bitbucket.org/rattray/acvte/ and the interface is at docblogger.org for anyone interested. Very little activity/use so far, though.

That's basically what I've done with [trofaf][0]. 3 subdirectories:

posts/

public/

templates/

Posts without valid YAML front matter are ignored (drafts, for example), and the few options available are on the command line, no config file. I run it with upstart and it watches the posts/ and templates/ directories for changes, rebuilds as needed. Pretty much the simplest still-useful static site generator I could think of. Fits my needs anyway.

[0]: https://github.com/PuerkitoBio/trofaf

It could be doable possibly with a microframework that's optimized to cache views into a public directory the .htaccess checks first, before passing requests to the framework. Toss in a simple web-based CMS and a frontend for Composer (mumble mumble profit.)

I'm ashamed to admit i've been working on something along these lines off and on for a while but have nothing brilliant to show for my efforts. But the basic idea is entirely possible.

You might want to look at something like Prose (http://prose.io/#about). It aims to provide the convenience of CMS/blogging platforms like Wordpress for static site generators.

Reply on news.ycombinator.com