This website

2019-12-01  (Updated 2023-11-05)    5 minute read

So you want to make a website?

Make a text file, put whatever words you want in it ("Hello World!" are some popular first words), and put .html at the end of the filename. Congratulations! You've made a website!

Of course, this lacks many of the features widely considered important for most websites, such as being connected to the world via the internet.

But there are two pieces of advice that I have for any form of self-expression:

  1. Put more things out into the world before they're done. One of the great things about digital media is that it's practically free to "release" something, so do it as often as you can, throughout the process.
  2. You can put as much into a medium as you would like. Even if that amount is practically nothing.

Tools I've used to make websites

Plain HTML and CSS

In my opinion, very underrated. My [contact page] is made using just HTML and CSS, and I think it does an excellent job at conveying the information it needs to. It was easy to set up and easy to update and adjust. It doesn't scale up very well, but it scales down excellently.

Static site generators

The first iteration of this website was made using Jekyll, and I now use [Zola], but all static site generators work pretty much the same way:

  • pick a theme
  • write some markdown files
  • run the generator
  • upload the resulting files to a hosting service (or self-host!)

I like this a little more because it separates the actual content of the site from the minute details of how everything is going to look.

Hosting services

Any web service should be hosted. While you could host it yourself (I don't know exactly how, but I hear NGINX is involved), there are so many free (in both cost and source code) options out there that, in my opinion, it really doesn't make much sense to self host a static site.

  • GitLab - I had some issues getting the GitLab pages pipeline to work properly, and some redirection authentication shenanigans. I don't remember a lot about the process, but at the time, I found it to be smooth and simple. I'm not sure what my frame of reference was.
  • Codeberg - I had a few hiccups (that I've unfortunately forgotten the details of), but other than the fact that the compiled website has to be stored in a repository, I'm pretty happy with it.
  • pages.sr.ht - Very nice upload workflow that lets you just curl a .tar.gz file. The upload process is as easy as running a shell script, and when it comes to statically generated sites, I greatly prefer running a script over the Codeberg workflow, which requires two seperate repositories: one for the source files and one for the generated site output. The only caveat with sr.ht is that it doesn't allow third-party scripts. Which, frankly, makes sense, but I really want asciinema and KiCanvas and Sketchfab embeds, so I'm currently useing Codeberg for this site.

There are also some options that I haven't evaluated yet:

  • surge - The CLI-centric workflow is nice, but I don't want to install some random node.js program.
  • glitch - You have to use their editor; doesn't let you upload your own website (except through a GitHub import, after which you once again have to use their editor)
  • bunny - It seems like there's an FTP upload option, but I can't figure out how to use it. Also, it's not free.

Markdown shortcodes in Zola

Made a shortcode file, and I use it by adding the following snippet to a post:

{{card(
	title="↹lature",
	link="/mus-tec/tlature#chain-view",
	desc="devlog - Implementing a niri-like signal chain viewer"
)} }

It creates a little card for visiting the article.

Unfortunately, Zola doesn't provide the information to automatically generate the title and description from the markdown front matter (all available variables can be shown with {{ __tera_context | json_encode(pretty=true) }}), so next step is to see if that's a thing that can be forked in.

This information is available in the context of page templates, which is how the auto-generation of the "All pages" sections on group pages like the homepage or Music Technology page, but those variables store the output of the markdown -> html rendering process, which of course won't be available during the process itself. That being said, assuming the front matter is independent of the html output, it should be possible to have that information available during markdown rendering.

wiki/garden?

TODO: write a review of the following blog post: https://maggieappleton.com/garden-history#a-brief-history-of-digital-gardens