From 62c3f15896de03bb9000916278c04e8332acd9f0 Mon Sep 17 00:00:00 2001 From: Danila Fedorin Date: Mon, 5 Aug 2019 01:54:42 -0700 Subject: [PATCH] Add static website post --- content/blog/static_site.md | 58 +++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 content/blog/static_site.md diff --git a/content/blog/static_site.md b/content/blog/static_site.md new file mode 100644 index 0000000..aea425b --- /dev/null +++ b/content/blog/static_site.md @@ -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.