Blog? Remix? How did it start?

Mar 27, 2022

Since mid-2021, the idea was to create a simple website about my work and the technologies I like.

How to make it? Where to start?

These were questions that always stuck with me. Before that period I had a website made with Gatsby, super simple. Besides being simple, it was ugly. As it was before the pandemic I didn't have much time to maintain.

The site you visit today is not that great work of art, but the idea this time was different: to combine a "semi-portfolio" with content I want to write. Something I've never done before, and yes, it's something I want to start doing more to pass on some kind of knowledge and value.

What were my ideas to get started:

  • Viable web hosting;
  • Take some valuable knowledge during development;
  • Working with technologies that I like.

A few other points appeared later on.

I picked React right away to start with. Something I've really enjoyed tinkering with for a while now and with some framework options to choose from.

The first choice right away was to use Next.js. For the blog, the flow would be very basic: I would make the posts using MDX pages with next-mdx-remote and I would generate them every build.

I finished the development, finished the first post. However, I never got around to releasing it. In the end, a framework that I had my eyes on was announced that it would become open source, Remix.

Read about seed funding for Remix.

Shortly after being announced open source the package was made available on npm. It wasn't the official release version yet, but it was enough for me to be fascinated!

Remix is a framework entirely focused on SSR[1], web fundamentals and modern UX. With a super simple API the learning curve is quite small (taking into account previous knowledge with SSR/SSG[2]/ISR[3] strategies).

The strategy had to change a little. In Next.js I generated posts statically with local files from my repository. As Remix serves everything via SSR, generating posts statically would no longer be possible.

Come to think of it, generating posts during build would pose a problem further down the road: the more posts, the longer it would take to finish doing the build. And also whenever I needed to fix a typo, I would have to build again just for that.

I started to build a solution where I had a route in the Remix application that received the contents of the MDX file and stored it in a Redis.

Finishing the development, I chose to host at Vercel. Unfortunately I ran into a problem: the package responsible for MDX, mdx-bundler, uses a dependency called esbuild. When performing the build on Vercel, the package presented an error with no apparent fix.

I really wanted to use Vercel hosting for the ease of caching and integration. Which made me think again. Why manage a database, deal with all the information if what I really want is to deal with simplicity? That's when I decided to go for a solution using a Headless CMS.

Collected Notes is a CMS that I can write my posts using markdown, but it already gives me basically everything. From title, headline to the content already in HTML to render. The implementation from there was super simple.

Was it overengineering? Maybe, but I really wanted to use it as a learning experience. I learned a lot about Remix, caching, various things about web fundamentals, among many other things related to rendering some types of content.

I'm very happy with the result. For the future I want to improve the site design and post A LOT about Remix.

My conclusion is: there is no definitive way to do something, there is what makes sense to you at a given moment. And technology is not something written in stone, it's something that keeps changing, just like I hope to keep changing this website.


  1. Server Side Rendering. ↩︎

  2. Static Site Generation. ↩︎

  3. Incremental Static Regeneration. ↩︎