Artikel zum Thema »ssg«

Jekyll 4.1.0

Huch, dieses kleine Nebenblog gibt es ja auch noch!

Das Release von Jekyll 4.1.0 war ein guter Grund, es upzugraden und wiederzubeleben. Jekyll hat in der Version 4 einen ordentlichen Performancesprung gemacht, die Zeit eines jekyll build für mein mittlerweile recht umfangreiches Fußballblog hat sich glatt halbiert.

Das Gem jekyll-paginate-v2 hatte sich beim Upgrade auf Release 4 zunächst als Hindernis erwiesen, weil es seine Dependencies auf Jekyll v3 verdrahtet hatte. Das macht es mittlerweile nicht mehr, aber verhält sich mit der neuen Version 4.1 ziemlich merkwürdig.

Deshalb habe ich ein eigenes Paginierungs-Plugin geschrieben, das hier und auch in den beiden anderen Blogs einwandfrei funktioniert. Die selbstproduzierte Arbeit geht halt nie aus…

jekyll ssg

»JAMstack Fundamentals«

jamstack ssg

Bild: Ladder to sky clouds

Kürzlich hatten wir es hier vom aktuellen Hype-Begriff »JAMstack«. Smashing jetzt auch, in einem ausführlichen Webinar mit einem JAMstack- und »Serverless«-Protagonisten, Phil Hawksworth von Netlify:

JAMstack Fundamentals: What, What And How

Großartig: Smashing liefert eine komplette Transkription des einstündigen Videos mit!

Mr. Hawksworth erklärt das Thema etwas langatmig, aber ziemlich gründlich. Das ganze natürlich aus Sicht von Netlify. Er relativiert dabei den Mode-Begriff »JAMstack« (»Javascript- APIs- and Markup-Stack«) ein wenig (Zitat):

»Because the common misconception is that every JAMstack site has to be JavaScript and APIs, and Markup, but this kind of thing that we’ve overlooked is that we don’t have to use all three — every one one of these is, kind of, optional. We can use as much, or as little of these as we like. In the same way that a LAMP stack site wouldn’t necessarily need to be hitting a data base. Now, I’ve built things in the past that are served by an apache server, on a Linux machine, and I’ve been using PHP, but I haven’t been hitting a database and I wouldn’t start to rename a stack necessarily for that.«

Und hebt auf das seiner Ansicht nach perfekte Zusammenspiel von JAMstack und »Serverless« ab. »Serverless« ist ein anderer Modebegriff, im Prinzip bedeutet das nur, dass man statt eines eigenen Servers den eines Cloud-Anbieters nutzt und sich nicht um den eigenen Server kümmern muss (Zitat):

»Serverless and JAMstack, they just fit together really beautifully.«

Ein empfehlenswertes Video, um die Ideen der Webdevelopment-Glaubensrichtung »JAMstack« etwas genauer kennenzulernen.

Wir »Old-School«-Developer sind naturgemäß etwas skeptisch. Wenn man auf den vollen JAMstack-Pfad geht, erkauft man sich den Vorteil, sich nicht um einen eigenen Server (CMS, dynamische Komponenten…) kümmern zu müssen, mit der Abhängigkeit von diversen Cloud-Anbietern…

(Bild: Samuel Zeller auf Unsplash, thanx!)

Ein Happen Dynamik: isso installieren und in ein statisches jekyll-Blog einbinden

isso python jekyll

Statische Blog-Systeme sind schön und gut, ein bisschen Dynamik braucht man aber schon. Z.B. für Kommentare, auch wenn die große Zeit des Kommentierens in Blogs wohl vorbei ist. Der Meinungssturm tobt heutzutage in Social Media…

Datensammler wie Disqus sind indiskutabel, also denken sich die Leute groteske Sachen aus wie Kommentare mit irgendeinem Formprozessor irgendwo in der Wolke zu verarbeiten und dann daraus einen commit auf ein Github-Repo auszulösen. Sinnvoller erscheinen da schon sich als datenschutzfreundlicher gebende gehostete Kommentardienste wie RemarkBox oder comment.sh.

Letztere bieten eine gehostete Version von isso an, das in meinen Blogs schon länger werkelt isso. Das ist ein Kommentarsystem für den eigenen Server, das man wie disqus und Co. per JavaScript in seine statischen Seiten einbinden kann.

isso funktioniert recht gut, wenn es einmal läuft, es hat aber einen großen Haken: Es ist in Python geschrieben, und es gibt nun einmal (für mich zumindest) nix Schlimmeres als das Rumgemache mit virtualenv, pip, easy_install und den diversen rummäandernden Python-Versionen…

Es begab sich, dass ich isso neu installieren musste und die Erstinstallation damals nicht dokumentiert hatte. Damit das nicht noch einmal passiert, habe ich es diesmal aufgeschrieben und hier abgelegt. Vielleicht ist das ja auch noch für jemanden außer mir nützlich…

Weiterlesen…

Das nächste große Ding: JAMstack

ssg jamstack

Alles in der Welt der Webentwicklung braucht einen griffigen Namen. Mit »Ajax« fing das an…

Als in den letzten Jahren statische Seitengeneratoren wie Jekyll immer populärer wurden und man begann (so wie früher mit Wordpress), jede für diese Technologie geeignete und auch eher ungeeignete Aufgabe damit lösen zu wollen, stellte man fest, dass es ganz ohne »Dynamik« halt auch nicht geht. Man verlagerte die dynamischen Komponenten mangels Backend deshalb mit JavaScript ins Frontend. Statische Seiten enthalten JavaScript, das sich von APIs Daten holt und darstellt. Und schon war der »JAMstack« geboren:

»Modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup.«

Und so denken sich die Leute kühne Konstrukte für ihre Websites aus. Statische Websites werden mit aktuell voll im Trend liegenden javascriptlastigen Generatoren wie Gatsby (das gute alte Jekyll, das meine Blogs allesamt antreibt, ist bei den »Coolen« voll out…) gebacken und aus einem »Headless CMS« wie Contentful mit Inhalten gefüllt. Und das Endergebnis wird bei Hostern wie Netlify abgelegt. Das ist der Fortschritt: Die Abhängigkeit vom eigenen programmierten Backend durch Abhängigkeiten von einem oder mehreren externen Anbietern zu ersetzen…

Wer sich in das Thema JAMstack einlesen möchte, findet bei JAMstack WTF eine schöne bunte Einführung. Und kann staunen, wie schnell es die Webentwicklungs-Community mal wieder geschafft hat, aus der simplen Idee »Wir nehmen einen SSG und backen aus ein paar Dokumenten eine statische Website und werfen diese auf einen Server und freuen uns!« ein kompliziertes Etwas voller externer Abhängigkeiten zu schaffen…