When you hear ‘Jekyll’, you may think of the infamous character in Robert Louis Stevenson’s novella ‘The Strange Case of Dr Jekyll and Mr Hyde’. In the web development world however, Jekyll has been adopted as the flag-bearing standard for static site generators (SSGs). ‘Wait!’ I hear you say: ‘Static? That doesn’t sound useful…and what’s with the generator?’ Enter my secret laboratory and I shall explain…
Essentially, Jekyll provides an alternative blogging website deployment worthy of competition against the biggest blog providers such as WordPress and Squarespace.
Existing Server-Side Blog Providers
Traditional blog providers (guised as complex CMS solutions) can be cumbersome. They offer the opportunity to influence the design of a website as well as allowing controlled access to content writing. Beyond this, they’ve grown to offer analytics services, CRM integration, content repositories and various APIs for integration into other areas. With these come individual security considerations as many third party applications are supported. Despite their capability, these facets collectively represent an overbearing size for simpler scopes.
From a technical perspective, the big blog providers require hosting on a server that actively processes using most of the tech stack every time a visitor accesses the website. This results in a number of inefficiencies at the expense of the website owner relating to time, money and energy. It is far from efficient.
Why Jekyll Beats Server-Side Providers
The impetus for replacing solutions like WordPress and Squarespace with Jekyll is derived from the removal of a remote processing unit on the server side. If all that is desired is a blog then the cost benefits from not having to pay for processor cycles are easy to see. Instead, a single FTP server with shared hosting offers a far cheaper method of deployment. With a SSG like Jekyll, any processing shifts to the client-side, which unlike a server-side solution won’t be running 24 hours a day - in fact the processing only really exists on the developer’s side when compiling. This results in lower electricity consumption which is cheaper and better for the environment.
Why Jekyll Beats Existing Static Sites
Static sites have existed since the early internet and we’ve learned to separate the HTML markup from the CSS style and Javascript function. Jekyll takes this to the next level where repeated markup is codified in modules. Here, we can simply instantiate a constant or variable which can be referenced multiple times across a site with smaller code. For example, we can have a module dedicated to a global nav, a footer, a blogpost, etc. This ultimately saves time when building a website and prevents constant re-writing (even clumsy copy & pasting) of code. The library-centric approach creates consistency across a website and from a design perspective is conducive to working with design pattern libraries; once you’ve created, tested and deployed, it’s available to use anywhere across the product.
Why Jekyll Beats Other SSGs
Jekyll rises to the top amongst a plethora of static-site generator solutions because it is well supported:
– Documentation via an official Wiki.
– Plenty of YouTube videos discussing uses.
– Strong community support
– Questions answered online at Stack Overflow and similar
– Plenty of free and paid high quality templates
— One such free template provider is CloudCannon. They have a number of excellent templates for you to bootstrap into Jekyll with minimal HTML and CSS setup.
– An annual Jekyll Conference which brings leaders together, sharing presentations on the development of the tech and its uses.
But…!
Despite the amazing advantages above, Jekyll is still sufficiently technical enough to irritate non-tech types into siding with solutions that are considerably more frictionless and offer a better user experience. Although the Jekyll scene is improving day-by-day with services such as Cloud Cannon and Site Leaf existing to lower the barrier, it still requires knowledge of a command line interface (CLI), Markdown, YAML, HTML, CSS and their associated tools.
There’s no clear best practice on deployment work flow outside of Github Pages. I’ve gone a bit rogue with this site by hosting on AWS S3 due to past familiarity and reliability of Amazon infrastructure. It certainly isn’t the easiest deployment but it is a strong one at a negligible cost. In the future I’m hoping to experiment using Github Pages as a host since Jekyll integration is supported from the get go; write code from Github’s web interface - no version syncing, compiling or uploading to worry about!
In Conclusion
Jekyll is an excellent modular solution that is well supported amongst SSGs if you’re willing to be adventurous with a minimal amount of coding (which I don’t think Markdown qualifies for - it’s a lot easier than coding!). There are plenty of superb templates to cater for your design needs and all are open source in case you want to tweak them. Best of all, it’s a light, fast and secure web deployment solution that will make your users forget about loading times and provide you with peace of webhosting mind.
