Much sooner than I expected but here it is at last: the follow-up to my last post about my blog.

The year is 2022, and this is my new blog.

If it wasn't really in the planning, than why did I decide to rebuild this one from scratch, and what am I using to run it?

The why

Both questions are kinda related, but let me start with the "why". Last year I launched my blog to the world with the idea to start writing more. It's been one of my dreams for the last few years, and so I decided that the best moment is now: I'm starting a blog!

So I set out and built a thing, with Ghost as my CMS and Gatsby as headless front-end.

It wasn't long before I noticed that I had some serious doubts about the styling that I choose. The font was pretty "in your face", a decision I initially liked but started to doubt when I saw those big headings on the screen. The coloring also felt "off", and the meta information for the posts were downright bad. I didn't have a clear vision to style it so I just put some information in a box.

I was equally dissapointed about the tech stack. I'd had already worked with Gatsby before, and wanted to try out the headless CMS thing in a blogging context. However, since Gatsby 4 was primarily SSG-based, I used Gatsby Cloud to build a new blog whenever I changed something in Ghost. This gave me a feeling of disconnect between the two systems and I was now bound by a specific build-system, unless I decided to implement the entire "rebuild on database chage" system myself.

So, the pleasure to start blogging went away quickly, and after a year I'd still hadn't written a post for it.

By this time, I was trying some stuff out with Next.js and even more interestingly (to me): Remix. Which brings me to the next question.

The what

This blog is still using Ghost as a CMS, because 1) they released version 5 which looked very interesting, and 2) I'd always liked the concept. I was following the development of it since version 1. And while I looked at some other ways to build a blog, Ghost always came out on top.

The front-end is still headless, because I usually refrain from building themes. It's mostly a lot of work and it feels a bit constrained at times; I like the freedom of building the entire front-end myself. Even if it's a lot of work.

There's a lot being said about how Remix works, why it's a pleasure to work with and how it differentiates with Next.js. I'll write up something soon from my end as well. For now it suffices to say that I really wanted to use Remix to build the headless front-end for my blog with.

It already fixes the main problem I had with my previous set-up: it bound me to Gatsby Cloud. Right now, the front-end is running on and being built with the DigitalOcean App Platform. I choose a simple NodeJS server with the smallest, $5 a month plan. It's connected to the GitHub repo containing the Remix app so whenever I push to main, a new build is being run and deployed to production.

Simple.

But the best part is, should I every want to move a way from DigitalOcean, I can simply replicate this set-up somewhere else. Most DO-like hosting providers have something similar like the App Platform, and can do a build-and-deploy when pushing to a certain branch. AWS, Fly.io and Vercel already come to mind.

And it's not just that I don't have vendor lock-in, the concept of how this all works is simple to me.

Remixing Gatsby

So why Remix instead of Gatsby? The first reason is that I really like the benefits that Remix (or Next.js for that matter) bring over something like Gatsby, which, in version 4, was a primarily static site. Having a dedicated back-end running may increase project complexity, it decreases app complexity. I can move over expensive computation to the server. Remix's server-side rendering approach mean that a page for a post is being rendered on the fly, which is simpler than SSG and also means no downtime when a re-deploy is happening just beause I fixed a typo.

Remix is also fast. As in extremely fast. Building a site correctly in Remix means that there's not a lot of stuff that has to render on the client. Couple that with the very powerful server and all its benefits and you have a powerhouse. Take for instance the dark mode on my site: the setting is contained in a cookie (only when you click it), every page reads the preference from that cookie in a request and sets the interface color. The actual changing part is nothing more than an HTTP request.

In short, I like the approach of a full-featured front-end framework (try saying that 10 times) for something "as simple" as a blog.

So, this means that I want to start blogging more!