SITE NAME CHANGE: Hi there, this is just a quick note to explain why the site name seems to have changed. I've decided that my personal domain of Gecko8 wasn't nearly descriptive enough. I want to cover not just code, but how to make our lives better as developers. With that goal in mind, I feel Life And Code is a better choice. I hope you agree!

This article is part two in an ongoing series on creating this very blog site! It documents the actual frameworks and tools I chose to use and why. Stay tuned for Part 3 which will cover the headless CMS portion of the project!

For Part 1 which covers the planning of the overall project, see Overall goals and decisions

Update: I've recently come across an issue in Nuxt that makes it very difficult to static generate blog post page headers for SEO. Basically the headers generate fine but then queries are still issued when the page is run live. There doesn't seem to be a good solution for this so I'll likely be looking into other options and will update this series as soon as I figure it out.

In the previous post in this series, we talked extensively about the major goals of my personal blog site and the types of decisions that needed to be made to get there. Now it’s time to let you in on what frameworks and tools I’ve chosen to make this thing a reality!

First, let’s just quickly summarize what these overall decisions were:

1. Canned or Custom? The winner, custom of course! I’m a developer, there’s no fun in using something like Wordpress or Medium that were created to someone else’s vision. I want to learn and have the flexibility to add custom pieces as I go along.
2. What Type of Site? A static website fits all my requirements including speed, good for SEO, and flexibility since there’s static systems for all the major frameworks.
3. Blog Content? A headless CMS feels like the best balance between capabilities and getting things up and running quickly. If you’re worried about speed, that’s not an issue as we’ll be pre-rendering the pages with the static framework so the user will never see the delay of contacting the CMS.

Okay, now that we’ve got that out of the way, let’s get to the fun part, figuring out what tools to use!

What Code Framework To Use?

There are several options out there, from the industry behemoth React.js, to the up-and-comer Vue.js. For me this was a pretty easy choice since I’ve been working with Vue a lot recently and have come to really love it.

Why Not React?

React.js

To be honest, I’ve only briefly played with React. I come from an AngularJS background and always loved the cohesiveness of having most of the major tools built in and ready to go. As React is really just a UI framework, there are a lot of decisions to be made and research to do around picking the best tools to support it. Think of React as the lead singer in a rock band, it’s the face of the band but doesn’t mean much without the guitar players, drummers, etc.

Why Not Angular?

Angular

Coming from the AngularJS (1.x) world, Angular 2+ might seem like an obvious choice. But as you may know, Angular 2+ is actually completely different than AngularJS. And like many AngularJS developers, I was frustrated with the Angular team’s decision to abandon everything that was good from AngularJS and start over. So if I was going to be learning a totally new framework, I may as well look at the other options in the industry. This led me to Vue.

Why Vue?

Vue.js

Very quickly after starting to learn Vue.js, I came to the realization that it felt like home. Vue encompasses many of the values I have about what makes a good framework. Here’s a few of the most important:

• Cohesiveness of tools such as UI display, server calls, state management, etc.
• Cleanly structured code (everything in its place)
• Small package size
• Fast

I personally love how structured Vue components are with clearly defined properties and methods for things like lifecycle hooks, computed properties, etc. It makes it very easy for a beginner to get up and running fast and for anyone to quickly understand another developer’s code. This last is really helpful in teams where projects can shift around. Vue’s single-file components also greatly cut down on editor tab clutter, a big pet peeve of mine.

Cost? Free.

What Static Website Framework to Use?

With the decision to use Vue.js out of the way, it’s time to figure out how to handle the static website generation. The two main ones for Vue seem to be Nuxt.js and Vuepress. Both have many strengths and weaknesses.

I’ll be completely honest here, I didn’t do a ton of research on this. When I searched for Vue static site generation, Nuxt.js was the framework that came up by far the most so that’s what I went with. As I was just learning about static site generation, it’s not like I really knew what sort of features would be important to me and what wouldn’t. So one framework seemed as good as the next.

Cost? Free.

What Headless CMS to Use?

This was probably the toughest decision of them all. This is a booming market right now so there are a ton of options out there. Just take a look at this great reference site for them: headlesscms.org. They all have different capabilities, costs, etc. You can host them yourself on your own server or use a 3rd-party hosted one. Heck, Wordpress can even act as a headless CMS!

Hosted or Self-hosted?

There are many choices for self-hosted headless CMS systems but to be honest, I didn’t want to deal with managing a server as well as everything else. Plus, unless you have a serious internet connection or easy access to a company server, hosting your own for free is tough. In my case, I decided to go with a hosted system. This narrowed it down to just a really long list instead of a massive one. Oh well.

Free

This ended up being a great question to narrow down the list. Many of the hosted headless CMS’ don’t have a free option. Many of the free options are really limited and jump in price dramatically once you need more. For example, the first one I looked at was limited to 50 blog posts and jumped to around $40/month after that. It would take me awhile to hit 50 blogs but I definitely would.

Editor Interface

Because a headless CMS doesn’t have an editor GUI that’s built into your site the way something like Wordpress does, you’re at the mercy of the interface provided by the CMS company. Some provide a simple Markdown type interface where your entire blog is written in Markdown. While I love Markdown, it can be a bit limiting. Some systems have more capable interfaces where you can build a document model out of building blocks such as text, images, tables, videos, etc. This can give a lot more flexibility.

Query Interface

This wasn’t a huge deciding factor for me but I found that some of the CMS’ used a GraphQL interface. As GraphQL was something I was curious about, maybe it would be a good opportunity to learn about it.

The Decision? DatoCMS

When I came across DatoCMS it looked too good to be true. A hosted CMS that used GraphQL, allowed editing in simple Markdown or a more advanced model system, and had an extremely generous free plan? Really? And by generous I mean REALLY generous. The language DatoCMS uses is a bit complicated but what it comes down to is I can create 1000 blogs for free before having to pay around $22 Canadian per month. If I hit 1000 blog posts anytime soon, I probably have a team writing them and can probably afford the $22/month.

As an added bonus, I’ve contacted their support a few times to clarify things and they’ve been extremely helpful. And since I’m on the free plan, that’s a rare experience.

Decision made.

Hosting

One item I haven’t discussed yet that can play a big part in the cost of your site is the hosting. I did a bunch of investigation into Microsoft Azure, Amazon AWS, and several others to see what the free options were. The vast majority provided a certain number of free credits over a specific period of time, after which you started having to pay. Then I looked into Netlify. Netlify has a free plan for hosting personal and hobby sites that supports custom domain names, free SSL certificates, and continuous deployment tools. These were all the items I was looking for. And Netlify specializes in static website hosting. AND there’s an integration with DatoCMS that allows me to re-generate my static pages from the DatoCMS interface.

We have a winner! Netlify.

I Think We’re Ready to Get Started

It probably seems like I’ve spent a lot of time talking about what pieces I’m going to use and why. I really wanted to make sure I had all the right tools before I actually started building something. And with any luck, my journey has helped shorten yours.

Don’t worry, in Part 3 we’ll actually start building something! Stay tuned.