Add static website post
This commit is contained in:
parent
43a72533f5
commit
62c3f15896
58
content/blog/static_site.md
Normal file
58
content/blog/static_site.md
Normal file
|
@ -0,0 +1,58 @@
|
|||
---
|
||||
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.
|
Loading…
Reference in New Issue
Block a user