my Overpowered website
February 29, 2016


This weekend I rewrote my entire website from scratch. For the past year or so, I have been using Jekyll to generate static pages, and then hosting those pages as a static site via an Amazon S3 Bucket. This worked fairly well. Jekyll transforms Markdown to HTML, and also allows you to write inline HTML, so if I wanted to put anything 'webby' in my blogs (e.g. an iframe, colors, a decorated modal), I could just write it into a standard page using HTML. I'm not invested in or excited by Jekyll, so I didn't bother to read up too much on its ins and outs: I just ran it in the command line, and dumped the static files to my bucket.

As I am becoming more interested in Go, I decided to switch my site to Hugo, a static engine that seems faster and more flexible, in comparison with Jekyll. As I started playing around with it, I realised that I wanted my front end in React. I've been using the front end framework for virtually all my projects these days, because it is compatible with declarative JavaScript, and works nicely in tandem with the wild and revolutionary Redux, in which I adore programming, for more complex projects.

I started playing around with the React static boilerplate on Yeoman, and quickly came up with a fast-moving simple site. Wanting to make as many of my React components stateless and functional, I started factoring text and other content, and decided to switch to my react | redux boiler, because I'm familiar with the code1. I sometimes use Redux state management even in simple sites, as it just makes state management easy; if I want a rotating gear at the bottom of the screen that animates between page turns and displays info, the Redux store keeps track of everything, and I just dispatch actions when I want it to update2.

Because my site is in part a blog, I need visitors to be able to enter it from more than one URL path (e.g., www.lachlankermode.com/blog/history-falling-apart, www.lachlankermode.com/resume), which I can't do with a client-hosted React site, as routing is handled via client-side JavaScript, not by a folder directory that just serves the file at the appropriate route when requested. So I added server-side rendering to the project, to preload the relevant state given the nature of the visitor's request on the server, and then serve to the client the appropriate JavaScript. The example setup I worked with asychronously fetches data and flushes it into the redux state before serving files to the client, and given I'll potentially want to load data from separate asynchronous sources into my site in the future, I decided to take the extra half hour and set up my site with that capability as well. I rewrote my blogs and static pages as JSON, and switched to loading them asynchronously into Redux state via an Express API.

To host my server, I created an Docker image3 from the mhart/alpine-node base image (thinner than the official Node image), and pushed it to Docker Hub. Amazon's Elastic Beanstalk is an easy way to run Docker containers from images that exist in the Docker Hub repo4. Additionally, my domain's nameservers were already pointed to my AWS account through Route 53, because I had previously been hosting my site through an Amazon S3 bucket, so it was a breeze to direct traffic at lachlankermode.com to my new Elastic Beanstalk container (update: am now hosting through Digital Ocean).

After the weekend's work, I am out the other side with a speedy new site, and an undocumented, scatterbrained React | Redux blog engine that has no test suite. When I was foraying into web development two years ago at my regular cafe in Princeton, NJ, I resolved to write my entire site from scratch as a pedagogical exercise. Two years later, at the wooden table in my apartment where I live with Italian male nurses, I have completed my project -- sort of.

Here's the start of my site's long to-do list:

  • Sort out dev environment; it's a mess.
  • Comment code.
  • Write a test suite.
  • Remedy hacks that are all over the place.
  • Refactor React components to make more sense
  • Allow for interactive resume editing (halfway there)
  • Code an admin site, with blog editor.
  • interactive archive!

On my old site, I mentioned that I was working on a interactive, personal archive. This upgrade is moving towards that realization. The data for the archive will be stored via the Express API, and it will be displayed via a section of the current site.

I'm not specifically planning to make this blog engine into a platform, although if it advances far enough, I might consider it in the future (because everyone wants a React | Redux blog for their personal site, right?). Hit me up on Twitter @lachlankermode or via email if you have questions or comments.

breeze and be well.


  1. Another great thing about React is that it's wild easy to migrate components and even entire sections of projects to other projects, especially if you're abiding by functional paradigms. Later on in this narrative, I literally drag-and-dropped some an over-powered resume component I wrote about a week ago into the site, did a tiny bit of configuration to connect the disparate redux reducers, and I was good to go. This would be even easier if I had written the above-stated resume component as an npm module, or added one more layer of abstraction at the top level.

  2. I'm not going to dive into Redux here. Read the docs if you're interested, they are sublime.

  3. Seriously check Docker out if you don't know about it, it's incredible. Here's a good article to get started.

  4. and they also have their own Docker repo, Amazon EC2 Container Service. I thought about hosting my container through the newly birthed dockercloud, the progeny of the soon-to-be-late Tutum, but found its infrastructure to be too comprehensive and complicated for my needs. I just wanted a single container, from a single image, with no volumes or networks or other complexities.

author Lachlan Kermode

Written by Lachlan Kermode who lives and works in Princeton. You should check out his Resume, GitHub, or Twitter.