My experience with Jekyll
For years I have implicitly been a promotor of Content Management Systems (CMS) for website construction. I have quite some experience with Joomla!, but I have also used (both as administrator and author) other solutions such as Drupal, Wordpress and Typo3. A CMS is certainly the best choice when it comes to collaborative website edition. If numerous potentially HTML-oblivious users must contribute to the content of the website in an independent fashion, solutions such as Joomla! give you what you need: a simple interface to contribute with content and a well defined set of roles, e.g., authors and editors, to manage the content of yout website. In addition, if the website requires more specific functionalities such as a forum or a downloads manager, well-established CMSs offer a vast offer of third-party extensions. I am myself involved in the development of extensions for Joomla! and I am very pleased to see my work being useful to other people. Despite the attractiveness of CMSs, as everything in life, they have downsides. Poorly written third-party extensions can jeopardize the security of your website, even if the core CMS is secure and well maintained by the community. Also, CMSs require maintenance. This is usually done by an administrator who takes care of keeping the system up-to-date, and who sometimes has the last word about what is published. The server setup to host a CMS-based website is also more complex; it requires a web-server capable of running code and a database. This pays off for websites maintained by a community, but it may be an overkill for simple websites with a single user and content that changes rarely. That was my case. After having my Joomla! website hacked due to lack of proper maintenance, I decided to try a static site generator.
Dynamic and Static site generators
Sites like Joomla! or Wordpress generate the content of the website in a dynamic fashion. The content of the pages is normally in a database. Visiting a page of the website, e.g., http://mywebsite.com/somepage triggers a program in the server (the CMS) that retrieves the content from the database and constructs the HTML page displayed in the browser. The CMS offers an interface to manage the website content and appearance, i.e., edit and add new pages, or change the structure and style of the website. With a static site generator, the HTML of the website is generated a priori, that is, visiting http://mywebsite.com/somepage retrieves a static HTML file with the contents of the page. One could argue that such a setting is not much different from the way websites were constructed in the early times of the web: a collection of interlinked HTML pages. The difference with static website generators lies on the way those HTML pages are designed. Traditionally, the pages and styles were written by the website developer, either manually in a text editor or via a HTML editor such as Adobe Dreamweaver, Bluefish or Kompozer. Static site generators relieve the developer from the burden of writing the website from scratch. They offer a set of templates with pre-defined look-and-feel and structure. The user must only write the page's content in a set of files and the static site generator takes care of putting everything in the right place and deliver a set of interlinked HTML pages that constitute the final product.
Jekyll
There are plenty of static site generators out there. They are normally written in scripting languages such as Python, Ruby and Javascript. However, knowing how to program in these languages is not required to build a website. I cannot write a single line of code in Ruby but I managed to build this website using Jekyll. This static site generator (written in Ruby) stores the content of the website in text files written either in HTML or Markdown. The latter is a lightweight markup language quite popular for README files, and is supported by sites such as Github and Stack Exchange. The basic components of Jekyll are templates, layouts, themes and posts. Templates are written in a variant of the Liquid language (a markup language and engine to write web templates). Writing templates for Jekyll requires programming knowledge and is equivalent to write templates for Joomla!. Nevertheless, there are plenty of free and nice templates for Jekyll, which can be used out of the box. I used the default one. A layout defines the structure of a page. Layouts can be written in a mixture of HTML, Markdown and Liquid (for more sophisticated logic). A simple layout could show the title of the page in a h1 tag and the content of the page in a paragraph tag. Another layout could display a list of categories and the articles associated to each category. A set of layouts and CSS files is called a theme. A template can define multiple themes to adapt to different needs. The pages are displayed according a layout. In addition, it is possible to write plugins for Jekyll, i.e., modules that extend the functionality of the base program. They are written in Ruby. There is an extension that can migrate a Joomla! website and translate it into the Jekyll structure. I did not use it since I did not have too much content in my original Joomla! website.
Finally, deploying your website in Jekyll is as easy as running a command. Jekyll comes with a bundled lightweight webserver where the user can see the website locally. The deployment generates a folder named _site with a set of static HTML pages. These pages are the final product that should be published.
The veredict
I am quite satisfied with Jekyll and the result of my "experiment". My new website looks clean and sober, and it renders quite fast. Adding new content is fairly easy. It took me one weekend and a couple of hours every evening of a working week to set the website up, because Jekyll is well documented. The most common features for websites are very easy to implement. For more sophisticated requirements, e.g., writing a layout to group articles by category, I had to google to get an answer, but it was fairly easy. Still, as for content management systems, more specific features will probably require the development of plugins.