Wenn Webdesigner an statische Websites denken, kommen häufig schlimme Erinnerungen an längst vergangene Projekte hervor. Wie oft etwa hat man Kopf und Fuß einer Website nach einer Änderung manuell in jede einzelne HTML-Datei kopieren müssen? Wie schön, dass es irgendwann dynamisch wurde. Aber sind statische Websites seit der Verbreitung komfortabler CMS-Systeme nun komplett passé?

Nicht ganz, denn auch WordPress & Co. haben ihre Schwächen. Zum Beispiel müssen regelmäßig Sicherheitsupdates eingespielt werden, damit die Site nicht von Spam-Bots als Virenschleuder missbraucht wird. Auch die Entwicklung gestaltet sich nicht ganz so einfach, denn um vor signifikanten Änderungen eine realistische Vorschau des Produktionssystems zu erhalten, muss jedes mal die Produktionsdatenbank auf das Entwicklungssystem geklont werden. Strickt man dagegen mit heißer Nadel direkt auf dem Produktionssystem, sehen die Besucher schnell mal Layout-Müll.

Statische Sites dagegen bringen hier einige Vorteile mit. So laden sie etwa wesentlich schneller als dynamisch generierte Inhalte. Dass keine serverseitigen Skripte ausgeführt werden, trägt zur Sicherheit der statischen Seiten bei. Admins müssen sich nicht mit lästigen Datenbank- oder Serverkonfigurationen herumschlagen, da ein einfacher Webspace für die Auslieferung der Plain-HTML-Dateien genügt. So fällt auch das Einspielen von Patches und Updates für Datenbank, Skriptsprachen oder Server weg.

Wer wegen dieser Vorteile auf statische Sites setzen möchte und trotzdem nicht auf einen gewissen Entwicklungskomfort verzichten will, greift auf Seitengeneratoren wie den in Ruby geschriebenen Jekyll zurück. Die mit Jekyll erzeugten Inhalte und Markups liegen in strukturierten, statischen Textdateien vor; eine Templating-Engine sorgt dafür, dass HTML-Fragmente wiederverwendet werden können. Mit Hilfe des Entwicklungsservers lässt sich die Website in aller Ruhe begutachten, bevor sie auf das Produktionssytem übertragen wird. Bei jedem Speichern werden die HTML-Dateien automatisch im Hintergrund generiert.

Auch die Darstellung dynamischer Inhalte auf statischen Sites ist mittlerweile kein Problem mehr. Viele SaaS-Anbieter bieten die einfache Einbindung der typischen Engagement-Tools wie zum Beispiel Kontaktformulare oder Kommentare per JavaScript. Das macht Jekyll auch als Bloglösung interessant. Nebenbei sind diese externen Dienste oft besser als selbst gehostete Lösungen, weil die SaaS-Anbieter dem Spam-Problem mithilfe ihrer wesentlich größeren Datenbasis effektiver begegnen können.

Nicht nur für Entwickler, auch für Blogger bietet Jekyll interessante Features. Wer von WordPress & Co. migrieren möchte, nutzt dafür Jekylls Importfunktionen.

Die Seitengenerierung findet bei Jekyll auf dem Entwicklungssystem statt. Daher werden relativ hohe Anforderungen an das System gestellt. Am besten funktioniert die Erzeugung auf Linux oder OS X, die Installation auf Windows ist möglich, aber höchst beschwerlich. Entwickler sollten auch keine Angst vor Texteditoren und der Kommandozeile haben, mit denen bei Jekyll Installation und Build-Prozess gesteuert werden.

Vorausgesetzt, dass Ruby in Version 1.9.3 oder neuer vorhanden ist, kann Jekyll mit RubyGems installiert werden. Mit dem nun vorhandenen Jekyll-Binary lässt sich die Grundstruktur einer neuen Site erzeugen:

gem install jekyll 
jekyll new website
cd website

Um sich das Ergebnis dieser Arbeit anzuschauen, startet man den Jekyll-Entwicklungsserver mit einer einfachen Anweisung:

jekyll serve --watch

Den aktuellen Stand der Dinge bestaunt man nun im Browser unter „http://localhost:4000“.

Jetzt gilt es, sich das Dateigerüst von Jekyll genauer anzuschauen. Den wichtigen Anfang macht die Datei „_layouts/default.html“, die das Layout der neuen Website vorgibt. Es handelt sich um eine HTML-Datei, die mit Tags der Template-Engine liquid angereichert wird. Platzhalter wie {{ page.title }} und {{ content }} werden später durch Werte der konkreten Posts oder Seiten ersetzt. Es ist möglich, mehrere „layout“-Dateien zu definieren. Dadurch können auch komplett unterschiedlich gestaltete Unterseiten, zum Beispiel Microsites für Marketing-Aktionen, aus einer singulären Jekyll-Installation heraus generiert werden.

<!DOCTYPE html>
<html>
   <head><title>{{ page.title }}</title></head>
   <body>
      <div class="site">
         <div class="header">
            <h1 class="title"><a href="/">{{ site.name }}</a></h1>
         </div>
         {{ content }}
      </div>
   </body>
</html>

Eine der späteren Seiten soll die „index.html“ im Wurzelverzeichnis sein. Die Variablendefinitionen, mit denen nun die Platzhalter gefüllt werden, finden sich im so genannten „Front Matter“ im Kopf der Datei. Das Front Matter ist mit Bindestrichen eingezäunt und vom folgenden HTML-Inhalt mit einer Leerzeile getrennt. Hier können beliebige Variablen im Ruby-YAML-Format definiert werden, um sie anschließend im HTML per „liquid“-Tag auszugeben.

‐‐‐
layout: default
title: Your New Jekyll Site
‐‐‐

