How I have chosen the backend technology for my blog - which of the myriad options suited me best and why.
As it happens - sometimes you can get away with no backend at all.
If you remember from my previous post I wanted simple to use solution to create website with minimum amount of fuss and moderate number of features. That was shouting to me Static Site.
For those unfamiliar - static site means you create a content and then run script which outputs the HTML and static files ready for upload to your hosting, no backend required at all.
The page is delivered exactly as stored, with little-to-no dynamic content possible.
Short list of pros and cons I went through:
- easy to host, can be done even on github pages
- no security vulnerabilities, nothing to attack but hosting
- plethora of ready solutions to choose from
- can be chock-full of frontend goodies
- no backend performance issues
- no database, migrations and library-version update problems
- can write content in any editor (yay - vim)
- how would I provide search?
- no dynamic content unless purely on frontend
- would need to leverage 3rd party services for some features
- no dynamic headers, dynamic redirects, form processing, mail sending etc.
- wouldn’t create a 99’th version of one-perfect-cms 1
Since my list of pros’ outweighted my list of cons by a nice margin, now all I had to do was:
Choose static site generator
There was of course an option of creating my own, but I have left it as a last resort.
I have filtered-out any generators that create an (React, Angular, Vue) apps, as I have strong opinion what is not a web app (e.g. blog) - in the future I may even write about it.
First one I have tried was a ruby staple: Jekyll.
It started nice - very good documentation, easy start process (4 step to working website). I was delighted with front matter, custom variables and big community. Data files would even enable me some more dynamic content or at least easy management of some lists - good feature.
Then I hit a first snag - meh template system, not slot based as I am used to, but more linear one that I am not fond very much.
Another problem was the language Jekyll is written in - ruby, I am not overly familiar with it 3 and trying to create even a simple plugin was a chore.
Having decided to check other options I moved on.
Wow, that’s fast! Written in GO it’s page/content generation is so fast it’s unreal.
Nice, extensible, can do anything you want. Asset management, tag management, style compilation - just check the docs
For my simple case it’s overly complex as well as written in unfamiliar language.
At least some familiar language, nice documentation too.
A bit opinionated, uses moment and lodash to generate. Not so easy as jekyll, not so powerful as hugo.
Looks a bit more like generic then custom-build solution, you can easily get lost in plugins - some of them doing exactly the same things, but that’s a bit of node/npm sickness.
Which became my choice, why?
- written in python, plugins in python as well - environment I am most familiar with.
- uses excellent Jinja2 template engine, in my opinion one of best if not the best there is
- easy to start, easy to extend, not overly complicated
- can create content in RST, which I like
- some simple plugins bundled in
- theme is entirely up to you, you can setup it in any structure you want
Of course that’s my reasons for choosing the generator - you may have different requirements or different background so some of the options above may suit your situation better.I suggest try a few.
Next on - build process
Apparently a rite of passage, every programmer will try to create at least one game (usually RPG) and every webdeveloper will create at least one perfect CMS, for him that is - noone else will be using them unless forced. ↩
There’s a theory that programmers are people who have better google-search skills then rest of the population. It has a grain of truth in it. ↩