Anfang letzten Jahres habe ich mir überlegt, wie ich meine hauptsächliche Arbeit beschleunigen und verbessern kann. Mein aktueller Job besteht zumeist darin, Responsive Webdesigns in HTML-Templates umzusetzen, die dann im Anschluss in der Software-Entwicklung weiter verarbeitet werden. Manchmal sind es Templates für Content-Management-Systeme, oft ist es aber auch die Grundlage für Java-betriebene Webseiten. Ich habe überlegt, wie ich schnell und flexibel statische HTML-Templates generieren, gleichzeitig mit Sass (Compass) entwickeln und ein Browser-Reload (Live-Reload) machen kann. Einige Systeme habe ich mir angeschaut und möchte kurz meine Erfahrung teilen.
Hammer for Mac
Als erstes habe ich mir „Hammer for Mac“ angeschaut. Hammer ist meiner Meinung nach ein einfaches Tool, um ein paar statische HTML-Seiten zusammen zu schrauben. Beim ersten Testlauf stellte ich aber schnell fest, dass Hammer nicht das machen konnte, was ich damit machen wollte.
Problem: Hammer konnte (damals?) keine HTML-Dateien in Unterverzeichnisse kompilieren — das ist doof. Zudem unterstützt Hammer Compass nicht. Das war auch suboptimal, autoprefixer & Co. gab es noch nicht.
Für Hammer gibt es ein kleines (eigenständiges) Zusatztool, das die statischen Seiten über einen kleinen (Ruby-) Server ausliefert – Anvil Server. Man kann so ganz easy virtualle Hosts wie http://project.dev anlegen. Das fand ich ganz gut.
Wie aber schon erwähnt, reichte Hammer für meine Anforderungen nicht aus.
Codekit
Codekit ist eine beliebte Software, die viele Sachen vereint, sämtliche CSS-Präprozessoren sind integriert, zudem JS-Hint/-Lint, Bildkompremierung u.v.m. Ich hatte mir sofort die Beta-Version angesehen und fand es soweit ganz gut. Mit Verlassen der Beta-Phase wurde Codekit kostenpflichtig, kurz danach wurde eine neue Template-Engine in Codekit integriert. Zu dem Zeitpunkt hatte ich mich schon mit Middleman beschäftigt, aber dazu später mehr. Die Template-Language „Kit“ ist meiner Meinung nach nicht ausreichend für etwas komplexere Templates, man kann lediglich einfache „Includes“, sowas wie SSI & Variablen verwenden. Es fehlen aber Schleifen oder If-Else-Bedingungen. Beim Anlegen einer mehr-oder-weniger dynamischen Navigation (beispielsweise mit class="active" für die aktuelle Seite) scheitert man bereits.
Sonst ist Codekit aber ein feines Tool, mit Browser-Reload und allem was man normal braucht.
Prepos
Prepos ist ein Tool, welches ich mal ausprobiert hatte, als ich gezwungen war, vier Wochen in einer Agentur auf einem Windows-Rechner zu coden. Ein Vorteil von Prepos: es ist Windows fokussiert (gibt es aber auch für Mac) und funktioniert wohl ganz gut, soweit ich gehört habe. Mein Problem war, dass ich die Compass-Struktur, die wir in dem Projekt hatten nicht abbilden konnte. So war das Experiement schnell erledigt.
Mixture.io
Mixture hatte ich mir ebenfalls in einer frühen Alpha-Version angesehen und ich war vom Featureset sofort begeistert. Mit Mixture ist es möglich komplexere Templates (mit Partials, etc.) umzusetzen. Die benutzte Template-Language ist Liquid. Zudem kann man mit Mixture neue Projekte mit Vorlagen wie Foundation oder Bootstrap starten.
Mixture unterstützt eine Daten-Anbindung über JSON, so dass man auf Grund von echten Daten statische Templates erstellen könnte. Das ist toll!
Mixture habe ich mittlerweile schon mehreren Kollegen empfohlen und würde es sofort wieder empfehlen, wenn man sich nicht gern auf der Konsole bewegt. Aber dazu sind ja die Tools da, sie nehmen einen die Arbeit mit der Konsole ab, kosten dafür aber Geld. ;)
Middleman
Im Kontext „Static Site Generators” taucht auch schnell Middleman auf. Wie der Name schon sagt, ist das die Software „dazwischen“. Middleman ist Ruby-basiert und unterstützt demzufolge die Ruby Template-Sprachen ERB, HAML, Slim, etc., aber auch Markdown (Kramdown) oder Jade.
Mit Middleman würde auch gleichzeitig Sass und Compass installiert werden, falls man es nicht bereits installiert hat. Middleman hat einen Server-Task, in dem ein kleiner Ruby-Server für Dateiänderungen gestartet wird. Zudem gibt es natürlich einen Build-Task. Auch für Middleman gibt es Vorlagen, mit denen man neue Projekte starten kann. Da das aber Open-Source und Community-getrieben ist, werden hier nicht so oft Updates oder neue Versionen veröffentlicht. Anders bei Mixture.io, dort sorgt die Firma dafür, dass Updates oder neue Template-Vorlagen-Versionen schnell zur Verfügung gestellt werden. Ein USP von mixture.io.
Aber zurück zu Middleman: Weiterhin gibt es für Middleman auch viele Plugins wie middleman-autoprefixer oder middleman-livereload. In der Middleman-Dokumentation werden ERB-Template-Beispiele verwendet. ERB ist für den Einstieg in die Ruby-Template-Engines auch ganz gut, da diese nicht so abstrakt ist wie z.B. HAML. Es sind einige Template-Helper in Middleman integriert. Es können z.B. Platzhaltertexte eingebunden werden, die je Aufruf variieren. Das ist besonders hilfreich beim Erstellen von Responsive Websites, abseits von Lorem Ipsum. In der Konfiguration kann man für den Build-Prozess einstellen, ob JavaScript oder CSS komprimiert und zusammengefasst werden. Middleman unterstützt auch die Rails-Asset-Pipeline sowie Asset-Caching. Eigentlich alles was man für ein statisches Template/eine statische Seite benötigt. Gute Tutorials zu Middleman:
- Understanding Middleman – the static site generator for faster prototyping
- Building static websites with Middleman
Jekyll
Jekyll wird aktuell häufig als statischer „Blogersatz“ verwendet. Das ist in Wirklichkeit auch schon das, was man am besten damit machen kann: Jekyll bietet neben der Möglichkeit Inhalte in Markdown-Dialekten oder HTML in verschiedenen Layouts zu publizieren, hauptsächlich Möglichkeiten, die aus der Blogging-Welt kommen: Kategorien, Tags, Posts und dazu passende Paginatoren. Für Entwickler eignet sich das ganze als Ersatz für WordPress ganz besonders: Jekyll publiziert absolut problemlos auf GitHub Pages (ein Wunder, entstammt doch Jekyll auch aus der Feder des GitHub CEOs Tom Preston-Werner) und hat mit Pygments einen Syntax-Highlighting Präprozessor, der diverse JavaScript-Bibliotheken obsolet macht. Mit Poole ist sogar ein recht brauchbares Starterkit für Jekyll verfügbar.
Will man über die übliche Dokumentation- oder Blogfunktionalität hinaus, stößt man allerdings schnell an die Grenzen des von Jekyll. Zwar kann man sich zahlreicher Plugins bedienen, an die Möglichkeiten die z.B. Assemble (mit Handlebars Helpers) oder Jade bieten, kommt Jekyll nicht heran.
Assemble
Ich habe lang gezögert mich näher mit Grunt zu beschäftigen, da ich letztes Jahr nicht so viel Schnittpunkte mit meiner Arbeit gesehen habe. Ich war und bin mit Middleman äußerst zufrieden und würde wahrscheinlich ausschließlich Middleman nutzen.
Im aktuellen Projekt wird allerdings Grunt für die JavaScript-Entwicklung eingesetzt, was Sinn ergibt. Die Überlegung war nun, ob man nicht die Templates, die für die Module, die clientseitig (mit Javascript) verarbeitet werden, die gleiche Template-Engine nutzen könnte. Bei der Suche nach einer Template-Engine, die das unterstützt, bin ich auf Assemble gestoßen. Assemble nutzt Handlebars als Template-Engine und unterstützt zusätzlich eine Vielzahl an Template-Helpern. Zudem ist die Community recht groß (obwohl das Projekt noch recht neu ist) und es werden für Assemble bereits viele Plugins angeboten. Ich muss das aber erstmal produktiv ausprobieren, Assemble sieht aber sehr vielversprechend aus.
Fazit:
Es fällt mir schwer eine Empfehlung auszusprechen. Ich habe im letzten Jahr mehrere Projekte mit Middleman umgesetzt und werde es sicherlich weiterhin benutzen. Hätte ich mich nicht so sehr mit Middleman angefreundet, gleichzeitig auch mit der Konsole, würde ich aktuell zu Mixture tendieren. Wer viel mit Grunt arbeitet, sollte sich vielleicht Assemble anschauen, das macht für mich aktuell den besten Eindruck als Static Site Generator mit Grunt. Unter http://staticsitegenerators.net/ findet man eine laaaaaange Liste von aktuell 220 Tools.
Eine lustigen Tweet zum Thema hab ich heute auch entdeckt. ;)
the net award for best static site generator goes to Dreamweaver
— jennmoneydollars (@jennschiffer) 29. Januar 2014
Vielen Dank für diesen umfangreichen Überblick. Ich hatte letztes Jahr einen ähnlichen Test gemacht, weil ich mein Kochblog auf Markdown umstellen wollte. An Prototyping hatte ich damals noch gar nicht gedacht. Meine Arbeit sieht ähnlich aus, wie Deine.
Mittlerweile kam ich auch schon auf die Idee, einen solchen Generator zu nutzen bzw. zu testen. Aber ich habe einen anderen Weg gefunden.
Ich entwickele meine Seiten immer mit PHP-Includes. Ich nutze keine Template-Engine, weil so jeder Entwickler, der meine Dateien bekommt, einfach kleine HTML-Schnipsel hat, die er in seine eigene Template-Engine integrieren kann. Und das verwendete PHP ist so minimal, dass es auch Java- und APS-Entwickler nutzen können.
So kann ich – manuell – alles abbilden, auch Verzeichnisse und muss keine Templatesprache erlernen. Sollte dann jemand staische Seiten haben wollen, nutze ich neuerdings das Grunt-Plugin PHP2HTML, das prima funktioniert.
Bei Assemble u.ä. würde mich fürs Protoyping abschrecken, dass das einfach Systeme sind, die dafür nicht vorgesehen sind und eventuell Sachen machen, die ich ihnen erst abgewöhnen muss. Middleman sollte ich endlich mal ausprobieren. Vielleicht macht das die Arbeit noch ein wenig leichter.
Obwohl ich ja dank Grunt und Bowser mittlerweile schon effektiver arbeiten kann, als zuvor. Ich sollte es auch mal aufschreiben :-)
Yeoman ist sicher eines der aktivsten Projekte Open-Source-Projekte zurzeit. Traditionell und da Ruby-basierend verwende ich meist Middleman.
@Jens Assemble hast du noch nicht verstanden und der Vorteil dieser Tools, liegt daran, dass ich Partials und Layouts nutzen kann. Diese Partials können dann auch die Software-Entwickler weiter verarbeiten, die müssen nicht das generierte HTML auseinander schneiden.
@Sven: Ich denke schon, dass ich Assemble verstanden habe. Ich habe damit auch ein paar Stunden herumgespielt. Du hobst auf die statischen Seiten ab. Ich schreibe schon seit JAhren meine Klickdummys nur in PHP-Includes und gebe die so an meine Kunden. Die Entwickler nehmen sich dann nur die Includes, die sie dann zu einem Template wandeln.
Da gehe ich also nicht viel anders vor, als Du. Allerdings mache ich es nicht komplizierter dadurch, dass ich eine Templatesprache nutze, die dann mein Kunde meist nicht nutzt und die die Arbeit dann am Ende nicht wirklich vereinfacht.
Aber wahrscheinlich ist ein Kommentar eh der falsche Weg, um meinen Ansatz zu skizzieren. Ich finde Deinen gut und spannend und werde sicherlich irgendwann herausfinden, ob er mir mehr brächte.