Web-Projects
/
blog-static
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Add static website post

This commit is contained in:
Danila Fedorin 2019-08-05 01:54:42 -07:00
parent 43a72533f5
commit 62c3f15896
1 changed files with 58 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

58
content/blog/static_site.md Normal file
View 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.