A new home for TheShellNut

Over the last month or so, I’ve been quietly rebuilding this blog using Jekyll.

This work is now complete, the resulting site have been tested pretty extensively in Chrome and Internet Explorer and I’m pleased with the result.

This new version of the “TheShellNut” is hosted on GitHub Pages, so the URL is :
For those who use an RSS reader to keep up-to-date, here is the feed URL :

From now on, any new content will be published exclusively to the new site.
I’m going to keep the old site around for a little while to let users transition to the new URL, then I may setup some kind of redirection, and finally I will kill the old site.

Why leave WordPress for Jekyll ?

Originally, what triggered me to consider alternatives was the fact the site was going down, not very often but sometimes for several hours. So I was pretty sure I could get much better uptime elsewhere.

Most of the benefits that I see in Jekyll compared with WordPress stem from a single advantage : simplicity.

Performance :

Serving a static HTML document is an order of magnitude faster than running PHP code and querying a database.

Sure, there are caching plugins for WordPress but even with one of these plugins, I find that the new blog easily outperforms the old one.
The fact that these static files are delivered through GitHub CDNs likely helps to keep the performance flawless, even at large scale.

Maintenance :

Almost every time I visit the WordPress admin interface, there are updates for plugins, themes or the WordPress application itself. This can get old.
On top of that, this requires a bit of testing to ensure these updates haven’t broken anything.

Jekyll has less plugins (especially if we want to keep the Jekyll install compatible with GitHub Pages), which means less time spent on plugin maintenance.

Security :

What can be hacked in a bunch of static files ? Not much.
For example, SQL injections attacks are not possible since there is no database.

The attack surface of a static site is so limited that attackers are probably better off targeting :

  • a vulnerability in Git
  • GitHub account(s)
  • CDNs delivering static files used by the site (especially JavaScript files)

Simple to customize :

Have you ever tried to customize WordPress themes or templates ? Then, you know it can get messy.
Besides, I have no intention of learning PHP.

I found that Jekyll customization has a gentler learning curve, because just getting the hang of HTML, Liquid and SASS (a cool way to manage CSS) provides a LOT of power in Jekyll.
These front-end technologies tend to be very approachable.

Reliability :

There are a number of things that could possibly go wrong when building the site (running jekyll build) related to config, layouts, plugins/gems versions or Github Pages-specific quirks.
But after the site is built, you could possibly break ?
Not that much, because at this point it is exclusively HTML, CSS and a bit of JavaScript : only stuff which runs within the browser.

And with the site being hosted on GitHub Pages, I’m willing to bet it will have better uptime than the old blog with the cheap web host.

One thing is certain, it will not intermittently crap itself in this way (unlike its WordPress ancestor) :

Database connection Failure

More adequate themes :

It’s a just a blog. All I need is a presentation layer for mostly text-formatted ideas, nothing fancy.

So I want a minimalist, clean theme that puts the content front and center.
This is exactly how many Jekyll themes are designed.

Also, most of these themes fully embrace responsive design so they are tablet and mobile-friendly, which is a very nice plus nowadays.

I love the authoring experience :

Over the last few months I spent quite a bit of time writing documentation in Markdown, and I enjoy it, a lot.
So writing and formatting posts in Markdown will make me more productive than using the awful WordPress built-in editor.

As part of both my day job and my personal projects, I do :

  • Code
  • Infrastructure-as-code
  • Configuration-as-code
  • CI/CD pipelines-as-code
  • Documentation-as-code

Heck, I even have the list of podcasts I listen to as code.

The primary reason for that is that it gives me the version control superpower.
I basically live in Git, so committing to a “develop” branch to experiment and pushing to a “master” branch to publish things is a very natural fit in my workflow.

So now, I can put my focus into creating and writing stuff on this fresh platform, and I’m looking forward to seeing you there !

Leave a Reply

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