published

Website erneuern

Ich hab mich heute mal hingesetzt und meine Website “runderneuert”. Das alte Design war über zwei Jahre alt und die Seite mit Jekyll, Bootstrap und git-Magie umgesetzt. Nun bin ich auf Hugo umgestiegen und möchte ein wenig dokumentieren was gut lief, was immer noch nicht ganz perfekt ist und welche Entscheidungen die ich ursprünglich getroffen habe gut hinsichtlich Migrierbarkeit waren.

Weg von Jekyll…

Als ich die Seite aufgebaut habe war Jekyll gerade ein Ruby-Script das am Kommen war weil Github sich dazu entschlossen hatte die Github Pages damit zu rendern. Es war irgendwie an allen Ecken und Enden unfertig und das ständige herumbasteln habe ich als extrem unangenehm in Erinnerung. Seitdem hat sich sicher einiges getan, aber damals musste ich mir sogar den RSS-Feed selbst zusammenschustern. Auch fand ich die Performance nie wirklich überzeugend. Im Prinzip ist das egal würde man meinen, aber beim Ursprungssetup wurde die Seite nach jedem Commit neu erzeugt und deployed, wenn das zu lange gedauert hat wurde der Vorgang abgebrochen. Das nerdy Feature hat also ab und zu unangenehme Arbeit verursacht, und bei der überschaubaren Anzahl an Blogposts fand ich das echt miserabel. Ich will hier nicht sagen, dass Jekyll allgemein langsam ist, aber ich war sehr unzufrieden mit der Geschwindigkeit in meinem Fall. Viel schlimmer hinsichtlich Jekyll fand ich, dass die Dokumentation sehr dünn ist. Oder war. Damals sah das alles schon total toll aus und es gab in der Doku auch immer “Pro-Tipps”, die teilweise wirklich essentiellen Sachen hat man da aber häufig nicht gefunden und musste ihnen hinterher googlen. Auch hier weiß ich nicht wie das heute ist, aber vor zwei Jahren hat mich das unglaublich viel Zeit und Nerven gekostet.

… hin zu Hugo

Im neuen Setup soll also Hugo die Seite bauen. Hugo ist tatsächlich recht performant und ich habe die Arbeit damit im Vergleich zu Jekyll als relativ angenehm empfunden. Sicherlich gibts auch hier einige Baustellen und man hat inzwischen schon mehr Erfahrungen mit Static Site Generators im Allgemeinen. Ich hatte einfach das Gefühl, dass Hugo mir beim Erstellen und Verwalten unter die Arme greift während ich Jekyll eher so in Erinnerung habe, dass ich häufig gegen das Tool kämpfen musste um meinen Willen durchzusetzen. Zudem gefällt mir die Dokumentation von Hugo recht gut, das hätte ich mir damals bei Jekyll auch gewünscht. Das Wenigste musste ich tatsächlich auf anderem Wege herausfinden. Zudem gibt es wirklich sehr viele Features und man ist einfach sehr frei in der Gestaltung und wie man Dinge am liebsten handhabt. Was bei Hugo bisher negativ aufgefallen ist ist die Tatsache, dass man offiziell den Feed nicht umbenennen kann. Inoffiziell gibts da die undokumentierte Option RSSUri die das zwar ändert, deren Änderung aber nicht in der Variable RSSLink wiedergegeben wird. Man muss also irgendwie drauf kommen, dass RSSUri schon funktioniert und man sich lediglich den Link zum Feed selbst zusammenbauen muss. Was ich sehr cool fand ist der Template Mechanismus, dadurch lässt sich relativ gut das Aussehen mit vorgefertigten Templates ändern und die lassen sich relativ gut anpassen. Womit wir zu den Punkten kommen die mich heute ein wenig geärgert haben.

No Bullshit

Dieses ganze Web Development ist irgendwie scheiße und ich frag mich immer mehr was in den Köpfen der Leute so vor sich geht. Man beobachtet ja immer wieder diese ganze Community die Dinge wie node.js, npm und den ganzen anderen Ranz geschaffen hat und ist alle zwei Wochen froh, dass man mit dem Zeug nicht arbeiten muss. Ich warte auch nach wie vor drauf, dass raus kommt dass das der größte Hoax in der IT-Geschichte ist und das keiner ernst meint… Da man Websites aber nunmal mit wenig Aufwand und modernen Webtechnologien bauen will, kommt man sehr leicht immer wieder zu Projekten und Arbeitsweisen, bei denen man nur mit dem Kopf schütteln kann.

