I’ve been postponing building my own blog for some time. Largely due to a good amount of procrastination, but also because there’s a lot to choose when it comes to platform and technology stack, so that could take some time. Since it might be useful for others, I’m sharing my thoughts and considerations during the process.
Why a blog
The time was right to start a blog. Blogs are an important source of information in my daily work and I’ve been relying on them for years for inspiration, problem solving and learning new things. Even though video content or podcasts are very popular and probably more fashionable, I much more prefer to read about a topic rather than to skip through a video looking for the interesting bits.
By writing my own content I hope to give back some knowledge to the community and simultaneously build a log of ideas and solutions for others and my future self.
I also find myself regularly in situations where I’m implementing something that could be explained better with some background information and a blog to direct others to would be very helpful. Writing helps to clarify thoughts and transform them into more easily consumable information.
Platform or self-hosted
Blogging platforms are quite popular and it’s easy to see why: you don’t need to waste time on technology and you can directly start producing content. They also provide easy discoverability and an instant audience that can interact with the content, using comments, subscriptions and likes. There are many popular platforms to choose from, such as Medium, DEV and LinkedIn Articles. Or hosted solutions like WordPress.com and Wix.
Even though this looks very attractive, these options were quickly out. I wanted to have full control over my content. Like Scott Hanselman wrote over a decade ago: I wanted to own my words. No dependencies on third-party platforms and most importantly: having my own domain that I can point wherever I want for ultimate flexibility.
Self-hosting options
Going down the self-hosting route means making some decisions regarding frameworks and frontend tech stack. I didn’t want to be bothered with securing and updating applications such as WordPress so it had to be something that could be build and maintained without too much effort.
Setting up a Single Page Application (SPA) using Blazor, React, Angular or Vue is probably a bit overkill for a content focussed website.
But, there are plenty of static site generators. These applications take input files (usually something like Markdown) and generate HTML pages during the build. It usually produces a set of HTML, javascript and CSS files: a Multi Page Application (MPA).
I decided to stick to a javascript/typescript based system because this is what I’m most familiar with. That means Jekyll (Ruby) and Hugo (Go) were off the list. I had some experience with Gatsby for the XPRTZ website so this was an interesting candidate. Astro was the relatively new kid on the block and has some big promises: it’s supposed to be fast, light weight and very flexible when it comes to content and integrations with component frameworks.
Since I disliked the slow build times of Gatsby I decided to give Astro a go (I have to admit, I’m also a sucker for shiny new things).
Settling on Astro
Astro proved to be a great option. It’s designed for content focussed websites which means it’s super fast. It’s also a very simple framework, so it’s easy to learn and to get started with. And finally, it’s extensible enough to support more complex features if the need rises for it in the future, using extensions and integrations and support for MDX and frontend frameworks.
Continuous deployment
I decided to stick the blog into Azure Static Web Apps because of it’s simplicity. By deploying to Azure Static Web Apps I can utilize a CI/CD pipeline that we get for free by integrating it with GitHub.
Any push to the main branch triggers a GitHub action that builds the project, generates the static site and deploys the artifacts to Azure Static Web Apps.
This means I can write my blog posts in Markdown using a simple editor or even in the online GitHub Visual Studio Code. Posts that are not yet finished can either be placed in a separate branch or on main branch using the ‘draft’ feature of Astro.
Given the criteria I had, I’m very happy with the choice of Astro and Azure Static Web Apps. I’m looking forward to further tweaking the blog and adding more content.