<div id="home">
   <h1>Blog Posts</h1>
   <ul class="posts">
      {% for post in site.posts %}
         <li>
            <span>{{ post.date | date_to_string }}</span>
            <a href="{{ post.url }}">{{ post.title }}</a>
         </li>
      {% endfor %}
   </ul>
</div>

In Listing 4 korrespondiert die „title“-Variable in unserem „index.html“-Front-Matter mit dem „{{ page.title }}“-Tag in der „_layouts/default.html“-Datei aus Listing 3. In der Regel sind die Variablennamen frei
wählbar. Um zum Beispiel den Betreiber eines Blogs auszugeben, können wir dessen Namen in das Front Matter der index.html aufnehmen:

---
author_name: Ralph von der Heyden
---
<p>Dieses Blog wird betrieben von {{page.author_name}}.</p>

Neben dem Front Matter enthält die index.html in Listing 4 noch den eigentlichen Inhalt, ein HTML-Fragment. Dieses wird im „default“-Template anstelle des „{{ content }}“-Platzhalters angezeigt. Besonders interessant ist die „for“-Schleife, mit der durch die „site.posts“-Variable iteriert wird. Dadurch wird die Seite von Jekyll automatisch mit den Dateien im „_posts“-Verzeichnis befüllt.

Ein einzelner Post ist dabei ähnlich aufgebaut wie eine Seite. Unser Beispielpost im „_posts“-Verzeichnis beginnt wie auch die „index.html“-Seite mit dem Front Matter, in dem zunächst die verschiedenen Variablen definiert werden. Der Inhalt liegt nicht in HTML, sondern im Markdown-Format vor. Jekyll konvertiert die Markdown-Daten später automatisch in HTML.

_posts/2014‐04‐06‐welcome‐to‐jekyll.markdown :
‐‐‐
layout: post
title: "Welcome to Jekyll!"
date: 2014‐04‐06 13:56:13
categories: jekyll update
‐‐‐
You'll find this post in your `_posts` directory.

Der Inhalt einer Website sollte gut mit den URLs korrespondieren, die darauf verweisen. Deshalb ist Jekyll sehr flexibel bei der Umsetzung eigener URL-Schemata. Grundsätzlich werden alle Dateien mit dem Suffix .html verarbeitet, zum Beispiel kann im Wurzelverzeichnis eine Datei mit dem Namen „about.html“ angelegt werden. Deren Front Matter wird befüllt und es wird noch etwas Inhalt eingefügt:

---
layout: default
title: Über diese Website
---
<div id="home">
   <h1>Über diese Website</h1>
</div>

Anschließend können wir das Ergebnis unter „http://localhost:4000/about.html“ bestaunen.

Der Webauftritt von Jekyll selbst ist auf GitHub gehostet. Ein Blick in den „_posts“-Ordner zeigt die letzten Beiträge im Markdown-Format.

Soll die „about.html“-Seite aber unter einer anderen URL angezeigt werden, ist auch das möglich. Dazu muss der Pfad aus der URL im Dateisystem angelegt und die Datei verschoben werden:

mkdir ‐p about/this/site
mv about.html about/this/site/index.html

Nun wird die Datei index.html erzeugt, die dann unter der URL „http://localhost:4000/about/this/site“ angezeigt wird.

Anders als für Seiten hat Jekyll für Posts bereits ein URL-Schema vordefiniert. Es bedient sich sowohl beim Dateinamen, zum Beispiel 2014‐04‐06‐jekyll.md, als auch aus dem Front Matter. Aus dem Dateinamen stammen Datum und Titel, sodass man sich zumindest das Datum im Front Matter sparen kann. Da im Dateinamen aber nur URL-kompatible Zeichen verwendet werden dürfen, ist die Angabe eines Titels im Front Matter unerlässlich. Beim Dateinamen der Posts ist das vorangestellte Datum und der nachgestellte URL-lesbare Titel Pflicht, damit der Post später in der „site.posts“-Variable auftaucht.

Die lokal erstellte Website muss nun noch auf einen Host übertragen werden. Da Jekyll anfangs mit der „‐‐watch“-Option gestartet wurde, liegt die fertige Site bereits im Unterverzeichnis „_site“ vor. Generell kann der Inhalt des „_site“-Verzeichnisses nach erfolgreicher Generierung einfach auf einen Host übertragen werden. Viele FTP-Clients unterstützen mittlerweile Synchronisierung, die sich auch für Jekyll-Projekte empfiehlt. Gut geeignet ist etwa das Tool rsync, falls der Host SFTP unterstützt. In diesem Fall empfiehlt es sich, für das Deployment ein kleines Script anzulegen und mit „chmod +x _deploy.sh“ ausführbar zu machen:

#!/bin/sh
rsync ‐rltPz ‐‐delete _site/ ssh_host:public/webserver/path

Anschließend funktioniert das Deployment mit ./_deploy.sh rasend schnell. Der Unterstrich zu Beginn des Dateinamens sorgt übrigens ebenso wie ein Punkt dafür, dass das Deployment-Script selbst nicht mit auf den Server kopiert wird. Alle anderen Verzeichnisse und Dateien werden eins zu eins übernommen. Interne Dateien wie eigene Scripts, Notizen oder Login-Daten sollten immer mithilfe von Unterstrich oder Punkt versteckt werden.

Übernimmt ein an Browser gewöhnter Kunde die Aktualisierung der Website-Inhalte, so fährt man mit einem klassischen CMS auf alle Fälle besser. Entwickler oder auch Blogger, die von den vielen Vorteilen statischer Websites profitieren möchten, finden dagegen in Jekyll einen einfach zu bedienenden Seitengenerator, der fast keine Wünsche offen lässt und enormen Gestaltungsfreiraum bietet.