Hacker News new | comments | show | ask | jobs | submitlogin
Show HN: Static blog generator in about 1 KLOC (github.com)
44 points by jjjbokma 11 days ago | hide | past | web | 32 comments | favorite

1000 lines! What decadence!

This is what I use for my blog, it is 250 lines: https://gist.github.com/jes/88e3e587413d5794f69c281bdd14a27f

(Joking aside: cool project, and I expect it is substantially more capable than my ridiculously-hacky version).

The filesystem is the best CMS. For my static blog I just stick to a file naming format like ~/www/blog/2020-10-17-1.html and then assemble post indices with shell and variations for monthly indices. The RSS feed generation is a 100 line perl script though.

    ~/www/blog/ $ ./recentblogposts.pl; ls -v 2020-*.html | tac | xargs cat > blog-2020.html

This is my 103 lines python version: https://github.com/cristiandima/scribe. I wrote it about four years ago for my own blog and I still use it to this day.

It does however depend on a few libs and comes with separate html template files for a theme so I am not exactly sure where I stand on the golf course.

Mine is 60 lines of js; the markdown library does most of the work.


The most minimal I can muster is 3 lines of Bash:

    for filename in ./posts/*.md; do
        pandoc -s -c style.css $filename -o outputs/$(basename $filename md)html

This can get pretty pedantic. Where do you draw the line between what is the blog generator and the tools required to do it when counting the number of lines of code? One could easily argue in this case you might want to be counting the lines of code in pandoc, not this bash script.

That said, I do think this is the way to go, using a popular and generic tool (notably that you do not have to maintain) to accomplish a specific task. And more importantly, composing utilities together in a succinct and efficient way.

Also, if you used semicolons, or xargs with a pipe, you could make this one line :) newlines can be pretty arbitrary, I wonder if there's a better measurement for simplicity, like branches or statements/expressions.

In that case, here it is in one line, producing byte-for-byte identical output to the snippet above:

    pangeadoc -c style.css ./ -O ./_site
(pangeadoc, of course, is a fork of pandoc that when invoked as above behaves exactly the same as those "3 lines of Bash".)

damn, that's not a bad effort, I like it. But it does sort of feel like cheating ;)

Mine is about 140 lines of bash, and I don't /think/ i'm using anything that isn't part of coreutils.

The real story here is not the 60 lines, but the literate programming style used for it.

Aside from that, this approach is very similar to Marijn Haverbeke's (the CodeMirror author) generator, although your 60 lines does lean more heavily on third-party packages.


Mine is 4 lines, although it would be trivial to make it shorter. Here it is, although I'm actually working on migrating over to Hugo because it has some nice features that would be a pain to implement myself

  for filename in pages_md/*.md; do
   basename=$(basename "$filename" .md)
   pandoc "$filename" -f markdown_github -t html -o "pages/$basename.html"

1 line of Perl counts for 5 lines of Python, so you're actually behind on the golf course.

Interestingly OP's project includes equivalent Perl and Python implementations and his Python version is actually shorter, I did not expect that.

That seems like a lot of unnecessary maintenance to me.

I ported the program to Python when the Perl version was already fleshed out a bit. Keeping them in sync hasn't been that hard. After each update I run both versions on the same input file (resulting in my blog https://plurrrr.com/) and check with meld if there are any differences. This works very well. I am only a little worried that the Python code might contain some Perl-isms.

I disagree. It does a lot to help reliability and to find bugs.

It also means you have a completely decoupled backup system should anything go wrong with the primary.

I'm aiming to have at least one redundant component for every piece in the system I'm writing.

I did not notice that, thanks for pointing it out.

It started small but then I added an RSS feed (it already had JSON somewhat from the start) and various calendar views. Also some code was added to rewrite an image followed by text to a figure + figcaption to make it more semantic and easier to style.

My ~750ish one to split the difference.


I do think this is one of the most enjoyable projects I’ve ever done.

Same here. I was happy to find a small bug in the code so I could work somewhat more on it.

I've been toying with a project where you define your entire blog in one file (blog.json) and then you can pass that file to a generator (community built) and it will output html for you to deploy.

I wrote about it here -> https://ajaxdavis.com/post/Introducing-JSON-Blog/

I'm using the project to run my blog above.

I remember playing with these things in late nineties and making jokes at my friends creating bleeding edge CMSes with PHP and mSQL/MySQL I can get much faster than them. I wouldn't have believed things would come full circle over 20 years later.

Sometimes the journey is about learning where home is, and why it's home.

It has been that way for me. After trying many frameworks, "modern" languages, working on many teams, I've learned to love Perl, LCD-JS, and HTML in a whole new way.

My first blog ran on blosxom. I think I switched to something dynamic (textpattern) partly because back then I thought it mandatory that every month and day needed its own index if you just put in the month/day in the URL and stuff like that. Seemed more elegant to do that dynamically than store redundant information.

(Textpattern was pretty great. Taught me about the weird google searches that lead people to your site.)

Adding my own in here, 668 lines: https://github.com/mihaifm/smolpress

Static generator + CMS (extremely lightweight), management interface and markdown editing.

This looks really cool and fairly unique! Thanks for posting.

The one I wrote for the FastComments Blog is 140 lines. Each post is a separate markdown file, and it has RSS support. I love using NodeJS for little scripts like this. Generates in about 200ms for the content we have today.


There are hacks in that file. Beware the dragons.

Commenting support is or course done with FastComments...

I'm testing for same job bashblog -> https://github.com/cfenollosa/bashblog

Example of the output can be viewed at https://plurrrr.com/

And here we begin the “I did it in X lines” where X is less than the previous commentator’s boast.

Oh, it's just a Markdown to HTML translator.

I expected it to write the blog, with GPT-3.

The amount of "intelligence" you could fit in 1KLoC is probably not much more than a really bad Markov model...

Depends on what external services it calls.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact