Skip to content

Generatoren für statische Websites

Ganz früher bestand eine Homepage, bestanden Webseiten allgemein im wesentlichen aus HTML-Dokumenten. Auf dem Weg zum Web 2.0 kamen zunächst CGI-Scripts für bestimmte Anwendungen auf; insbesondere aber mit der Verbreitung von PHP wurden Webseiten deutlich interaktiver. Blogs, Gästebücher, Kontaktformulare wären anders auch kaum vorstellbar. Nicht immer aber ist Interaktivität wirklich erforderlich. Manche eigentlich statische Seite wird nur deshalb dynamisch via PHP - oder auf vergleichbare Weise - erzeugt, weil es so bequem ist, die Erstellung einer Navigation und der Grundstruktur der Seiten zu automatisieren und Änderungen nur an einer Stelle vornehmen zu müssen. Das kann durch Installation eines CMS - oder eines dafür "zweckentfremdeten" Blogs oder Wikis - erfolgen; man kann auch wie ich schlicht die bisherigen HTML-Dokumente durch PHP-Scripts ersetzen, die im wesentlichen nichts anderes tun als vorgefertigte Funktionen für die Generierung des Seitengerüsts und der Navigation aufzurufen und ansonsten praktisch nur aus HTML bestehen. Meistens wäre es aber eigentlich gar nicht erforderlich, die Webseiten für jeden Aufruf neu zu generieren, weil sie sich nicht oder doch nur selten ändern. Ausreichend wäre es vielmehr, die Erstellung der an und für sich statischen Seiten aus Vorlagen - Templates - zu automatisieren und dabei ggf. auch automatisch die nötige Navigation zu erstellen.

Das leisten - in verschiedensten Variationen - static site generators, also Scripts oder Programmpakete, die man mit Schablonen (Templates) und Inhalten füttert und die daraus - ergänzt um eigene Programmschnipsel - die fertige Website erstellen. Vorteilhaft daran ist, dass die Webpräsenz im wesentlichen aus statischen HTML-Seiten bestehen kann, nur dort durch Scripts ergänzt, wo das auch tatsächlich für Interaktivität notwendig ist. Auf dem Webserver wird die Last deutlich verringert, weil nicht für jeden Seitenaufruf ein PHP-Interpreter gestartet werden muss; auch bestehen weniger Angriffsmöglichkeiten, weil kein ausführbarer Code mehr "live" auf dem Webserver laufen muss. Eine gewisse Interaktivität lässt sich auch durch tägliche, halbtägliche oder sogar stündliche Neuerzeugung der Webseiten erreichen; das macht für ein Forum oder auch ein Blog mit Kommentaren sicher wenig Sinn, aber wenn "nur" ein RSS-Feed oder die aktuellsten Tweets eingeblendet werden sollen, reicht das oft aus. Zudem lassen sich bspw. Kommentare auch durch externe Systeme wie Disqus vermittels Javascript einbinden.

Das Angebot an solchen Generatoren ist - wie bei Blogs, Wikis, CMS, Bugtrackern usw. - einigermaßen unüberschaubar geworden, wie man einer beliebigen Liste von Static Site Generators entnehmen kann. Gute Erfahrungen habe ich mit nanoc gemacht, mit dem auch der CCCS seine Website generiert; Jekyll wird bspw. bei GitHub genutzt, um dort Webseiten - direkt aus Git heraus - zu generieren. Der einzige Nachteil bei beiden ist ggf., dass sie in Ruby geschrieben sind und daher eigene Scripts und Erweiterungen sinnvollerweise ebenfalls in dieser Sprache zu halten sind. :-)

Das Grundprinzip ist bei allen Generatoren immer dasselbe: Es wird ein Grundgerüst für die Seiten in Form eines oder mehrerer Templates aufgebaut, gerne in HTML 5 und "responsive", die dabei Platzhalter oder sogar entsprechend fortgeschrittenere Funktionen enthalten. Das Design erfolgt über CSS, wobei auch CSS-Präprozessoren wie LESS oder SASS zur Anwendung kommen können. Die einzelnen Webseiten schließlich können als HTML-Dokumente, aber besser noch in einfacheren Auszeichnungssprachen wie MarkDown, Textile, Asciidoc usw. angelegt werden. Dann gibt es in der Regel noch eine Konfigurationsdatei, aus der sich ergibt, wie die einzelnen Bausteine - Templates, CSS, Seiteninhalte - "bearbeitet" und zusammengefügt werden sollen. Aus diesen Anweisungen und Bausteinen generiert der Site Generator dann statische HTML-Dokumente (oder auch PHP-Scripts, oder Dokumente, die Javascript enthalten, oder ...). In der Regel sind dabei eine Vielzahl von Filtern zur Interpretation von Markdown, LESS und Co. bereits enthalten; die eigenen Seiten und Designs lassen sich daher quasi aus einem Baukasten zusammensetzen, zumal als Basis für das Grundgerüst der Seiten auf Systeme wie Bootstrap oder HTML5 Boilerplate zurückgegriffen werden kann, die eigene Schriftarten, Icons und/oder Javascript direkt mitbringen oder zumindest entsprechende Anregungen enthalten. Mit verhältnismäßig wenig Aufwand lassen sich so die eigenen Inhalte hübsch, technisch modern und auf den verschiedensten Geräten vom Smartphone über das Tablet bis zum Laptop oder großen Desktopbildschirm ansehnlich darstellen.

Wenn man möchte, kann man auch die Quelldokumente in einem Versionsverwaltungssystem wie Git verwalten und bei jeder Änderung daraus automatisch eine neue Version der Webseiten erzeugen. Auf diese Weise ist ein Blogbeitrag, aber auch eine neue Seite der eigenen Homepage schnell in Markdown geschrieben, mit einem Vorspann - mit den notwendigen Informationen wie Titel, Autor, Erstellungsdatum, Typ pp., bspw. in YAML - versehen und im Git-Repository gespeichert; daraus erzeugt dann der Generator automatisch die neue Seite und passt - gleichfalls automatisch - alle davon betroffenen anderen Seiten (Inhaltsverzeichnis/Sitemap, Navigation, RSS-Feed, ...) an und erzeugt sie, soweit nötig, neu.

Ich finde das sehr praktisch für alle Anwendungsfälle, die keine "Webapplikation" darstellen, sondern im wesentlichen statische Inhalte enthalten, die sich nicht minütlich oder stündlich, sondern eher täglich, wöchentlich oder auch nur alle Jubeljahre einmal ändern. Durchaus lässt sich aber auch ein Blog so betreiben, wenn man denn die interaktiven Elemente wie Kommentare pp. "outsourced", bspw. an Anbieter wie Disqus. Mit ausreichend Zeit - ja, genau da liegt der Knackpunkt ... :-) - plane ich, zumindest einige der von mir betreuten Webseiten in der Zukunft entsprechend umzustellen.

Trackbacks

Netz - Rettung - Recht am : Webdesign anno 2015

Vorschau anzeigen
Webdesign ist ein Beruf - und eine Kunst. Und damit nichts, was man sich “mal eben” im Vorbeigehen für die professionelle Gestaltung der eigenen Webpräsenz aneignen kann. Dennoch müssen Webseiten (gerade heute!) nicht mehr entweder “kla

Netz - Rettung - Recht am : Webseiten und Webapplikationen erstellen und pflegen

Vorschau anzeigen
Viele der in den vergangenen vier Wochen dargestellten Möglichkeiten rund um die Gestaltung von Webangeboten lassen sich ohne größeren technischen Aufwand umsetzen. Will man jedoch Templates einsetzen, andere (vereinfachte) Auszeichnungssprachen wie Markd

Netz - Rettung - Recht am : PHP-FPM mit Debian Jessie

Vorschau anzeigen
Statische Webseiten sind nett (und durchaus wieder im Kommen), aber zumindest für manche Zwecke sind dynamisch generierte Seiten und die auf diese Weise ermöglichte Interaktivität doch dann besser oder gar notwendig. Facebook, bspw., würde sich als statis

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Dirk Deimeke am :

Dirk Deimeke

Im Moment sind wir themenmässig voll auf einer Wellenlänge. :-)

Auch ich möchte zwei Webseiten auf eine statische Variante umstellen. Mein momentaner Favorit ist Pelican.

Thomas Hochstein am :

Thomas Hochstein

Das heißt dann ja vielleicht, dass wir beide am Puls der Zeit sind. ;-)

An einem Erfahrungsbericht über Pelikan wäre ich (irgendwann einmal) interessiert; da ich allerdings von Python bisher genauso wenig Ahnung habe wie von Ruby, hätte das wenig Unterschied gemacht ...

Thomas Hochstein am :

Thomas Hochstein

Pelican scheint mir nach der Beschreibung - wie gar nicht wenige Generatoren - explizit (und fast ausschließlich) auf Blogs zugeschnitten zu sein. Ich suche da eine mehr allgemeine Lösung und habe festgestellt, dass man sehr schnell helper modules (wie es bei nanoc heißt) bzw. Plugins (wie Pelican es wohl nennen würde) benötigt, wenn man etwas komplexere eigene Lösungen haben will. Dazu gehört bspw. die automatische Generierung von Veranstaltungsdaten (Ort, Zeit, Veranstalter pp.) aus YAML front matter, hinterlegt mit Links, aber nur dann, wenn diejenigen Daten vorhanden (und verlinkt) sind.

