Getting the website setup
When I began dreaming this place up I had a few things that I wanted to keep in mind:
- Cost. I don't have a lot of money or income right now, and I don't expect the website to get a lot of traffic, so keeping costs down was an absolute must. 8£ a month for a traditional hosting solution might not sound that bad, except for something that I expect to be visited maybe a couple of times a month when I don't have an income it kinda is.
- Customisability. I'm a tinkerer and I like things to be the way I like them.
- No ads or unwanted popups. I value experience and aesthetics and ads and popups kind of make that impossible. I also think good content is its own marketing, so I don't think I need them.
- Blog (optional). I've tried to keep a blog once or twice before and while I enjoyed it, and keep thinking of things I want to write about, I also really struggled to keep consistent on that front. Therefore, if it would be possible to have a blog with this website that would be a nice bonus, but not a deal-breaker.
Given the criteria above, I decided pretty quickly that this website was going to be a static one since it is pretty much the only solution that fits the above criteria. Since I do everything locally and just upload the result I can setup whatever toolchain I want as long at it all outputs valid HTML at the end. I'll talk more about the one I picked in the next section, but suffice to say I'm very happy with it.
Static websites are also much cheaper to maintain than traditional dynamic websites. Partly because of size, partly because they don't need any computing resources. This website is, at time of writing, around 8.3 MB, with the vast majority of that consisting of logos, pictures and other static resources like PDFs. Another point is that I only need to pay for storage instead of a whole server. All you're doing when you visit this website is requesting a file, instead of having a server do all sorts of calculations and creating the files it sends you on the fly. That also has the added benefit that the site loads nice and fast!
It also came with a lot of other added benefits. First of all privacy and security, mainly yours to be specific. I wanted something that would log as little as possible. There are many reasons for this For example, GDPR is enforcing stricter regulations on websites, keeping logs and other data costs money, and the more moving parts you have to a website the harder it is to make it secure. I don't want to be implicated in another security scandal and I don't have enough manhours to monitor this space actively. But I also wanted this because I believe in only collecting what that you need. One of the oldest adages in both computer science and statistics is:
Garbage in, garbage out
This is all part of a sort of life philosophy I try to live by.
Get what you need, but not more than that
This makes things easier to maintain, (though I have been known to overengineer thing from time to time I'll admit) and is overall better for the environment. Technology is still advancing rapidly, but I don't think that the way we treat things like storage and computation is sustainable, and I think we should start looking at things like efficiency again instead of just raw performance.
This static website is really all I need, and so I wanted to limit myself to that. That helps me maintain the darn thing, keep costs low, and make sure I don't become part of the next privacy scandal. Pretty good deal right?
Picking a static site-generator
So now that I'd decided to use a static site generator, I had to pick one. Can't be that hard right? Well, not exactly. I went through quite a few options. There are a lot of them out there such as Jekyll, Sphinx, Ghost, Gatsby, Hugo and Zola.
My first consideration was that I wanted a stack that I was at least somewhat familiar with. As I knew I was going to heavily customise pretty much everything I knew I'd already have to dive back into HTML and CSS so I wanted to spend as little time as possible learning new languages/toolchains and even more so the systems admin that's involved in getting those systems set up. I really really really hate doing sysadmin stuff. This already cut out Ghost, Jekyll and Gatsby.
Secondly, I wanted something with a healthy ecosystem. Because this is just a side project, I can't spend too much time on it, so while I often don't mind taking a DIY approach to stuff, I knew that that would prove fatal for a project like this. This limited my options quite a bit since healthy ecosystems are rare, especially when you're a hipster like me.
Sphinx I already had some experience with, since that is what I'm using to document my python project PyNeg, but I find it very cumbersome to use, especially if customisation is involved. It's hard to get at the internals or interact with it in different ways than strictly intended, and I got put off by that prospect. Additionally, I find it quite slow and let's be honest, I don't want to have to wait for my dopamine thank you very much.
This left me pretty much with Hugo and Zola. Hugo, I liked. I had already used it once before to make another website. It was fast, customisable, has a healthy ecosystem with lots of themes and extensions and some really nice QoL features. Initially, I thought I'd go with that and started my work with it. I'm not super familiar with Go, but familiar enough that I was willing to give it a try.
Overall I liked Hugo, except for one thing. The templating engine it uses drove me absolutely crazy. especially the inconsistent scoping and the weird prefix syntax that was applied very selectively put me off.
So I finally settled on Zola, and so far I'm very happy with it. It's written in Rust, which means that it's pretty darn fast. I've also been interested in Rust for a while now, so I figured making this in something that uses Rust might help me get into that more. What's more, the community and documentation are good enough that I find it very usable, and the templating engine is robust and consistent enough for my liking. So there we go, Zola, it is!
Next was the hosting. I knew this was going to be the biggest source of cost so I took quite a while to decide on this. I thought about self-hosting for a bit, but I eventually decided that would mean too much overhead and too little downtime. I also didn't want to go with any of the free hosting services because of my aforementioned concerns about security, privacy, ads and popups, and if you put your stuff on someone else's platform that is generally very hard to control, just ask any Youtuber about COPPA. I also still believe in the saying that "if you don't pay for something, you're the product".
I also wanted something away from recommendation algorithms. Just something I can point to when someone asks me about my work, and generally have them find it. I don't expect to build a following or anything and that is what a lot of those services are geared towards.
ExoScale is a relatively small (relatively mind you) Swiss competitor to AWS. The advantage of them is that they are an EU based company, meaning they are bound by EU regulations and at least theoretically not bound by foreign governments. The problem with them was that I couldn't figure out how to just host a static website on it, which was a bit of a problem, to say the least. Another problem was that their pricing came in tiers, meaning that if I wanted to upgrade from one website to two I'd have to spring for a lot more infrastructure which I didn't like. The
So the final race was between DigitalOcean and AWS. With this, it ultimately came down to pricing. DigitalOcean has good pricing but they start you off at a minimum of 5$ per month for 250GB, which is astronomically more than I need, while AWS has pay-as-you-go so that's what I eventually decided to go with. Right now, this website is served from a simple S3 bucket which costs me less than a dollar per month, pretty neat right?
The final peice of the puzzle is that I added AWS' CloudFront, a content delivery network. Personlly I would have just not taken this step since I don't expect the demand for this website to be that high or widley spreak, but using CloudFront was the only way I could have the website be served over HTTPS instead of HTTP and I was quite adamant that I wanted HTTPS.
One added benefit of using AWS is that it's an industry standard so that can go on my CV as well, and it also gives me easy integration with other AWS services such as AWS Lambda, which I am planning to use to have this website also serve content security policies, but that is a story for another day.