Update: New Website

August 8, 2022
Close up of new pagination design

You might not realize it, but my website has been completely rebuilt. Like most things, I stumbled into this project while working on a different project. This time, in my quest to control Csound with web technologies I fell down the Node.js rabbit hole, which led down the static site generator rabbit hole, which led down the GitHub Pages rabbit hole, and so on. Less than two weeks later I have this shiny new static site built with an ultra-minimalist custom script. So long Joomla! Here's how it all happened.

Csound, Browsers, and Node.js

As I've been working on the Mell Fark project the past few weeks I've run into a couple snags.

Node.js logo
Node.js lets you run JavaScript code outside of the browser environment.

Given that I enjoy coding with JavaScript and had already done a lot of work designing the Mell Fark interface with it, a good option would be to move to the Node.js environment. Node.js allows me to run JavaScript code natively on my computer without being in the browser environment. All I needed was a way to control Csound within Node.js. A quick search of Node.js packages revealed the csound-api by Nate Whetsell, so I had a path forward.

Static Site Generators

I'm new to Node.js, but it's been on my list of environments to learn for a while. In fact, the timing is good because I need to get familiar with Node.js for a work project. To get my bearings, I started with the official Introduction to Node.js, which is wonderful. And soon thereafter I started falling down the rabbit hole of Node.js packages and frameworks.

Before long I was looking into static site generators (SSG's), which are popular in the Node.js world. I've known about SSG's for a few years but never seriously considered using them. Here's a quick overview of dynamic versus static sites.

Logos of WordPress, Drupal, and Joomla
WordPress, Drupal, and Joomla are CMS's that dynamically serve websites.
Logos of Gatsby, Jekyll, and Hugo
Gatsby, Jekyll, and Hugo are SSG's that generate static websites.

Problems with Joomla

My website was originally built in Joomla. I've never loved Joomla, and I only chose it as a CMS because I was maintaining an organization's Joomla site at the time and wanted to learn more about how it worked. Here's why Joomla has been frustrating to me.

Choosing an SSG

Given my frustrations with Joomla and that I wanted to delve into the world of Node.js, I figured that converting my website into an SSG would be a good introductory Node.js project. The first order of business was choosing an SSG. I briefly looked at Gatsby and Jekyll but then started to read other people's blog posts about their experiences with them. These posts gave the impression that Gatsby and Jekyll were also flexible, abstracted frameworks with their own configuration learning curves. The writers asked, "Why spend days wrapping our heads around somebody else's idea of how to build a website when we can build bare bones SSG's that meet our needs in the same amount of time?"

One such writer was Yakko Majuri. His post "Why I built my own static site generator" made the case for an ultra-minimalist SSG. He wrote his own SSG called Teeny and explained how the components work together. If you look at the main cli.js script you'll see that it only takes about 160 lines of JavaScript to build his site. Studying the cli.js script demystifies what an SSG actually does. Inspired by his approach, I forked Teeny in GitHub and began to customize it for my own site.

My New Site

You can find the SSG code that builds my new website in my forked Teeny repository and the content and assets at my jasonhallen.github.io repository. I'll give you an overview of how it works.


The content of the website (aka the Music, About, and Blog pages) is made up of Markdown files and HTML templates. For example, here's the Markdown file of this post. At the top of the file is a front matter section that contains metadata about the post. After that is the post itself which is mostly written in Markdown with HTML sprinkled in to format the media items. Assets like images and audio are stored in dedicated folders within the repository. The Node.js package called front-matter parses the front matter and the package called marked converts the Markdown to HTML.


The website itself is built by the cli.js script. All it really does is insert the front matter and Markdown content from each Markdown file into different HTML templates. That's what produces a set of finished HTML files that constitutes the website. You'll notice that there's no database that stores and manages the metadata for the templates and assets. There's no need for one.

The main work I've done for this project is customizing the cli.js script. Out of the box Majuri's cli.js script creates a super simple site structure. My goal was to make the site look and behave like my original Joomla site, which meant that I needed to display a list of blog posts across multiple pages sorted by the most recent posts. This feature is also know as "pagination". Then for each blog post I needed to provide buttons that link to "Newer" and "Older" posts. Frameworks like WordPress and Joomla provide pagination and linking between posts out of the box, but when you're rolling your own SSG you have to code them yourself.

I also put a lot of work into the style.css style sheet. That's where I created the theme and layout of the site. Again, I just wanted the site to look like my original Joomla site. You can judge my success with these screenshots.

Screenshot of home page in Joomla compared to SSG
Home page in original Joomla site (left) compared to new SSG site (right).


My site is now hosted entirely in GitHub through their free GitHub Pages service. My old Joomla site was hosted by Bluehost which cost me $10 per month. In fact, I'm still paying for Bluehost for now, but I hope to cancel it soon.


Here's the workflow I've developed so far for writing and publishing blog posts.

  1. Write the content of a new post in a Markdown file. Add the metadata into the front matter section.

  2. Use the 'teeny develop' command to build the site and launch a local server so I can see how the new post looks. Every time I make a change to the Markfown file Teeny will rebuild the entire site, and I can refresh the page in the browser to see how it looks with the changes.

  3. When I'm ready to publish the new post I commit the changes to the main branch of my website's repository and then run 'gh-pages -d public' (from the gh-pages package) which commits the public directory of HTML files and assets to the gh-pages branch of my website's repository. I've set up GitHub Pages to deploy my website from the files in the gh-pages branch.

Next Steps

I'm very happy with my new site. It's basically the same as my old site except that:

  1. I have complete command over how it works.

  2. It's free.

  3. It loads much faster.

The workflow for writing new posts and publishing them is also more suited to how I like to work. All I need is a text editor and a command line to publish my site. No more getting lost and frustrated inside a bloated CMS.

There's more work that could be done on my website. Here's what I might work on next.

Leave a Comment

Your email address will not be published. Required fields are marked *