Working on a side project, I encountered some technical problems that would make for interesting blog posts. I wrote them, but didn’t want to publish on my website as it looked and felt outdated to me.
I built it in 2019, and it didn’t change much since then. A makeover was long overdue.
The framework rabbit hole
The previous iteration of my website used Gatsby, but the blog itself relied on an external theme that wasn’t maintained anymore. This time, I wanted control over my blog platform.
In an attempt to ship without delaying my side project, I spun up a repo based on my twin-macro-next-boilerplate template. I knew that comparing all different frameworks would be a waste of time, so I went with what I use most frequently.
But something felt off.
I like building web apps with Next.js due to its flexibility, but for a static blog, it’s not ideal.
Filesystem routing with Markdown files isn’t that great if you want a different structure in the repo than on the blog. The alternative would be to use the Next.js data fetching functions to parse Markdown manually and generate slugs, which isn’t a big deal, but again, not ideal.
What about using astro instead, a fairly new static site generator (SSG) which promises “peak performance”?
I seriously considered it until I generated the blog starter. I was faced with the prospect of learning yet another framework, and either starting from scratch or customizing a bloated starter. And to be fair to other SSGs, there’s no perceptible difference in load times unless you’re on a slow 3G connection.
Not what I was looking for, so I briefly explored using Remix, but felt it was overkill for a simple static site. All I really needed was a Markdown-based blog so I could get back to my side project.
You see where this is going. I fell into the trap I was trying to avoid: analysis paralysis. When all options seem equally good, with different tradeoffs, it can be hard to make a decision.
So what’s the solution?
A familiar ally
A thought remained in the back of my mind as I was exploring all these frameworks: just use Gatsby again. I like its GraphQL data loader, its performance is great, it handles the developer blog scenario well, and most of all: I know how it works.
Here’s a quick rundown of its benefits in case you’re in the same paralysed boat:
Why Gatsby
At first glance, Gatsby can look more limited that other options because of its approach to data loading.
While other frameworks such as Next.js provide a completely flexible loader, Gatsby hands you a large set of lifecycle hooks that allow you to customize its GraphQL-based data loader.
This “limited” architecture is exactly its strength. It enables the community to share plugins, and developers to inspect all available data at any time through the GraphiQL explorer.
Out of the box, Gatsby does a lot for you. The blog starter is easy to understand and customize, and the plugin ecosystem makes adding common and non-trivial functionality easy.
For example, here’s all the code this blog needs for build-time syntax highlighting compatible with VSCode themes:
// under `gatsby-transformer-remark` plugins:
{
resolve: `gatsby-remark-vscode`,
options: {
theme: {
default: 'Eva Light Bold',
dark: 'Eva Dark',
},
extensions: ['Eva-Theme/VSCode', 'vscode-graphql'],
},
},I’d say Gatsby’s good enough.
There’s value in doing R&D and exploring all different options, but sooner or later a decision has to be made. If the end result would be similar with all options, familiarity with a technology should be taken into account.