Ah yes, it's true...but for a Ruby developer, something that involves Ruby is just about as good as something that involves bash :)

I guess I was thinking of "simple" in terms of the static HTML and deploy. I don't think you actually have to run any Ruby commands, you just run a command line task and it reads the textfiles from the specified directory.

Unless I missed it in the OP's description, one huge advantage that Jekyll has over the OP's bash solution is the ability to write in Markdown, made possible by the inclusion of Markdown parsing Ruby libraries. So the complexity added in the framework part, IMO, is more than made up in the simplicity of actual content-production.

  for i in ./*.md; do perl Markdown.pl --html4tags $i > pub/${i%.*}.txt; done;

And viola! We have markdown formatted to html.

Now if you consider "maintenance" or "separation of concerns" or any of the other things anyone using a framework takes for granted, this is inadequate, but that's not what I see this as. I could, of course, use grep and sed to do maintenance if I felt as much.

I think maybe both you and cmelbye in his reply are not considering is that this is just a step above manually editing and creating HTML files. The appeal isn't just simplicity, but a bit of nostalgia as well.

I guess it's a bit hard to explain, but the idea here is not having more layers than absolutely necessary between my thoughts and having it accessible to the web. I hope that made sense.

That's a nice idea, but it gets complicated when you want to create a uniform layout across all of pages, etc. Jekyll automates that so that you don't have to copy and paste header and footer blocks and things like that.