Now I have moved my blog. chuvash.eu is a static site. I’ll share more details and insights later.
It has passed a few months since the move from Wordpress to a static site. Now it is time to summarize the insights.
Why I moved
Here are the reasons why I switched from Wordpress.com to a static site
- To be honest, the main reason was that I was curious about static sites.
- It appealed to me to have a fast and secure website (because there is no database that slows down or gets hacked).
- I finally got rid of the annoying ads from Wordpress.com. Don’t get me wrong. I appreciate Wordpress.com, as a matter of fact, I sacrified some really neat functions (such as the comments and the community) when moving to a static, but on that later.
- It finally got free from the vendor lock-in. Now I have all my blog posts as markdown files in a git repository. I can build them to any static website or even consume as they are, no fiddling with a database (if it were a own hosted wordpress site). I find it also easier to collaborate on my blog posts since I can grant access to the git repository to people I want to work together with.
- Speaking of git, now I have real version history of my content, no more accidential deletions.
Well, there might be more reasons, but these are the most important ones.
What I use
Just to give you a picture of how my basic setup is:
- a private git repository hosted on Github
- Hugo static site generator
- an app on Nettlify, with a build pipeline triggered whenever I update the code in the
- Custom domain - chuvash.eu, bought on loopia.se, but pointed to and managed on netlify.com
- an account on imagekit.io for storing images
- Google Analytics account
- Google Search Console account
Why this and why that
Here comes the reasoning around my technical choices. My blog - chuvash.eu - is just a hobby project - for the sake of community, I don’t have whether too much time nor money to invest in it. It should be secure, cheap, simple, fast and clean.
There are a plenty of static site generators. I researched some of them and decided to give Hugo a go (pun initially not intended), because:
- It was reported to be the fastest. Indeed it is, a joy to compile a whole static site in seconds when working on it locally, and it is especially good when you know that the build time in the Free Level of Netlify is limited.
- Go is an interesting and concise language I would like to get acquainted with. (Un-)fortunately, there was nothing I had to do with Go, except one little adjustment to a template.
- Hugo is open source
- Hugo is simple, it does not provide a lot of (confusing) extra features, it is good at what it its core. For my needs - having a blog - it was just what I was looking for.
- Hugo was easy to install locally and it has a built-in server (nothing unique, but definitely a good thing).
The whole point of going static is that you don’t have to depend on one provider only. I could have chosen Github Pages or something else, but I chose Netlify because:
- I have read good reviews from other guys who switched static sites. Why not to try it then?
- Netlify has a DNS feature, that was something I wanted to make my blogger life easier and be able to create subdomains when needed.
- Netlify has a generous Free Level (at least for now), that gives me free build minutes, automatic detection of mixed content (less secure http images)
- It gives me a free SSL certificate (Let’s Encrypt), also here, nothing unique anymore, but still.
- Integration with Github is awesome. Once authorized I could point to my repository and set up a build. Whenever the main branch is updated, a new build and publish gets triggered. Also, merge check on Pull Requests and a Site Preview (with a different url) is really sophisticated.
- Lambda functions seem appealing, although I have not used them on my blog, I definitely feel curious about them.
Why a private repo
First, I thought, it would be good to have a public repo for my site, but then I decided to keep it private (at least for now), because:
- I would like to work on my next blog post directly. I work in a separate branch and merge it to
main when I’m done.
- I might have some very specific instructions in README that should not be shared publicly.
- There might be a need in future to “remove” pages but still keep them in the version history internally.
- I still don’t know which license to use for my content.