It's been quite some time since the first version of this blog, so I finally decided to review the few phases it went through and how they reflected my perception of web development over the years.

In a way, I could say that my first blog was a notebook I carried around, where I wrote about school and life in general, but there is no need to go that far. Since this is a technical post, I'll focus on the stacks I used or considered throughout the years.

v0 | Google Sites 🙈

Yes, the very first version of my blog used Google Sites. Of course, it is no longer published, but I still have the project saved, and looking back at it after all these years feels... funny.

This was back in 2014/2015, and at that time, I had practically zero knowledge about web development, so my options were limited to the website builders available then (I considered Wix as well). The tool was still called Classic Google Sites and was migrated to the New Google Sites in 2016.

Nowadays, Google Sites offers free domains (something like sites.google.com/[blog-name]) and, in my opinion, it remains a good free option for non-technical blog owners. There are examples of pretty cool websites out there built with Google Sites, like this Illustrator portfolio by Joshua Pomeroy.

v1 | Jekyll + GitHub Pages

This was back in 2016 when I started exploring Static Site Generators since I had begun working as a web developer.

At that time, I was also dabbling with Ruby because the company I worked for was primarily a Ruby on Rails consulting agency. Because of that, I decided to combine those two (as Jekyll is a Ruby-based tool).

Jekyll is a Ruby gem that provides a command-line interface to quickly bootstrap and serve a project. Creating a blog is as easy as running jekyll new myblog. While knowing Ruby isn't a hard requirement for building a project with Jekyll, being familiar with the language makes it easier to improve or maintain your project.

Additionally, Jekyll, like every static site generator, bundles all your code and project content into static assets that can be served through a hosting service.

Jekyll has built-in support for GitHub Pages, a free static website hosting service. This means you can deploy your project simply by setting up a GitHub repository with a Jekyll configuration file and your content as Markdown or HTML files.

The diagram below depicts the flow in which Jekyll works both locally and on GitHub Pages to build and serve your project files.

I remember that one significant drawback I encountered with this version was that for new blog posts or simply fixing a typo, I had to rebuild and redeploy the project since everything was static. Because of that, I knew I would eventually have to look for a stack that would allow me to separate the blog content from the source code.

It's worth mentioning that there are a lot of community-maintained templates available. I was using one of them, but over time, it felt like there were styles or features I didn't really like or need, and I increasingly felt the urge to start fresh with self-made minimal styling.

v2 | Gatsby + Netlify

Later in 2019, as I focused more on JavaScript only, I decided to migrate some of my projects to JavaScript/React. This blog was one of those projects.

Gatsby was released in 2015 and by 2019, it had gained a lot of attention. At that point, there was already a good level of integration with other tools and platforms. Based on the quick research I did at the time, Gatsby was one of the top options.

The goal was to migrate to Gatsby while minimizing the work needed to update the blog content to adapt to the new stack. Since Gatsby also stores posts as Markdown, it was relatively easy to migrate from Jekyll.

Because I kept working with Markdown files for the blog content and those files lived within the same repo as the website code, this version retained the drawback of the previous one: having to rebuild the website after every change. Though the plan was to eventually migrate the content to a Headless CMS.

Gatsby is also powered by React and has a data layer that makes your content available to React components via a GraphQL API. Your project's content can also reside outside of Markdown files while still utilizing the same data layer.

I also wanted to move away from GitHub Pages and use a more robust hosting service that would provide additional features in case I needed to implement something more complex for the blog. Thus, I chose Netlify, which offers a generous free plan with unlimited websites, custom domains, and Deployment Previews.

Below is a diagram illustrating the setup I had with Gatsby and Netlify.

v3 | Remix + Hygraph + Netlify (current)

After working with Gatsby for a few years, I reached a point where I wanted to optimize my workflow further and use modern tools to customize the development experience and website performance.

Enter Remix, a relatively new framework built to deliver fast, dynamic web applications based on core web standards. Remix prioritizes user experience by focusing on fast page loads, efficient data loading, and server-rendered content.

Remix is opinionated regarding certain things, such as data loading and caching practices, which can reduce decision fatigue and guide developers toward performance best practices. The built-in error handling is very handy, allowing you to delegate the effort to make your app more error-prone and instead focus on important features.

Hygraph is a headless CMS that is essential to this new tech stack, allowing me to manage and publish content without needing to redeploy the website. Its interface is very user-friendly, enabling you to create schemas, manage assets, and link your project with tools like Netlify for automating the publishing of new content, especially when dealing with static content that requires building.

The greatest thing with this stack? All these tools have rich documentation, which also covers how to use them together:

• Remix on Netlify
• Remix + Hygraph
• Connect Hygraph to Netlify

The following graph depicts a simple workflow for this stack, where you can connect your project to Hygraph to query content for both static and dynamic pages.

This stack is the one I feel most at ease with, as it effectively addresses the key issues I've faced over the years. The best aspect is that I can utilize this stack on a free plan for each of the tools for my project. The only expense I incur is for the domain hosted by GoDaddy, which costs me approximately €20 per year.

The code for this blog is publicly available on Github.