A Spark of Creativity

I decided to play around with a new concept for my site a few weeks ago, out of boredom and anxiety about the whole world being on fire and needing a distraction. I started how I always start a personal project: playing with color schemes and Tailwind. This time around, the playtime also included TinaCMS and Gatsby. I wanted to investigate TinaCMS as an alternative to some of the heavier content management systems I’ve seen folks recommend in the past, and wanted to see how it fared on a personal site. It eventually evolved into the beginnings of my new site, what you see before you now.

After I realized I was, in fact, rebuilding my site, I decided I had to address some things. When I build my old site, I thought at the time that it was visually appealing, but it was more difficult to maintain than I originally anticipated. Some of the features I was looking for in my new site:

• Easy-ish to enter and maintain content.
• Relatively easy maintenance of the codebase.
• A visually appealing, refreshed look.

The Old: GraphCMS + GatsbyJS + Github Pages

I wrote the old site on top of Gatsby 1.x with GraphCMS as the source. At the time, I wanted to have GraphCMS trigger a new build on Github pages whenever I made a new edit. However, at the time Webhooks were a pro feature and I’d be paying $25/month for GraphCMS alone. (As of the writing of this entry, it appears that as of last month that is no longer the case.) GraphCMS was also fairly new at the time and what I built my old site on is now considered their legacy software. It was fun to play with, but it was all custom written and may have taken a lot of time to migrate.

As for hosting, I was deploying and hosting the old site on Github Pages. The old process was:

1. Write a blog entry on GraphCMS.
2. Mark it as published. (This was a boolean field that I created because I usually like to test out drafts and I planned on writing preview functionality with the webhooks.)
3. Go to my local copy of my Github repository, run npm run dev, to make sure it was pulling the new entry.
4. Run npm run deploy to actually run a production build and commit that built code to the gh-pages branch.

I grew tired of this process pretty quickly, as evidenced by the lack of content on the old site. (If you think this process might work for you, go for it! Gatsby has official documentation on this process.)

The Prospect: TinaCMS + GatsbyJS + Netlify

I’ve been hearing amazing things about Netlify for the last couple of years. Their free tier offers ample build time limits and bandwidth for personal sites and deploying from Github is a breeze. The best part: I can stop paying for the shared hosting I had purchased a year of from Namecheap last August. Moving my site there was a no-brainer.

Additionally, I decided that the source plugin for my site should be markdown stored in the repository for ease of migration later on if necessary. I’ve been using static site generators for my website for a while, so Gatsby was also a favorite choice from the beginning.

WTH is GatsbyJS?

GatsbyJS is a static site generator written on top of React, and as a result, allows you to write React syntax and components. This means that I’m only using the automation of React to create my components, then use them to keep my site consistent and my code DRY. Static HTML is rendered upon build and React is not actually run on the client side.

WTH is TinaCMS?

I hadn’t heard much at all about TinaCMS until earlier this year. It’s a library that gives users an interface on the actual website’s front end to edit content on a GatsbyJS or Next.js site, either in the form of a slide out form or with inline editing.

Getting Started on the New Site…

I started from scratch with this iteration, but reached for an old favorite: The Gatsby Blog Starter. With Tailwind, I was off and running and had a basic page layout concept styled within a couple of hours. I played around a bit with TinaCMS and liked being able to interact with my blog posts in the browser. Progress! I ended up launching that same weekend and sent a message out on Twitter, to the accolades of friends. I also made sure to note that it was still very much a work in progress. Smooth.

The Features

My favorite features of this new site are the light switch in the top right corner and the 404 page.

I originally forked the Gatsby dark mode plugin, but after a week or so ditched my custom code for the actual plugin. (Why write your own copy if a plugin exists and does basically the same thing?) The way this plug-in works is, when you visit my website, it detects your device’s settings regarding light or dark mode and changes the look of the site based on that. However, if you decide to change it manually using the light switch, it stores the new mode in your browser’s local storage. This is just about the coolest thing I’ve done for one of my own websites. This and the mobile menu are the only client-side JavaScript on this site.

As for the 404 page, you’re technically not supposed to see that, but I’m super proud of it. It reinforces my love of computing history with a tribute to Admiral Grace Hopper and how she and her team coined the term “bug” with respect to software development.

The Issues

I discovered a week or so after launching this on GatsbyJS + TinaCMS that the performance of the site was scoring well below what I expected of a Gatsby site. I kept thinking, “I’m serving static HTML! This shouldn’t be taking so long to load.” I investigated the photo and SVG assets and both were minified as much as possible and had appropriate cache headers. I double checked that Tailwind CSS was purging all but the necessary CSS rules (it was).

I also noticed that disabling JavaScript in my browser prevented the whole site from loading, which I hadn’t experienced working with GatsbyJS before. I also noticed that there was way more JavaScript running than should have been on Production. I know I didn’t write that much client-side JavaScript; even though I built everything out in React components, the JSX gets parsed on build, not runtime. Then it clicked: The delta was TinaCMS. I opened a few minified JS files and sure enough, TinaCMS was running—but visually hidden—on the production site.

I investigated a few avenues and even time-boxed a couple of hours to see if I could prevent it from loading on production. It had so many moving parts for me to have to conditionally add that I ultimately decided it would be a net loss for me. I took it out of the site that same day and saw immediate improvement. Performance improved significantly and the site was rendering at least the text content with JavaScript disabled.

Aside: My ISP tries to block the TinaCMS website, citing malicious activity. 😬

The New Process (For Now)

1. Work on content locally while running npm run start. I watch the page update as I make changes.
2. Commit the new content directly to my Github repository on a separate branch.
3. When I’m done working on content, I create a pull request and review that the content built to my expectation on Netlify.
4. If I’m satisfied with the preview, I merge the new work into the main branch.

Alternate Process: Github as a CMS

One other possible process I can try is using the new Github IDE to create entries, which I don’t think existed when I built my old site. The goal here would be to set up a drafts branch, write entries through Github’s UI and tell Netlify to automatically deploy that branch to a test environment for review.

Action Items

• Investigate NetlifyCMS + Gatsby.
• Investigate GraphCMS (now with a free tier that offers webhooks!) + Gatsby + Netlify.
• Follow up in a new entry about both of those approaches as well as the aforementioned alternate process.

Was it Successful?

Since I only wrote a tiny blog post on launch—and am just now getting around to writing again—this remains to be seen. Like I mentioned in that post nearly a month ago, I hope I can keep this up. I’m very impressed with Netlify and, while I decided not to use TinaCMS, I’m hopeful that I’ve made it easy enough. Regardless of whether or not I’m using a CMS, maintenance is already 10x easier with Tailwind and leaving the build process up to Netlify. I’m still excited about the prospect of keeping this updated, but I might still look into other ways to make this even easier.