I recently migrated my blog from WordPress to a framework called Jekyll – a simple, blog-aware static site generator. WordPress certainly has a ton of flexibility and is preferable for client projects, but I gained interest in Jekyll because of it’s “blog like a hacker” approach. In this article, we will take a look at the differences between building for both platforms.

Fundamental Difference

The most important thing to understand when comparing Jekyll to WordPress or other website management tools is that it’s not a CMS. Jekyll needs to be compiled each time you make a change and it generates a new set of files in a local directory called _site. This directory contains static HTML files which can be uploaded to a web server.

This may seem awkward and inefficient to some, but Jekyll was not designed to be a CMS. In fact, it was meant to create a workflow that eliminates the need for a database (which most CMSs rely on) in efforts to build sites that load really fast. Jekyll is not recommended for managing projects with large amounts of content or multiple editors.

Site Settings

Jekyll uses a file called _config.yml to manage site-wide settings. These settings include general options like site title, description and URL as well as custom options like permalink structure and pagination. Here is an example of what your_config.yml file could look like:

title: Matt Litzinger
email: hello@mlitzinger.com
description: ""
url: "http://localhost:4000" 

markdown: kramdown
permalink: articles/:title
paginate: 5

Content

WordPress uses a WYSIWYG editor to format page/post content. Jekyll on the other hand, uses the Markdown syntax to format content in plain text files. Those markdown files are then injected into the template files which we’ll talk about later.

Sometimes you may need to add content that is not classified as a page or post. In WordPress, this is addressed with custom post types, but Jekyll uses something called Collections. You could create a new collection for portfolio by making a folder called _portfolio and adding the following code to the _config.yml file:

collections:
  portfolio:
    output: true
    permalink: /portfolio/:path/

Meta Data

Jekyll uses YAML front matter in place of meta data which is typically stored in a database (e.g. – authors, categories, tags). There are a number of default variables for layout, permalink, published, category and tags. You can also create custom variables for things like title or author. YAML front matter must be added to the top of Jekyll content files. Here is an example of what YAML front matter looks like:

---
layout: post
permalink: /year/month/day/title.html
title: Making the Switching from WordPress to Jekyll
author: Matt Litzinger
---

Templates

Templates are an essential part of any framework. They can help you avoid writing repetitive code and make your site easier to maintain. Jekyll uses Liquid, which is a templating language developed by Shopify. It contains much of the same logic used in PHP when creating templates for WordPress. There are a few syntactical things that were difficult to master, but the documentation is solid and there to help.

Plugins

Jekyll allows you to create custom plugins to add functionality to your site. If you are using GitHub Pages to host your Jekyll site, you will be limited in the number of plugins you can use as Pages sites are generated using --safe option which disables custom plugins. If you’re hosting anywhere else or just uploading the static files to GitHub pages, then this shouldn’t be a problem.

Hosting with GitHub Pages

A distinct advantage to using Jekyll is the ability to host with GitHub Pages. I’ve always been a fan of pushing to a production server through version control instead of FTP. GitHub Pages makes this process easy and automatically compiles your Jekyll project before it’s served up to the user.

Resources

4 Questions To Ask When
Planning Your Website Redesign

A Goal-Oriented Approach To Web Strategy

Matt Litzinger headshot

Matt Litzinger

Matt is a New Hampshire-based web developer focused on UX and digital accessibility.