genehenson.com
← Back to blog

Build a Blog: Part 1 - The Stack

©genehenson6 Feb 20214 minute read

Before I can actually build a blog, I need to figure out what the tech stack is going to be. We are blessed (or cursed!) to have a multitude of options for our stacks today. I'm pretty excited about it and plan to use some new things.

I'll break this into a few parts. We'll need to figure out our options for:

  • Framework
  • CMS
  • Hosting
  • Other stuff

Let's just take it one step at a time.

The Framework

Man, there's so much to choose from here. You've got regular old html/css/js, PHP, React, Vue - the list goes on and on. I had a few things in mind that helped narrow it down:

  • I wanted to serve static HTML files. It seems like the best option for a blog and I just like idea.
  • I wanted a framework to make building faster. Although anything can be done from scratch, after waiting 10 years to get started, I didn't really want to waste a bunch of time reinventing the wheel.
  • I wanted to be able to add some "app-ish" functionality in the future. Not sure what, but I wanted to have the option.
  • I wanted to serve images responsively and in the best format for the users device

So this really narrowed my choice down to a few options:

Statamic

I really like Statamic. As soon as I went to their website, I was in love. It's the first time that I've genuinely enjoyed reading a website in a long time. The thing I like about it the most is the CMS. It's amazingly customizable and the UX experience for content creators is top-notch. It uses PHP/Laravel under the hood to serve websites, but it can also be used as a headless CMS through a very well designed API.

Ultimately, the reason I didn't go with it is that I eventually decided to go another route on the CMS side. I am quite certain that I'll use it for some client projects down the road.

React | VueJS

Some people will hate me for it, but I'm lumping Vue and React into the same category because their capabilities are so similar, even when their approaches differ. I've used and honestly like them both.

When left to my own devices, I probably use React a bit more mainly because of the extensive community. Since we want to serve static pages, and I don't want to develop my own static site generator, I'll need to add something on top.

NextJS

I've used NextJS for a previous project and I liked it a lot. It's lightning fast and generally easy to use, although it has it quirks like any framework. The issue with Next is dealing with images. They have recently come out with their own image component that resizes and serves images, but it's missing a few of the features that Gatsby has.

I am sure that it will catch up to Gatsby in no time, but it's not quite there yet. (Although it does have the advantage of sizing images on the fly and caching them as users request them. This prevents some of the problems with Gatsby Image when images come from a third-party CMS - more on this later.)

GatsbyJS

I haven't really used Gatsby for anything beyond simple Hello-World applications, and I was keen to check it out more. There are two things that I really like about Gatsby over NextJS:

  1. Gatsby Image is really great. Although there are other services like Cloudinary that you can add on to any service, I really like that Gatsby Image just works out of the box.
  2. All data-sources are available through a unified GraphQL api. Some people see that a weakness, but I think it's a strength. There are plugins available for most major CMS platforms and it's actually really easy to create a custom one if you've got something special going on.

That was enough for me to go with Gatsby on this one. I may or may not regret that choice later on, but for now I'm really looking forward to getting started with it.

CMS

Ok, on to the next challenge. Every blog needs to get content from somewhere. Our options here, while offered by many services, boil down to a just few basic options:

  • Traditional CMS: Wordpress, Drupal, etc.
  • Headless CMS: Strapi, Sanity, etc.
  • Flat-file CMS: Statamic, Grav, etc.
  • Markdown

I actually tried a couple options from each category. I won't go into all the details here because comparing the merits of CMSs is a topic in it's own right. I will say that they all have their benefits and drawbacks, but I hit a major hurdle with each of them.

Since they all serve images from their own databases/apis, Gatsby doesn't have a chance to run those images through it's pipeline and they can't be used with Gatsby image. Almost every example that you see on the internet skips over this fact and just dangerously sets inner_html with whatever the CMS serves, losing all the benefits of Gatsby image.

You can work around this problem by parsing whatever is returned from the CMS and dealing with it, but I just didn't want to go down that route for now. So I decided to just go with Markdown. Gatsby has great support for it and it'll catch and process all of your images. It's not going to win any points for elegance or complexity, but it gets the job done for now.

Hosting

It seems like there are new hosting companies popping up every week. There are way, way too many options to even try to talk about here.

I knew I wanted something that I could easily hook into my build pipeline to deploy whenever I make changes (especially since I'll be committing markdown for every new post.) I was planning to just go with Netlify until Scott Tolinski from SyntaxFM talked about using Render for his new site.

I decided to check it out and was quite impressed. It also offer GitHub integration to hook into your build pipeline, plus you an host static websites for free forever. It doesn't have all the bells and whistles that Netlify does, but it has enough to suite my needs.

Other stuff

I'm not totally sure what else I'll need down the road because I don't know where I'm headed with this thing yet, so I guess I'll just update this thing whenever the time comes.

Share this

You think I got something wrong or missed the point entirely? You're probably right. Hit me up on Twitter and let me know.