59 lines
3.3 KiB
Markdown
59 lines
3.3 KiB
Markdown
---
|
|
title: Switching to a Static Site Generator
|
|
date: 2019-08-05T01:13:58-07:00
|
|
draft: true
|
|
tags: ["Website"]
|
|
---
|
|
A long time ago, I decided to try out Jekyll for my website. However, it all felt too
|
|
convoluted: the ruby gems I needed to install, the configuration options for the site,
|
|
the theming. I was given a template that already made several design decisions for me,
|
|
and I didn't like it. So I wrote my own back end and front end, and was happy with it
|
|
for a few years, periodically updating the look of the site. I even made a post on
|
|
the site, called "Ditching Jekyll", with the glorious contents:
|
|
|
|
> This morning, my guilt finally took over and I ditched the idea of using Jekyll.
|
|
For the better, probably. I sat down to code, and got up several hours later,
|
|
victorious! Thanks to a handy tutorial on Python and Flask written by Miguel
|
|
Grinberg, found here ["here" is not a link], I wrote a bare bones website
|
|
to host my silly blog posts and projects.
|
|
|
|
Recently, however, I started to do a little more writing for the blog. My posts
|
|
grew fairly long, and started to include nontrivial pieces of code, ones
|
|
that I couldn't write and be sure without checking that they worked. Additionally,
|
|
I felt an increasing need for version control. This was all very difficult
|
|
through a custom backend, which doesn't come for free with features such as
|
|
tracking changes and including code snippets. My workflow boiled town to the following:
|
|
|
|
1. Write the skeleton post in a local Markdown file
|
|
2. Write the relevant source code in a proper source file
|
|
3. Copy-paste the new source code into the Markdown post.
|
|
4. Copy-paste the full post into my custom website's input box.
|
|
|
|
There are two steps where parts of a writing project can become out of sync
|
|
with each other! Changing the source code means that you eventually have to
|
|
update the Markdown file with the changes, and modifying the Markdown file
|
|
also means that eventually, you'll have upload the new file to the website.
|
|
It's inefficient, and there's a lot of redundancy.
|
|
|
|
With this in mind, I think there are many advantages for using
|
|
a static site generator for a personal website / blog. They are as follows:
|
|
|
|
1. Content is first class. Your posts are files you can edit in any way you like,
|
|
rather than opaque entities stored in a database. This also has the added benefit
|
|
of allowing you to properly use version control with your posts.
|
|
2. A static site generator can support complex multi-file setups. It took me
|
|
about half an hour to configure my posts to pull code snippets from other
|
|
files on disk, thus freeing me from having to copy-paste source into my posts.
|
|
3. A custom back end is overcomplicating things. You write your own code to render
|
|
posts, your own code to log the user in. This way you're not only spending
|
|
more time than you need, but you're also adding more surface area for possible
|
|
errors and bugs.
|
|
4. A static site generator allows for the re-use of ideas and code. Rather than
|
|
reinventing your own solution for tagging, rendering Markdown, syntax highlighting,
|
|
and the like, you get these solutions out of the box, with a body of online
|
|
questions and answers that have been generated over these very subjects.
|
|
|
|
Having come to this conclusion, I will be switching my website to [Hugo](https://gohugo.io/),
|
|
which seems to be easier to configure and customize, without making too many assumptions
|
|
about what you want in your website.
|