When I first heard about Jekyll, I was intrigued and wanted to learn more about this tool. That’s when I discovered that it was part of a full-fledged tool category: static site generators. Here is what I learned when rewriting this blog and my personal website using 2 different static generators.

Static site generators

Basically, a static site generator allows to format content using a templating language that further processing will render into plain HTML files:

content + template = HTML

There are a lot of different generators as proves the list available at staticsitegenerators.net. It’s interesting to browse generators available in a specific language(ruby, PHP, JS, etc.) or ordered by the last updated time so we can choose one still actively maintained. Depending on the chosen tool, content will be created using some markup language such as Markdown, then formatted to be visually appealing using a template language like Liquid or Blade which usually offers variables or functions for more advanced layouts. Then, the site comes together after the generator processes those files by merging content and templates to generate HTML files. Some generator, like Jekyll, will allow to install plugins(or develop custom ones) to add steps to this processing and modify the output. For example, a plugin could generate the RSS feed corresponding to the published posts of a blog.

Compared to Wordpress(which provides tools to build dynamic websites) where the content is fetched from the database, processed and rendered for every request, static generators do that only once when the content changes. This makes static sites useful for content that does not change often and is read-only. On the other hand, dynamic sites are more flexible, offers real-time content and rich interactions to the user. Think of a blog or a corporate website(static) where you passively browse content to get information compared to Facebook or Twitter(dynamic) where the news feed is constantly updated, you receive friends request, direct messages and you can interact with all these components.

As there is no one fits all tool, static sites offer interesting advantages when used in the right context:

• Speed: Web servers are pretty good at serving static HTML files. Since there is basically no processing done by the server upon every request, the server requirements are minimal to run a static website and it supports higher traffic as the overhead is negligible.
• You have more control on the content: Content is created in plain text files instead of stored in a database harder to access directly. This also allows you to version control it using VCS like Git.
• Server configuration: The server configuration is usually more straightforward as web servers can serve static files out of the box. There are fewer components involved so it’s simpler to put in place and to secure. Even better, you can publish the generated HTML to GitHub and host your site on GitHub Pages.

If no user interaction is needed and there is no real-time content, a static site might seem like the perfect solution, but there is a small drawback depending on who will be maintaining the content. Usually, static site generators don’t use fancy administration control panels like Wordpress, for instance. As a developer, I don’t mind browsing directories and manually create new files, but less tech-savvy users might prefer the reassuring UI of an admin panel(although some static generator also offers one or have plugins to add it).

Jekyll vs. Jigsaw

I decided to get into static site generators because I heard great things about Jekyll. It’s always hard to choose a tool when you don’t know much about the technology you will be using so you must rely on some googling. In the end, there is no better way than doing a small project to try out a new tool. So I decided to rewrite my blog using Jekyll. The documentation is great and the configuration is not complicated once you got ruby versions sorted out. Since Jekyll is pretty popular, there are plenty of resources online if problems ever arise.

At about the same time, I discovered Jigsaw through Twitter. When I began to play around with web technologies more seriously, I resolved to learn a web framework and I settled on Laravel. Jigsaw is a static generator aimed at Laravel developers using the same tooling like Blade templating and powerful Collections utility methods.

After using both Jekyll and Jigsaw to build a real project, here are some things I noticed:

• The documentation is complete, but Jigsaw is less popular so fewer resources are available online. For instance, searching for tags cloud jekyll gives appropriate results in contrast with tags cloud jigsaw which shows pretty much only jigsaw puzzle pieces with words on them and other useless items.
• Jekyll supports plugin to extend its processing behaviour. They can be installed through ruby gems, or by simply adding a ruby file to the plugins directory of the site. This mechanism is very powerful as you can create even create files programmatically. For example, you could generate a page showing all the posts for every tag used in the blog posts. That’s a feature that would look like it can’t be done using a static site, but the tags’ pages change only when a new post is added. So, when the site is built by the generator, the tags’ pages are created accordingly.
• Jigsaw does NOT support plugins and the processing pipeline can’t be extended as far as I can see. Although, it’s possible to create helper methods to reuse logic across multiple pages.
• Jekyll’s Liquid templating has many interesting features(tags for control flow/iteration and filters), but I prefer Jigsaw’s Blade templating where I can use any PHP function and Laravel’s Collections library.

In the end, it’s a matter of taste and what you’re trying to accomplish. I prefer Jigsaw’s technical environment, but it is less flexible than Jekyll for a complex site’s structure.

What’s next?

Overall, both tools are fun to work with. I learned a lot playing with those 2 static site generators and I hope to be able to use them again in the future and better understand the appropriate use case for such tools.