Die oberste Regel war daher: no Bullshit. Ich will kein CMS oder anderes Zeug abseits des Webservers das ständig läuft. Seit Jahren wissen wir, dass die einzige Idee die dümmer ist als Wordpress zu installieren das Installieren von Wordpress Plugins ist. Trotzdem ist Wordpress mit vielen bunten Plugins beliebt wie nie. Dazu gesellen sich Projekte von Leuten, die der ernsthaften Überzeugung sind, Javascript sei so toll, das müsse man auch außerhalb des Browsers haben. Nein, ist es nicht. Das hat viele Gründe und die gehören auch in einen eigenen Post, daher hier nur: Kein Javascript. Ich brauch es einfach nicht. Nach 20 Jahren Evolution sollten Browser in der Lage sein, selbst zu entscheiden wie sie meinen Content rendern wenn ich ihn sinnvoll darbiete. Und andere tolle Dinge wie Übergänge, Zeug das durch die Gegend fliegt und was man alles machen kann verabscheue ich zutiefst, das will ich keinem hier antun. Wer das gar nicht nachvollziehen kann soll sich bitte diesen Talk durchlesen oder anschauen, dann kann man mich vermutlich besser nachvollziehen.

Ich will nur dass alles klein, performant und aus einer Hand ist. Damit meine ich nicht, dass man CSS gleich so klein wie möglich zusammen presst. Damit meine ich, dass für meine Homepage weder eine Datenbank, ein CMS, memcached, Schriften von Googlefonts, CSS (und meist Javascript) von irgendwelchen Content Delivery Networks und zusätzlich noch ewiges Processing im Browser erfordert. Und an alle diejenigen, die der Meinung sind ihre Homepage/Blog/whatever brauche das: Ihr seid nicht Facebook! An alle Designer die googlefonts und bootstrapcdn hardcoden: Eure User sind nicht Facebook und Google! Und falls doch kümmern die sich selbst um Performance. Ich will einfach keinen Bullshit. Brauchen ansonsten auch <1% der Nutzer. Weg damit.

Gute Entscheidungen

Es gab aber auch freudige Momente beim Umbau, meistens hatten die mit den guten Entscheidungen von damals zu tun. Allen voran: Plaintext bzw. Plaintextformate. Ich liebe es, man kann es immer und überall mit jedem Texteditor oder automatisiert verarbeiten. Man kann es versionieren, diffen, komprimieren (obwohl es eh recht wenig Platz braucht) und benötigt keinerlei Kentniss über ein spezielles Datenformat. Fast.

Die zweite gute Entscheidung ist nun nämlich das auf Plaintext aufsetzende Format das zum Erstellen von Posts benutzt wird: Markdown. Ich habe alle meine Artikel heute gleich nochmal durchgeschaut und alles was nicht schon Markdown war mit Markdown ersetzt. Es ist einfach perfekt auf das Schreiben von Text zugeschnitten, schlanker und lesbarer als HTML und rückblickend kann ich sagen, dass man so ziemlich alles in reinem Markdown niederschreiben kann, so dass daraus sinnvoll HTML erzeugt wird. Ich schätze das ist bei den anderen modernen Beschreibungssprachen wie beispielsweise reStructuredText genauso, aber sich da etwas zu suchen und konsequent dabei zu bleiben erleichtert Lesen, Bearbeiten und Migrieren.

Hinsichtlich Migration war von Vorteil, dass alles als Markdown im Dateisystem organisiert liegt. Ich kann ganz normal auf dem Terminal das Zeug massenverarbeiten und durch die Gegend schieben und es funktioniert einfach. Ich hab kein Gepopel mit Datenbanken oder Datenexport, lediglich normale Dateien in einem Ordner. Das erleichtert auch die Synchronisation, man steckt den Ordner in die Dropbox/Owncloud oder git (in meinem Fall) und hat überall problemlos Zugriff auf alle Revisionen. Einfacher geht es vermutlich nicht und so soll das in meinen Augen auch sein.