Show HN: Super simple static blog generator, Benjen | Hacker News Reader

Show HN: Super simple static blog generator, Benjen

daeken.com

90 pointsdaeken45 comments

And, to complement this, I wrote a small program that serves static (or Jinja2) files from folders (optionally on AppEngine):

https://github.com/stochastic-technologies/static-appengine-...

You just create a folder called "yourdomain.com" and put your static files in there, upload, done. All URLs are rewritten (/foo/bar/ resolves to /foo/bar.html or /foo/bar/index.html) and you can host multiple domains on the same GAE instance. I use it for various static sites, such as my company's site (http://www.stochastictechnologies.com/) and my resume (http://resume.korokithakis.net/). They're all pretty much hosted for free, since they're static files on a single app on AppEngine, and migration is almost free (you just upload the whole thing to the host of your choice).

You can also assign multiple domains to one site, or rewrite your URLs to custom files.

What is the benefit of your server over just dumping the static files to S3 and letting Amazon serve them?

Does S3 remove the .html extension from URLs? I can't stand dirty URLs.

I think the main itch being scratched here, is the problem of templating.

Those that grok file systems, might be happy assembling content into an appropriate folder structure, and hitting a 'publish (to html)' button. You could use a little metadata - such as summaries and keywords to string it all together.

I know there are systems such as Pelican already out there, but it's still too complicated for Joe Blow to produce a site with the tool.

Frames were a pretty simple alternative to elaborate CMS's that have been employed to pretty much solve the same problem.

So much wasted CPU time and money. So called professionals cashing in while presenting building web sites as mystical and technically difficult (I realise the tech is difficult - but why should it be?). It goes so against Tim Berners-Lee's vision of publishing easily and straight from the browser.

Not having some dead simple web page editor, has ended in sites such as Facebook becoming 'the web' to so many people.

I miss Geocities, etc.

Tripod is still around, but I haven't actually tried to use it in ages. Shame about geocities though.

It maybe isn't simple enough for Joe Blow to use (yet?), but I started working on Serif[1] specifically to get away from having to manage the filesystem, without losing the simplicity of everything just being files. Having a web interface to edit content makes a big difference. (It still supports ignoring the interface entirely, while keeping certain things automatic like fine-grained timestamps.)

Jekyll, which it is similar to, had stagnated by the time I'd first put it up on GitHub, but it's probably closer in "philosophy" to Statamic[2].

[1]: https://github.com/aprescott/serif

[2]: http://statamic.com/

I have been seeing a lot of static blog generators being paraded around lately. I seriously think that static blog generators should be the next "hello world" when learning a new language. It seems to be useful in doing just that.

The intention of Hello-World is to check that compiler-linker and basic IO works.

A static blog generator checks that filesystem access works and your language provides a markdown and a template library.

Oh I mean it as a way to know how the language works.

EDIT for more information:

Being able to write a static blog generator means you have to learn most of the basic skills in a language from the data structures to objects/functions (whatever floats your boat). You have to also most likely interact with outside systems like I/O and databases (if your static blog generator is db driven). You get to familiarize yourself with packaging/modules that the language uses. So yea, I think creating a static blog generator as a next step after hello world would be great

