Blogging like a rustacean

Overview

This blog is built with Rust and no Javascript. Why might that be interesting? I overview the performance, accessibility, SEO, and security implications this site (and yours?) could have compared to a competitive site generated by Jekyll. I also show, with provable evidence, how this tech stack supersedes some of Jekyll's aspects.

Jekyll?

Jekyll was written in Ruby and is the most popular static site generator (SSG) in use. The SSG ingests Markdown formatted text and uses templates to generate a static website. Jekyll seems ideal for those quickly publishing thoughts with nice formatting. GitHub Pages is powered by Jekyll¹, and GitHub will use Jekyll to build a site by default². These reasons and special privileges make Jekyll a safe popular option for most users.

The general workflow is to 1) install Jekyll, 2) create a project, and 3) host it on GitHub. If you create a GitHub repository named <username>.github.io, GitHub will automagically host this with GitHub Pages for free³. You can use alternative static site generators with GitHub Pages' hosting, which we will explore later.

Technologies

It's time to introduce the components that get taped together to present what you see now and de-obfuscate the magic. I install Zola as a Rust-alternative SSG to Jekyll. Contrary to Jekyll, Zola makes minimal robust assumptions about content. Moreover, Zola needs a "theme" to dictate the output of static sites, providing valuable flexibility for developers wanting more control. I chose Jieiku's "Abridge" theme with Zola for its maturity as a blogging theme. I later explain how I host, test, and deploy my blog for free using GitHub Pages and GitHub Actions.

* Optional

Zola's opportunities

Why do I favor Zola over Jekyll? Let's clear the air on Zola - It's not because of WASM. Rust's famous ability to transpile into Web Assembly (WASM) may be hip and trendy, but this is not the reason Zola is substituting Jekyll. Zola is a mature SSG with all of the necessities. The SSG offers live-reload previewing, scalability, markdown, and more. But most importantly, Zola makes fewer assumptions about content, allowing a static website exactly how I want it.

Operability

One contentious point with Jekyll was operability. As a Rust developer, I enjoy the ability to fix issues if they arise. Since Jekyll is written in Ruby, this presented a language barrier to me, or any rustacean, who otherwise has no interest in Ruby. From the perspective exclusive to a blogger, one should never need to write Ruby, only markdown. My conflict was with the undertone of uncertainty I had relying on Jekyll as a backend. Generally speaking, I wanted the ability to fix or contribute to my backend SSG, Zola.

Lighthouse metrics

Jekyll potentially makes all the right tradeoffs as a simple, blog-aware solution. Unfortunately, inherent to those compromises, one can expect to record off-nominal results from web-scoring frameworks. Google Lighthouse is one such analytic framework that provides meaningful analysis for web scoring. When measuring several blogs with Jekyll, Lighthouse suggests opportunities for improvement across several axes of measurement. I will pick on Raph Levien's blog for evidence. He is a friend and active publisher in the Rust community, well known for his work on Xi, Druid, and Piet. Measuring his Jekyll blog is a good example, as several points are missing from a perfect score. Because Zola is very flexible, my objective was to abuse the finer control given to receive a perfect score.

Click here for Raph's Lighthouse report

Security

Indeed, a blog will typically only contain first-party-origin scripts and original content, so security is not a typical, or even legitimate, concern. However, I would like to endorse some benefits over Jekyll. Since Lighthouse does not measure security, I chose the Mozilla Observatory as a supplemental analytic framework to analyze. In using the Observatory, I found that Jekyll didn't aspire to mitigate some benign security concerns.

Generally, web security guarantees are from the web server, not the blog. These guarantees come as headers, certificates (SSL), and more. Aware, the developers of Jekyll delegate this grandiose responsibility to you. This task seems like an impossible problem if you do not control the web servers (e.g. GitHub Pages).

As a GitHub Pages user, I encountered this plight. However, there are a number of headers that can be enforced inline. These headers can be in-lined with control over the site templating, e.g. Zola.

Abridge

Zola has an index of themes for generating varying static sites, such as documentation sites, blogs, or portfolios. In a journey to find the most mature blogging theme, I began with Adidoks. As time went on, I had to replace it⁴, citing poor support for tagging, pagination, RSS/Atom, and more.

Enter Abridge. Abridge is a semantic classlight theme designed to be a modern emulation of Jekyll; fast, light, perfect. With caution in avoiding similar mistakes, I did my research. Abridge has support for these taxonomies, and most importantly, no javascript (demo).

Improvements over Jekyll

Abridge had some issues at first. For weeks I contributed to the source, making it accessible to a wider audience, and addressing the shortcomings of Jekyll. Some of my contributions include asynchronous deferral of font loading to improve the first contentful paint, fontawesome support, more social icons, SEO optimizations, color skins, and config options. Now I am happy to say Abridge feels like the most mature, minimal theme for blogging.

Abridge is, in my opinion, ready for adoption. Specifically, this theme is engineered as a better Jekyll with improved performance, accessibility, SEO, and security. If Abridge does get a perfect scorecard on Google Lighthouse, it is a bug. Please file an issue.

As previously suggested, security is a bit of a red herring, and I hold the opinion that the Mozilla Observatory is poorly calibrated. However, I show that security was improved regardless, especially for users without administrative privilege over their web server. While Jekyll scores an F, Abridge scores a B-, subject to improve further.

Jekyll's Security	Abridge's Security

Deployment

Deployment with Zola and Abridge came with a few hiccups, but nothing too major.

GitHub Pages

I chose GitHub Pages for hosting because of its convenience with GitHub. If one creates a GitHub repository named <username>.github.io or converts a repository to a Pages deployment, GitHub will graciously host static content for free and treat the code contained as the source code for Jekyll. More on creating a GitHub Pages site here.

There were two main pitfalls I was a victim to.

• GitHub Pages requires some ceremony to opt out of Jekyll. GitHub requires a .nojekyll file in the root level of the repository since GitHub defaults you into using Jekyll².
• I have a custom domain name, and with that, I needed to stage a CNAME file in the static/ directory of my Zola repository.

If you're considering a migration to GitHub Pages, the Zola guide is here.

GitHub Actions

My favorite aspect of this tech stack is the autonomy. GitHub Actions is a powerful, free CI/CD which cooperates with Zola. Pushing a commit can trigger a build or deployment. Thankfully, the authors of Zola provide an easy GitHub Action, batteries included.

You can see my actual workflow, but here is a minimal example:

on: push
name: Build and deploy GH Pages
jobs:
  build:
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - name: checkout
        uses: actions/checkout@v2
      - name: build_and_deploy
        uses: shalzz/zola-deploy-action@v0.14.1
        env:
          # Target branch
          PAGES_BRANCH: gh-pages
          # Provide personal access token
          TOKEN: ${{ secrets.TOKEN }}

If you're considering using GitHub Actions, see the Zola documentation here.

That's about it for now. Farvel!

Back to top