As mentioned in my first post, when planning out the rebuild of the blog, I researched a bunch of options. My first option, naturally, was to go with Django 2. I’ve been using Python 3.6 almost exclusively this year, and the feature set is certainly impressive. However I don’t want to spend a lot of maintaining an active web application. In addition, I have been planning on migrating away from Webfaction; they have served my well and was a cheap playground to grow as a developer, however now I use AWS across the board. The catch there is it would not be cost effective to run a Load Balancer, EC2 Instance for Django, as well as an RDS instance just for a personal blog.
So with Django out of the running, and the requirements being along the lines of:
- Ability to be Statically Hosted
- Easy to Write Posts (I don’t want to be writing HTML everywhere)
- Easy Customization
- Lots of plugins
- Low Maintenance
- Stable framework (I don’t want it to disappear mid blog)
Given the requirements, the first pass of choices looked something like this:
- Django Wagtail + Wagtail Bakery
As a side note, all but the first one can be compared side to side on www.staticgen.com/, which was an extremely helpful resource when researching the options available.
Django Wagtail is a CMS plugin to the Django project. It is meant to make thet backend of Django extremely user friendly and it supports a lot of other plugins; namely, in this case, Wagtail Bakery. Wagtail Bakery came highly suggested by a fellow pythonista in the PhillyDev slack channel. It will render out your Wagtail blog into a set of static files. That way every request doesnt hit a database or even need a server to be there to back it. This fulfills the
Statically Hosted requirement very nicely, as well as allowing me to be in an ecosystem that I know and love.
However the downsides is the Bakery side of things is still a bit experimental at the time of this writing, and all the details are not quite ironed out. I also kinda wanted to branch out away from my defacto hammer of using django to fix everything. At that, Django was also way overkill for the problem at hand; I needed a simple blog, not and entire web application framework.
The big player in the static site generator space, based in Ruby, and, at the time of this writing, has over 31,000 stars on github and over 7000 forks. My good friend Chris Becker runs his site as a Jekyll built site, and I have heard nothing but good things about it. There is a pretty large community around it, and tons of plugins.
Octopress started as a set of helpful plugins, opinions and themes for Jekyll, and has grown into its own toolset and community. It’s opinions in the Jekyll ecosystem generally are good ones, however active development on it has all but died off completely. The getting started guide was easy enough to follow, but the lack of contributions relative to others was a bit worrysome.
Being frontrunner for python site generation, this was a solid option for me, however the amount of batteries not included somewhat scared me off. There are plugins to do everything, and that is not something I particularly wanted to deal with. The documentation is great and it looks like it could serve my needs, but the initial setup seemed a bit more involved than the JS or Ruby alternatives.
I didnt dig as deep into this one as soon as I saw
go, but it certainly has a good following, tons of documentation, and an impressive list of features. It brags about its speed, however I don’t necessarily see that as a necessary benefit or even a good trait for a static site generator. The whole point of static is the speed comes from the delivery network, not the framework itself, so fast compilation is pretty far down the list of things I require.
Hyde is a tongue in cheek python clone of Jekyll that never really took off. Its name comes up a lot jokingly as a ruby vs python antagonist to Jekyll, however it hasn’t been touched in years and its capabilities and community pale in comparison to Jekyll’s.
For a few years now I have been deploying everything to AWS. In the past year or so, I have become a huge fan of the serverless architecture (more on that later), and thus the plan was to deploy this site via a Gitlab CI pipeline to an S3 bucket, distributed by cloudfront. This setup I have done many times on many projects, and it results in an essentially free hosting solution. I get free SSL certs via ACM, near infinte scale (and far beyond anything I would ever need), and the security and account control I am used to all over the place in AWS.
With how sure I was about deploying with AWS, this option that popped up on www.staticgen.com (a marketing tool for Netlify), gave me a lot of pause. I could host any of the above mentioned tools for free, with a custom domain and SSL Cert, with built in form handling and A-B testing included. If I didn’t already have a ton of tooling and monitoring setup around AWS, this would be an easy choice.
As previously mentioned, Hexo + AWS is the solution I ultimately chose to run the blog you are currently reading. However it was mostly a templating and ecosystem choice, as any of the above mentioned tools would have served me very well. For beginners looking to start a tech blog or otherwise, I would highly recommend Hugo, Jekyll, or Hexo on Netlify as an easy to setup and get going choice.