Programming a blog you'll learn this (pirobits v3)

I’ve always enjoyed using my blog as a side project to experiment with different technologies, explore ideas, and share my learnings as I build products and tools as a software engineer. Now, it’s time to roll out a new version.

My blog (pirobits) has gone through various stages: first, I started with static files served via AWS S3, then I moved to EC2, tried static site generators like Hugo, and finally ended up using Next.js to learn about React Server Components and host an API on a VPS.

Each stage has had its pros and cons, which I’ll analyze in depth later on, but they’ve allowed me to enjoy the learning process. In the end, the evolution of any product (or company) is usually driven by user or market needs. In my case, the blog evolves according to my needs—whether that’s learning, building a platform to share what I do as a hobby, or both.

At first, with pirobits, I simply wanted to document what I was learning. Later, I wanted an API to start a newsletter and add some interactivity to the blog... And now, knowing the pros and cons of each option, I want to build a product with technologies I know well, that’s simple in design, allows easy functionality additions, and has automated processes to optimize my time.

As I always say, I enjoy building things just for the fun and learning experience, and I want this to be my own product where I can play and experiment. Lots of new features are coming in the next few weeks, so make sure to subscribe to the newsletter.

First Version: Static Files

In the first version, I just wanted to write about what I was learning and building, so the simplest option was to try a static site generator. Here, I experimented with rendering the content myself, but there were quite a few details to consider, so the best option was to use a static site generator. I tested Hugo, which is developed in Go, has a large community, and is very comprehensive.

To serve the static files, I explored serverless cloud options, where I found some areas were still a bit underdeveloped and didn’t quite convince me. Then, I explored storage with AWS S3 and EC2, but due to cost, a VPS instance with NGINX from any other provider was much cheaper. Plus, this allowed me to try out tools for configuring a server remotely.

I considered using a static site generator again, such as Hugo, Zola, or Lume, but right now, I’m not convinced for several reasons:

• I don’t want to rebuild/redeploy after every post.
• I don’t want to maintain another project just for the API.
• Even though I like serverless options, I’m not considering it for certain projects where a $5 VPS works perfectly.

Second Version: Next.js

After working with static files for a while, I wanted to improve both the design of the blog and add some interactivity. I’ve been familiar with React for several years and have worked on my own server-side rendering (SSR) project, so I wanted to explore the benefits of tools like Remix.js or Next.js.

I loved the philosophy of Remix.js, although I realized I had to develop several parts myself. Therefore, I decided to use Next.js to learn about React Server Components. This is a framework I love for the optimizations it brings, how it’s structured... although it also has some issues that I mentioned in another post.

Certainly, if you want to build a product that’s a SPA, Next.js is a very interesting option. In my case, after working with Next.js on this latest version of my blog, I think it wasn’t the best decision since I’m mostly using it to render static content, and due to the tool’s limitations, I’ve spent more time doing workarounds than building the product. However, I’ve built other SPAs with Next.js and React Server Components, and I’m thrilled with the results.

As I always say, the best solution to each problem is always relative, and sometimes you just have to try and fail until you find the best solution.

Third Version: Choosing the Stack

Today, there are thousands of tools we can choose from as a "web framework": from high-level to low-level options. There are also platforms like Medium, Substack, or Ghost (which is open source), that offer everything ready-made, but in my case, they don’t meet my needs. I haven’t explored Astro, which caught my attention, although it seems quite similar to Next.js.

My main issue is that many of the blog processes are manual and not optimal, so I want to automate various tasks that I currently do manually. Moreover, I don’t want to maintain the current base since it has some limitations that prevent me from adding new functionality.

The goal is to create something simple that allows me to render content dynamically, where deployment and publishing are fully automated, so I can focus my time on writing posts efficiently.

So with the third version, I’m going to use the classic option: use a web framework that has a templating system, includes an API, and I’ll implement the functionalities I need. The good thing is that although it requires some initial setup time, it’s then easy to maintain, modify, or expand.

In the next post, I’ll talk about the specific architecture I’m working on and the different challenges it presents. In the end, every option has its pros and cons. Choose the one that’s most comfortable for you, and if you make a mistake, you’ll learn. In most cases, you can change your decision, especially if it’s early in a product that will evolve quickly. So as they say... fail fast.