I completely agree. I'm still working on my own but already i've learned a lot (among which, it's a bit more difficult than I expected.)

For many it is - just take a look on GitHub for the massive number of static site generators people have written for various languages.

It does seem to make more sense to just roll your own static site generator rather than try to learn a whole new framework and language like Jekyll, which then might not even give you everything you want. This is particularly true if you where to use a robust templating engine like Jinja2.

I like the idea of generating as many of our site pages as 'static' as we can. We created our own system for our needs but I am seeing a lot more of this as I look around. What I'm curious about is how people tend to handle dynamic content?

If you put Varnish in front of your site you can use edge side includes to populate the dynamic fragments of your site. Since it is Varnish you can also cache the fragments themselves.

https://www.varnish-cache.org/docs/3.0/tutorial/esi.html

Thank you. I've seen Varnish but never used it. I will give this a go.

I love seeing the source for such elegant single-purpose projects like this. I'm in the middle of writing my own static site generator for Python; it's a bit more feature-rich, but it's up at something like 800 LOC for the minimum feature-complete implementation. Great to see evidence that I have a long way to go..

Yes, I've learned a lot seeing how different people are approaching the static web page publishing job. I'm at the other extreme, a couple of bash scripts to push markdown files through markdown and add header/footer then push the changed ones out to the Web.

Seems nice but at first sight the code needs a bit more checks. There is a rmtree on a config parameter that could delete all your content if the tool is misconfigured.

I thought about mitigating that, as it could definitely have some nasty effects, but couldn't come up with a decent way to do so. Hopefully, people won't misconfigure it too often!

Since we're talking about minimalistic static site generators, here's the one I wrote a while back: http://srgpqt.github.com/Wakefile/

It's a 74 line Makefile (or 174 with generous spacing and comments) with rubygems and node module support.

I wrote something similar: https://github.com/jimktrains/gus

I like the flexibility of gus and the ability to create custom index files (for tags, by date, &c) and run preprocessing on asset files.

It also has a watch option, but at the moment that acts a little wonky and I'm working on fixing it.

One of my end goals is to create a search index and then use that server-side or ideally via JavaScript on the client.

Here is an entry I wrote about it: http://jimkeener.com/posts/first

These days most people prefer spend some time to create thier own static blog generators than use popular products like octopress or nanoc.

And that's great.

I wrote a Tumblr (=Editing backend) to static S3/Cloudfront script on App Engine for my linkblog. If there's some interest I might put it on Github.

What's the difference between a static blog generator and something like WP's blog system, or Posterous? Bit confused by the terminology.

Rather than a web app that runs and serves up content dynamically, this just spits out HTML that your webserver can serve up. No additional surface area for attack, no need for caching to keep things efficient, etc. Super simple.

Cool. So there is no DB involved at all for the content? When you edit, the old file is replaced by the a new one? I guess there is a backend you log in to and a wysiwyg for editing?

Nope, no DB at all. The way you edit the content is 100% up to you, but at the end of the day, your entries are just Markdown files in a directory. You can see my whole blog setup at https://github.com/daeken/Benjen/tree/master/daeken.com

Up-boat and comment for later reading and look thru.

I like your idea and I hope it's okay if I borrow some of your concepts for a future idea of mine ?

Yup. The only problem is with using shorturls (since there no DB object ID to map to).

I get around this with nginx rewrite rules. Since my old blog was Posterous, I spit out a bunch of rewrites to map my old URLs to new ones, e.g.:

    rewrite ^/superpacking-js-demos$ /2011-08-31_Superpacking_JS_Demos.html;

(Another solution is to have a directory for each post containing an index html file. I do it that way myself using Jekyll.)

You could have your static generator create symlinks for each post at the short url pointing to the actual page at the canonical url to handle this, and set your server up to follow symlinks.

Alternatively it could generate a table of redirects for you to put in your server config/htaccess.

Is this possible on S3?

No idea I'm afraid, it depends on their setup. I used it as one approach when generating a static blog a while ago under Apache, but there are plenty of options (using config redirects, using symlinked pages or dirs, using duplicate html pages with rel=canonical, using js redirects in extra html pages), and I'm sure some if not all of them would work on S3. As long as you're generating statically anyway, you can always add another step to generate all your short links automatically too in whatever form works on your server...

when you edit an article file, you also want to regenerate index, sitemap, rss feed, ... etc. or any pages that depend on the modified article.

when you edit a template or configuration, you need to regenerate entire site.

even if you blog very often, say 10 times a day, in 10 years, you only have 36k articles. Probably it shouldn't take too long to regenerate entire site for any kind of modification or addition of pages.

or, you can try to be smart and draw dependency graph (maybe using Makefile) and update what's only needed. basically you're solving caching problem, one of the hardest thing in programming.

If you don't mind a local backend that you access on the command line, you can host the blog itself (or any static site) directly on Github with no further ado. I recently moved my since-1997 site Vivtek.com to Github and freaking love it. It's never down, no matter how much I neglect my active server!

Generally, a typical blogging engine is made up of templates, your database of entries, and some sort of logic that stitches them together on the fly when a visitor hits your website.

A static blog is run through a processor once, and plain html pages are generated and stored on the server. When a visitor requests a page, they're served one of those static pages.

WordPress has caching plugins that allow your blog to serve static pages (helpful when traffic surges and your database might be overwhelmed), but, by default, a WordPress blog serves content dynamically (meaning it isn't cached).

Cool. Any plans to add an RSS feed? Your blog is really interesting, so I'd like to subscribe, but I probably won't remember to come back and check it manually.

This is an all too common issue with roll-your-own static site generators. There are quite a few blogs in this category.

Maybe there is space for something like that uses HTTP responses to check for changes, and generates RSS.

No need for it to be an issue though. Generating an Atom feed is dirt simple. I wrote my own Jekyll template to do it:

https://gist.github.com/graue/5184195

The only Jekyll-specific stuff is the first three lines and the `{{ .. }}` and `{% .. %}` templating code.

(For those who don't know, Atom is the better, cleaner replacement for RSS, supported by virtually all RSS readers. I like to promote RSS since people know what that means, but when I go and actually implement it, I spell RSS "Atom".)

This seems interesting, but I recently got started with Kirby and will likely stick to that for the time being.

I have mixed feelings about static site generators on one hand i really like the geeky approach where you make everything yourself and build it all from scratch and you fiddle around in the terminal ... on the other hand im really lazy and just want to push a button and it just runs.

And I think that is why I love the idea and concept of Kirby. It's PHP yes, but I this case I don't really think that, that is a bad idea. I wan't my blog to be easy and cheap to host. And a PHP hotel is easy and cheap. With Kirby you build your site and upload it to some random host and it just runs. No need to setup S3 or Github commit and push.

So thumbs up to Kirby, it suites my lazy habits.

I recommend you to change the URLs: use dash to seperate words and all lowercase.

Very cool. URLs are a little funky (underscores).

Reply on news.ycombinator.com