Der CCCS generiert aus den vorhandenen Einzeldateien mit näheren Infos für jede Vortragsveranstaltung bspw. nicht nur - zusammen mit anderen Terminen - automatisch den Kalender, sondern erstellt - gleichermaßen automatisch - Übersichten mit vergangenen Veranstaltungen, gesondert nach Jahren, mit Paginierung. Das alles wird man nicht "out of the box" finden, und es ist oft dem Verwendungszweck "Blog" ähnlich, damit aber eben nicht identisch.

Insofern finde ich es schon einigermaßen wichtig, das vorhandene Gerüst um eigene Bausteine ergänzen zu können.

Dirk Deimeke am :

Dirk Deimeke

Ich habe mich mit Wolfgang Stief am vergangenen Wochenende unterhalten. Wir beide suchen beispielsweise auch noch die richtige Markup-Language und er ist zu ASCIIDoc gewechselt.

Kennst Du die Webseite der Static Site Generators? Oder das Gollum Wiki?

Thomas Hochstein am :

Thomas Hochstein

Ja, die Listen der static site generators kenne ich; ich hatte ursprünglich einige Zeit gesucht nach einem Programm, das ich ggf. durch Module o.ä. in einer mir vertrauten Sprache (Perl, PHP) oder wenigstens in einer Sprache, die ich ohnehin einmal lernen wollte (Python), erweitern kann, statt mich ausgerechnet mit Ruby beschäftigen zu müssen ... Dabei habe ich nicht nur festgestellt, dass das Angebot einfach zu groß ist, um jedes verfügbare Programm in allen Einzelheiten zu evaluieren, sondern auch, dass gar nicht wenige Generatoren auf Blogs festgelegt oder doch darauf zugeschnitten sind. Das war aber nicht das, was ich gesucht habe.

Für die Auswahl von nanoc war für mich einmal entscheidend, dass ich an der Website des CCCS gesehen habe, dass man damit das erreichen kann, was mir vorschwebte, und dass ich dort auch Beispiele für praktische Anwendungen ansehen konnte, die Vielfalt der vorhandenen Filter bei der Flexibilität, zwar ein statisches Blog betreiben zu können, aber eben nicht nur oder primär dafür geeignet zu sein, und die Möglichkeit der einfachen Erweiterung durch eigene Funktionen.

Gollum kannte ich bisher nicht; ich wollte mich immer mal mit ikiwiki beschäftigen, und ich glaube, das wäre für mich auch die erste Wahl, wenn ich ein Wiki-aus-einem-SCM einrichten möchte. Den Schritt habe ich allerdings bisher nicht getan, sondern bin bei Dokuwiki geblieben.

Dirk Deimeke am :

Dirk Deimeke

Gegen Ruby wehre ich mich auch noch, ich werde nach meinen Erfahrungen mit der Software Redmine mit Ruby nicht warm.

Oder, mit anderen Worten, ich bin genauso weit wie vorher ...

Thomas Hochstein am :

Thomas Hochstein

Oh, und was AsciiDoc betrifft - ich halte das für das Mittel der Wahl für längere Texte, die auch verschiedene Textauszeichnungen benötigen.

Für - meist ja doch eher übersichtliche - Blogbeiträge und auch für einfache Webseiten hat mir bisher Markdown genügt. Vielleicht nicht zuletzt, weil Generatoren wie nanoc es mit freistellen, ob die Quellseite Markdown ist oder HTML (oder Markdown, das HTML enthält, was ja auch geht) oder sogar PHP.

Dirk Deimeke am :

Dirk Deimeke

AsciiDoc hätte schon den Charme, dass ich mich auf eine einzige Auszeichnungssprache beschränken könnte. Warum zwei verschiedene lernen, dann kann ich auch bei dem bleiben, was ich derzeit mache: Statische Seiten in HTML, Serendipity-Artikel in Pseudo-HTML und DokuWiki mit Wiki-Markup. Vorträge und Papier dann weiterhin in LaTeX.

Martin am :

Martin

Wer gerne schreibt und es mag, wenn der Artikel im Mittelpunkt steht, kann sich mal mein Blogless anschauen, ein etwas spezieller Generator: http://blogless.datenbrei.de . Man muss keine Sprache lernen, das ganze läuft im Webspace mit PHP und generiert statische Seiten mit sitemap und RSS-Feed, wenn man möchte. Ach ja, es gibt keine Quell-Dateien, alles ist HTML.

Kommentar schreiben

HTML-Tags werden in ihre Entities umgewandelt.
Markdown-Formatierung erlaubt
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Gravatar, Identicon/Ycon Autoren-Bilder werden unterstützt.
Formular-Optionen
tweetbackcheck