Ever since I was a kid (I mean, I still consider myself a kid, but let’s think of this in terms of being around 12–14 years old), I’ve always been into computers. I was introduced to them through PC games. I remember paying an hourly rate to play Counter-Strike 1.6 at an internet café.
A few years later, I got my hands on my own personal computer, and it was almost like a whole new universe opened up for me. I’d use it to play music, browse the internet, connect with my friends on Facebook (yeah, it was a thing in the 2010s), and, of course, play some more games.
In parallel, while using all this amazing software, I deeply desired to build things both for myself and for the folks who lived in this alternate universe. This motivated me to pursue my education and career in Computer Science.
Out of the million things I intended to build, two were an end-to-end RPG game with beautiful character sprites (😅), and a blog, which I’d often think of as my little corner on the internet.
I’ve had my site for a couple of years now and have already revamped it multiple times for various reasons. In this post, I’ll be writing down the tech stacks I’ve considered and my reasons for moving away from them. I hope this also motivates and helps you choose a tech stack for getting started with your blog.
I first created probably countless iterations of a portfolio site with React and deployed them on a free subdomain from one of the many available hosting providers. I later bought my own domain and built my initial site on Next.js with its App Router, Tailwind, and GSAP for animations. This lacked the “blog” aspect, and while I was about to add it to my existing site, I discovered Astro.
I immediately loved Astro and stuck with it for a long time. This was because it had a very simple learning curve, shipped zero JS by default, had a beautiful View Transitions API, and supported image optimizations out of the box. All this is to say that it was very hard to build a non-performant site with this framework. I’d create my blog posts as MDX files, write them via VS Code, and push them to my CI/CD pipeline, which would then build the site and serve the generated static files. Since the pages were static, they could be easily cached at edge with a CDN and served right from the cache, which further improved latency.
I had also built and published a theme on their themes page. The MDX files were quite convenient initially, as they’d let me define custom components, such as callout tags, and use them within my posts. I also briefly checked out TanStack Start for my blog with a similar setup.
However, I kept running into the same issue. Writing in an MDX file gives me a ton of customizability, but unfortunately, it’s not the desirable editing experience for me. I’m aware that a lot of folks use this exact workflow and have awesome sites, and even courses that I’ve personally followed, but this didn’t work well enough for my blog.
I then explored a few CMSs, such as Payload CMS, Strapi, etc., but didn’t like the editing experience that much. I had already tried various Git-based CMSs for my existing Astro sites, but maybe I just didn’t prefer the Git flow that much. Especially the coupling, and the fact that I’d use the Git-based CMS, draft the content, then raise a PR and merge it, and even with that workflow not get the ease of using custom components, felt a bit off.
I then stumbled upon Ghost, and I immediately loved it (yeah, again!). It was based on a tech stack I love and had all the writing utilities built in. I’d love to try it out again, but back when I considered it, and probably even now, It didn’t support first-class custom editor components (aka blocks) the way I’d expect from a content-based CMS (though, I heard something similar is on their dev pipeline). Basically, I intend to create various custom components, and those custom components should be easily usable within my content flow.
Finally, I moved the entire site to WordPress, running on a custom-made block theme. It’s stable and has a huge community, which means many useful plugins. Of all the development options for a custom theme I’ve considered, developing a WP block theme is much more standardized and straightforward, which makes it easier for a lot of folks.
I’ve heard a few arguments saying a WP site is slow, but I don’t believe that’s necessarily the case. It’s plenty fast by default with a handpicked, usage-driven plugin selection. I’ve also heard that hosting a WP site is expensive. While that may be true for managed hosting, self-hosting is quite trivial to set up and is cost effective. This site runs on a ~5 EUR VPS (and I rarely go beyond 30% resource usage). Although the traffic on this site isn’t much, even on a high-traffic site, with proper caching, the traffic can still be served efficiently.
More importantly, it has a very good editing experience and support for custom components, or blocks as they’re called here. I’m not saying it’s the fastest way to serve web pages, has the best developer or editorial experience, gets a perfect Lighthouse score every time, uses the least system resources, or runs like butter wherever you deploy it. It maybe doesn’t. But it strikes a really good balance between usability and flexibility.
I plan to use WP and see if I still make excuses in the future for not publishing on the blog. Even so, I’m sure they wouldn’t be due to friction in publishing.
Happy blogging!
Leave a Reply