Back to posts

Making this site

What better way to kick off a new blog than by writing about how the blog was made?

At its core, this site is a collection of text-based documents, some of which are standalone, others, like the current page, form part of a blog.

So what were my options?

Rails?

I considered building the site in Ruby on Rails, since I’m so familiar with it. As a full-stack framework, the allure was that I could do almost anything I wanted with it, perhaps make the site more than a blog.

I checked out some blogging gems for Rails, but for various reasons, I couldn’t really get on board with what I found. Ultimately, it didn’t seem like blogging engines had been a big focus of the Rails community. On the other hand, I also didn’t want to re-invent the wheel.

Wordpress?

If my site is a blog, couldn’t I just use Wordpress? Great things have been done with Wordpress.

I considered this to be a pragmatic option. But, for a personal project, I felt like I wanted to choose something a bit more developer focused.

React etc.?

I find tools like React interesting. The goal of these tools is to enable the developer to both write their UI in a declarative way, and to bridge the gap between authoring the initial render and subsequent interactions.

These tools typically construct the HTML of a webpage from scratch as a function of some JavaScript running on the client side. If you are following along, there has of course been some realisation that this is somewhat bad, and part of the work at least is being shifted back to the server. Though at least with React, it’s at the expense of even more complexity.

There are sweet spots for making good use of these types of tools, however, in my opinion, building a blog isn’t one of them.

HTML

While one could write plain HTML & CSS (and some sprinkles of JavaScript), I enjoy the convenience static site generators bring to the development process. Things like asset bundling, partials, templating, and built-in Markdown blogging.

I tried and liked Eleventy in the past. When I tried it again, I found it wasn’t really ready out of the box, and I didn’t want to get sidetracked with configuration.

I tried Hugo for the first time, but something didn’t gel. I was spending too much time in the documentation, unsuccessfully looking for things that I felt should have been obvious to me. I’ve heard the exact opposite expressed, so that may just be on me.

Jekyll, which I’ve built client sites with in the past, doesn’t seem to have kept up with the times, sadly. GitHub pages doesn’t seem interested in supporting newer versions of Jekyll.

Bridgetown

When I first came across Bridgetown a while back, its purpose wasn’t immediately obvious. Wasn’t the market already saturated with static site generators? It’s written in Ruby, which is interesting to me, perhaps not so much to the general public, I thought.

When I decided to take another look, the Bridgetown webiste promised me three things:

  • Sass would already be installed, and ready to use
  • Webpack would already be installed, and pre-configured
  • I’d be able to start blogging, immediately

So I started it up, and true to its word, everything was ready to go.

Bridgetown just got out of the way and let me work. There was nothing I needed to configure, but as I dug deeper into the docs, I saw that I could switch the templating engine to ERB — a dream come true for people who like using Ruby.

To complete my ideal development environment, I added Gorko to my Sass pipeline, for design tokens. Turbo to enhance the navigation experience, and Stimulus for JavaScript, in case I ever need to write any.

Deployment

This site is hosted as a static site on Amazon S3, behind a CloudFront distribution. I’ve not set up automatic deploys or a build pipeline yet.

Styles

I’ll be writing a separate post about how I styled this site, in terms of how I approached and landed on the design, with tools and techniques I applied in order to achieve it.

I’ll add the link to that here once it’s ready!

Closing thoughts

When working on a personal project, without the constraints or specific needs of a business, use whatever tools and approach suit you best — if it works, it’s right!