An orange desert flower

Rebuilding with Jekyll

Posted 09 Jul 2023 by Scott

On my journey to discover an effective platform for hosting this site, I have decided to go with Jekyll (for now).

I should state that there are few key things I’m looking for here:

  1. Ease of use
  2. Ease of management
  3. Flexibility
  4. Works well with my hosting platform
  5. Cost
  6. Relative performance

Some of these are relative. For example, ease of use, doesn’t just mean it’s easy to get up and running, but also it’s easy to meld it into whatever I want it to be (i.e. “Flexibility”).

What I’ve tried so far (and what went wrong):


I’ve always (and I mean from way back at the beginning) had some issues with Wordpress. There are all these subtle little things going on in the background that maybe nice 90% of the time, but the other 10% of the time you’re screwed (i.e. in the beginning I wrote a lot about computer code, and curly quotes are bad in that context). Now, I know of ways to work around most these annoying things (though maybe I shouldn’t need a plugin to fix many of these things), so over the years, I’ve softened my stance on Wordpress in certain use cases. However, the new trajectory Wordpress is on, with blocks and code-free design is horrific.

I realize the whole block (formerly “Gutenberg”) thing is new(ish), but it’s so limiting and convoluted (and poorly documented) that it’s a non-starter for me. I mean I can build a nice looking blog like post with blocks, but it really limits just how far one can go with content and design.

Styling is so sucky. First, styles are initially defined using JSON in a themes config file. So any existing style sheets, style tools, frameworks, etc. that you like are useless to you. Now, if you adjust any of these defaults in the block builder (which is the part I think they feel is cool) the changes are not saved back to a theme or anything, they are saved in the database. While you can add plugins that help you export changes back to templates, there is no visual way to create global styles (for that you need to go back to the JSON config file.)

Finally, no matter what you do, the site ultimately ends up looking like every other Wordpress site (with maybe different colors, spacing, and images). Boring.


Statamic in general was nice, and I really wanted to like it, and maybe someday I’ll return to it when I have the time to fully explore it. But there was one big problem (which was probably on me): It totally failed once moved to my web host.

Beyond that some other issues include that it’s tightly integrated into Tailwind CSS, and while that is not necessarily a bad thing, the documentation doesn’t really go into how to work with tailwindcss etc. For example, when you make a style change (i.e. add a new class) to an element, it doesn’t work until you “rebuild tailwind”. Something that it never really goes into (this may just be a standard “curse of knowledge” error in the documentation). (BTW the solution is npm build, but you have to read the package.json to figure that out).

Mostly, I just grew impatient and opted for something simpler.


Hugo is supposed be Jekyll like, but faster (written in Go) and with more features. Now if you just wanted throw something up there, Hugo and Jekyll are similar. However, if you want to move beyond default, Hugo get complicated quickly. To make matters worse, Hugo’s documentation is lousy. I guess if you know, and follow along with, the evolution of Go, then Hugo might be the thing for you, otherwise, maybe try something else.

Craft CMS

I find some things with Craft CMS really cool (it can produce very clean code). It could be a great platform for a medium to large bespoke website, though when we start thinking about large sites I start thinking Drupal since I have lot’s of experience using it. The problems with it are two fold:

  1. You basically start with nothing and need to build everything up from scratch. Not quite to the extent of starting with a bare framework like Laravel, Symfony, or whatever (Craft I should mention uses Yii), but you really need to decide exactly how you want to model you site, and then build it up on piece at a time before anything tangible works.

  2. It relies heavily on doing everything on a development platform before pushing to production; however, the separation of what is contained in files and what is just in the database isn’t clear. So this makes things difficult.

Basically it became more work then I wanted for a simple website that seems to reinvent itself every year or so. (Also, and this applies to Statamic too, it can get pricey once you reach a certain point.)


I’ve always liked Jekyll for simple sites, and this site isn’t going to challenge any others for complexity. Jekyll is not as feature rich as Hugo, but it seems much more straight forward to use, and liquid templating works in any file with front matter (unless you tell it not to), so unlike Hugo, you can mix markdown, html and liquid all in the same page to wonderful effect.

Jekyll isn’t without its own weirdness, for example, themes are not (by default) part of your site, rather they are git packages, so to see how or were some stylistic themey stuff is happening you need to go for a journey around you file system. Still, as you build stuff out (assuming you are after a unique site) you can quickly (or slowly if you prefer) replace everything with your own stuff.

Still with a little basic web knowledge (HTML/Sass/Markdown) and a way to move files from you computer to your web server (SFTP/Git), you can be up and running quickly. With some added knowledge of Jekyll’s templating language (Liquid) you can do many wonderful things. Also, while certainly not needed, JavaScript never hurts it you want to add to fancy front-end features.

While I’m not sure I’d try to use Jekyll for a big site, it’s nice to use for this.