Wer qua Schriftoutput eine wirklich unabhängige Webpräsenz führen möchte, benötigt eigenen Webspace und darauf eine Schreibmaschine, die Webseiten produzieren kann. So können Artikel, Meinungen, Aufrufe und Aktivierungen in jeder Form zeitnah umgesetzt in alle Welt gehen, ohne sich auf die Megaplayer des Web (Meta, Google, Musk,…) oder „App-Anbieter“ verlassen zu müssen.
Allerdings müssen Webseiten nicht nur schriftlich gefüllt, sondern auch in der Fläche gestaltet werden. Farbe und Webtypografie sind wichtig. Die Erfahrung lehrt, dass viel Raum und Ruhe immer gut sind.
Deswegen hiermit der Typo-Typ für das Blog-Template Tokiwa, das mich in seiner Ausgewogenheit, Farbgebung („Minze-Esche“) und Typografie (‚Suhrkamp‘) wirklich überzeugt hat. Als Hugo-Template von He Yeshuang erst im August dieses Jahres aktualisiert, sieht es mit seiner Affinität zu chinesischer Typo („simplified Chinese“) auch mit lateinischen Buchstaben hervorragend aus.
Startseite Template Tokiwa …
Viel Luft, schöner Rhythmus, diskret-angenehme Farbigkeit plus guter Typografie : Hugo-Theme ‚Tokiwa‘ von He Yeshuang (Demo hier) bekommt zehn von zehn Punkten in Webtypografie
… auch mit lateinischen Captions und Formeln:
und kleiner Markdown-Demo unter hugo-theme-tokiwa/post/markdown-syntax/
Was ich an diesem Template auch bemerkenswert finde ist, dass sich nach all den Jahren der Herrschaft von ausschließlich horizontalen Navigationsleisten, hier wieder eine vertikale Navigation abzeichnet.
Als Ergebnis eines statischen Seitengenerators ist auch der Code, also die Materialität der Webseite (Demo hier) vorbildlich schmal.
Jetzt folgt ein nicht so relevanter Rant über Wordpress und den Code, den diese Webschreibmaschine auf die Welt loslässt
Für solch reduzierte Auftritte aber nehmen weiter die allermeisten Wordpress. Aber der Code, den diese Webschreibmaschine ausspuckt ist grausam und völlig verfettet. Die Stromkosten dafür, also das Zusammenbauen im Server aus den Einzelbestandteilen einer der Datenbank, das Übermitteln des Ganzen, die Kosten für Transport und Herunterladen sind relational zum wirklichen Rezeptionscontent völlig overdone.
Der Code von Tokiwa dagegen stammt von Hugo und ist selbstredend ebenso kompakt, klar und ruhig, wie die User-Ansicht, eine sehr schöne Lösung, die sagenhaft stabil ist und praktisch Null Ressourcen benötigt. 👍
Zurück zum Hugo-Theme bzw. statischen Webseiten
Immer mehr kleine Webpräsenzen, etwa solche von Autorinnen, Denkern, Öffentlichkeitsarbeitern, Journalisten, etc. arbeiten heute mit solchen Schreibmaschinen. Statische Generatoren bauen alle Webseiten auf dem eigenen Rechner zusammen und setzen dann das fertige Paket als ‚statische Seiten‘ zum Abruf online. Das Zeug ensteht als Markdown-Datei sagenhaft nah auf dem Schreibtisch und wird vor allem von dort geschrieben, verwaltet, publiziert. Das bietet viel mehr Kontrolle, ist wesentlich datensparsamer, insgesamt schneller, benötigt weniger ‚Vorhaltestrom‘ und ist schließlich – der allergrößte Vorteil – absolut sicher gegen Online-Hacks. Ein Nachteil des Hugo- Systems ist allerdings der eher hakelige Einbau einer Suche auf der jeweiligen Webseite.
Ich muss dazu auch gestehen, dass die Schreibmaschine von cw.com ‚textpattern‘ heißt und dieses System auch per Datenbank läuft, und Sie also gerade das Produkt einer Datenbankabfrage lesen und nicht eine statische .html-Seite. Aber das textpattern-System erlaubt eine durchgehende Kontrolle aller Inhaltselemente, was ebenfalls zu sehr sparsamen Code führt.
Als Befürworter des Permacomputings fordere ich auf, Code auch material zu sehen: Er muss hergestellt, erhalten, transportiert und gelesen werden. Welche Aufwände sind damit verbunden, bzw. wie kann man diese im Sinne von Nachhaltigkeit dauerhaft senken?
Nachtrag, drei Tage später: Hup! 222tsd Zeilen CSS!
Dieses Hugo-Template ist aber leider nicht überall schmal. Das zum Template gehörige zentrale CSS-File umfasst unglaubliche 222tsd Zeilen! Wie man eine solch völlig überfettete CSS_Datei aber wieder trimmenknann, operabel und kline, ohne dass damit wichtige Seiteninhalte eventuell gar nicht mehr dargestellt werden, ist eine Wissenschaft für sich.
Denn nach einer oberflächigen Websuche wird klar, dass der Charakter von CSS _ dass es frei benannt und frei in Kaskaden eingesetzt werden kann, ein ‚reverse engineering‘ fats unmöglich macht. Man kann allenfalls ausgelieferte Codestücke per Server-Logfiles tracken und damit sehen, welche CSS-Teilchunks nicht ausgeliefert wurden und also obolet sein dürften. Es ginbt auch Apps, die jeden möglichen Zustand der Webseite (Viewpoints, Agenten, Unterseiten, Formulare etc.) darstellen und wenn man das dazu ausgelieferte CSS sieht, kann man durch Schnittmengen (bzw. diffs) die kleinstmögliche Angaben-Größe herausbekommen. Das ist nicht unbedingt trivial …