Welcome to Jekyll

For those of you who are familiar with Jekyll, no, I didn’t forget to delete the default post. For those who aren’t, Jekyll is a ‘Static site generator’, probably the most well known example of such a thing.

4 minute read

For those of you who are familiar with Jekyll, no, I didn’t forget to delete the default post. For those who aren’t, Jekyll is a ‘Static site generator’, probably the most well known example of such a thing. It certainly has the most Github stars of all the static site generators on staticgen. It is also what I used to build this site.

I’m a huge fan of static site generators. As a designer / front-end dev I find them a great solution for mocking up sites, ahead of a back-end being integrated. That’s selling these tools short, for sure. Sites created from these generators can certainly be used for full production builds. In my experience though, there is as yet no non-technical solution for content editing that matches the experience of a content management system. My personal sites (like this one) rarely need to be dynamic, and only I (someone who is happy to work in code) need to be able to administrate them. So this is another good use case for me.

Jekyll is a great tool, with some good selling points. The biggest of which is probably its integration with Github Pages. Ultimately though I chose Jekyll for this site because it is very blog centric. While I wanted to give it a little shout out here, Jekyll is by no means my de facto site generator of choice.

I’m a firm believer in having the right tool for the job. I don’t just mean having a screwdriver in your toolbox, I mean having a range of different screwdrivers. This analogy falls down pretty quickly. Once you’ve mastered the use of a screwdriver, you can pretty comfortably use any screwdriver you lay your hand on. Static site generators on the other hand tend to have their own unique learning curves. Having to learn the nuances of many different static site generators probably wouldn’t be a good use of anybody’s time, I do really value though, having a few favourites to choose from. I’d like to mention a couple of others, while I’m here.

Middleman #

Middleman is up there with Jekyll when it comes to established static site generators. To me, it is to websites, what Jekyll is to blogs. If I’m free from constraint, Middleman is my default choice. I find that out of the box, it gives me a good boilerplate for website projects. It’s versatile, unintrusive, and just works. I use Middleman to build my photography site for example. It’s a simple single page, essentially a list of images with captions. Middleman is there, primarily, to give me the separation of content and code, so I’m not duplicating code every time I add a photo. As you might come to expect from a static site generator, Middleman has some bonus features that make editing even easier. There’s LiveReload integration, which just needs to be switched on during initiation. There’s also a nice deployment plugin, allowing you to upload your files from your command line.

Roots #

I have relatively little experience with this one. It seems to me though that Roots is spoken about less (in these kind of posts) than the two aforementioned tools, and I feel it deserves a mention here. Roots has a few distinct pros and cons for me, a lot of these come down to personal preference though, so I wont’t go into them all here (I’m sure you can find in depth reviews of all these applications elsewhere). I would like to mention though, the one thing that lead me to Roots, and that’s Roots Records. This extension essentially enables Roots to load remote (JSON) data, into your project, and make it available to your templates. This is something I specifically wanted for my design portfolio site. All the content already existed on my Behance profile. Being able to pull that content into my site, without having to worry about the API going down, or hitting its usage limits, was the ideal situation for me. Beyond this use case though, I find this quite an exciting concept. It begins to truly separate content from the codebase. Meaning content editors could be interacting with an interface designed specifically for them, it’s only prerequisite being that it has to produce a JSON file. Meanwhile, us techies can continue to enjoy our static site generators :)

Start a conversation. @ me on Mastodon.