TechWorkRamblings

by Mike Kalvas

Revamping My Blog

A New Coat of Paint

You may have noticed that the blog got a new look and feel recently. The changes weren't purely cosmetic though. Let's take a look at how I migrated from a Bootstrap and PHP based blog to React, Next.js, and Styled Components.

#blog #tech

Fat marker sketches of new blog page designs

Motivation

It's probably not a surprise to most people that I'd want to switch from a PHP based blog to something a little more modern, but honestly — and perhaps controversially — I think PHP is still an amazing solution for simple use cases like mine. No, the shininess of tech isn't a good enough reason on its own for me to rebuild the blog from the ground up. So what reasons were there for updating things and switching tech?

Criteria

  1. Ease of Maintenance — My blog was running like a dream for years on a crazy simple setup, so any solution that I went with was going to have to at least match it in terms of maintenance effort.
  2. Ease of Writing — There was quite a bit to be desired in the old setup. I was using a rich text editor that was hard to get well formed rich text data out of. It was also really difficult to use on mobile. Wanting to use a simpler format (like markdown files) and the ability to use a plain text editor was a big reason to make a switch.
  3. Performance — My old setup was slow for a host of reasons. I was running PHP and MySQL on the same old machine sitting underneath my printer. The thing was ancient when I acquired it longer ago than I care to admit. It would be nice if I could take advantage of something out there that did lightning fast static site edge cached delivery.
  4. Cost — This blog is something I do for enjoyment. I've dropped and picked up this project many times over the years, and I don't want the cost of running the thing to come in the way of my ability to leave it online even when I'm in a period of not working on it.

Candidates

Now that I had some criteria to make a decision on, I set out to see how the different options stacked up.

Don't Rewrite

This is always worth considering. One option is to simply not do a rewrite. Maybe there's some cleanup, upgrades, or new features that we could do in situ that would solve our problems. It's important to think carefully about the built up work and effort that you're throwing away when choosing to rewrite.

In this case, the reasons I started this project to begin with were enough for me to realize that in-place upgrades weren't going to cut it. I also wanted to use this as an opportunity to work on a new tech stack and hack on something fun in my spare time. So even though most rewrites are a mistake, for personal projects we can get away with a lot more latitude when it comes to doing things just because I feel like it.

Custom React and/or Headless CMS Stuff

One avenue I explored was using a headless CMS. These are content management systems that aren't coupled to a UI. Imagine Wordpress, but only the admin section. From there you'd have to build some sort of front-end that would call the CMS's API and get structured content data out of it, render it (either statically during a build or dynamically once hosted), and deploy that site somewhere.

One downside is that these are almost never free and the ones that are free are either restricted free tier plans or self-hosted open source stuff. Since I wanted to reduce complexity and cost with this project, I thought hosting or paying for more tools was out.

Performance is also an issue. Network calls for dynamic content are always slower than static HTML and CSS. You could obviously get around this by doing an SSG build when new content is available, but again, this ends up being more complicated than my old setup.

Ease of maintenance is almost there and depending on the tool, ease of writing could be true. Neither of these are an obvious win though.

No, unfortunately I don't have that much time to hack on these things to begin with, so this option didn't feel right. I realized I was going to have to look at some things that give me developer experience and end product wins right out of the box.

Gatsby

One of the most popular static site generators out there is Gatsby. In addition to a thriving community and ecosystem, it comes with a lot of great built-in optimizations and first-party plugins.

It hits the cost, performance, and ease of writing right on the head. The only concern is ease of maintenance. The framework itself is great, but I'd also have to figure out where to deploy and host things. Would I use my home servers, VPS, some cloud platform? Not a huge hurdle, but worth thinking about.

Another downside of Gatsby for me is just how much there is to it. The huge amount of power and customization cuts backwards as being overkill and a bit finicky. Think about how webpack configs are powerful but not fun to deal with all the time. I'd prefer if it had more simple, sensible defaults with escape hatches if needed.

Next JS

This gets us to the actual solution I picked: Next.js. It's all the goodness of Gatsby with less configuration but retaining escape hatches if needed. It has first in class DX, crazy fast optimizations, and a first-party, free, single digit ms latency hosting service through vercel. I get to use React and get a hybrid static/server/client site generated from it automatically with the option to get more fine-grained over time if I'm interested.

So that's what it's built on now. I hope you can tell that behind the nice new design it's faster and more responsive too.

Design

Speaking of the new design, I had a ton of fun playing with different options. One of the best parts about it was using some tools to do low-fi sketches of possible layouts. Here's the sketch for the new layout that I actually went with.

Fat marker sketches of new blog page designs

I want to do mockups like these more often while working on projects. It's a quick, low-cost way to iterate on ideas and get a feeling for what the finished product could be without having to do full POCs in real code.


Update 2021-08-01: This sketch is a little inaccurate after unifying my projects. The old blog nav got subsumed into the wider site navigation and the search got moved to the home page and searches everything now. There's just the /blog endpoint with the full list of posts and the /blog/[slug] endpoints for specific posts.