Blog mit Gatsby.js und React im JAMStack

3 Minuten Lesezeit
Blog mit Gatsby.js und React im JAMStack

Es fing an mit Jekyll und einer schnellen einfachen statischen Website. Ich wollte schlicht „Hallo“ auf meiner Website sagen. Dazu kam der feste Plan eigenen Content irgendwann dazu zupacken. Jetzt ist’s soweit. Doch statt mit Jekyll und einer bereits schnellen Seite zufrieden zu sein, dachte ich noch ein, zwei Schritte weiter: React und Gatsby sorgen dafür, nur Code zu laden, der für die aktuelle Seite erforderlich ist. Eigentlich logisch, oder? Alle Features im Vergleich sind hier aufgelistet.

Gatsby.js als Startpunkt

Ich stieß irgendwann auf Gatsby und wurde neugierig. Gatsby ist ein Framework als Static Site Generator mit React als Motor. Also genau das Richtige, um schnelle Websites und Apps zu Bauen. Ich muss gestehen, dass für mich die Werkzeuge noch ziemlich ungewohnt sind. Bisher war entweder alles PHP oder Twig gepaart mit JavaScript und SCSS. Auf einmal ist fast alles JavaScript. Damit entfallen auch 90% der Anforderungen an den Webserver, der nun nicht mehr die Seite bauen muss und vorher die Daten aus einer Datenbank holen muss. Es geht jetzt nur noch ums Ausliefern der Site. Netter Nebeneffekt: Diese Architektur ist viel leichter skalierbar.

Gatsby kommt mit kurzer aber guter Dokumentation relativ einfach für Einsteiger daher. Dazu gibt es ein Command Line Interface, dass es einfach macht mit sogenannten Startern ermöglicht, schnell nach vorne zu kommen. Warum ich glaube, dass ausgerechnet Gatsby das richtige Framework für mich ist?

Ich starte mal hier mit meiner Wunschliste (oder meiner ToDo-Liste):

  • Ich möchte auf dieser Seite meinen Content schnell und einfach automatisiert veröffentlichen.
  • Die Datenstrukturen, Komponenten und Templates möchte ich selbst definieren.
  • Die Site soll verdammt schnell sein, und das Maximum an Punkten von Googles Lighthouse Audits kassieren. Also Lazyloading und responsive Picture-Tags sind Pflicht. Browser caching soll ebenso dazugehören.
  • Die Inhalte sollen sichtbar, also auch gut organisch in den Suchmaschinen platziert sein. Neben 301-Redirects, Canonical Tags und Strukturierten Daten dürfen natürlich die Meta Descriptions auch nicht fehlen.
  • Videos kommen auf YouTube und sollen eingebettet werden (Easy, ich weiß). Bilder sollen als Responsive Images durch eine Pipeline aufs letzte Bit optimiert werden. Dabei soll für jeden Viewport das optimale Bild geladen werden. Next Generation Bildformate wie WebP wären auch toll.
  • Inhalte würde ich gerne in Markdown schreiben. Das lässt sich auch schön strukturieren. Die Metadaten kommen als YAML in den Kopfbereich, ins Frontmatter.
  • Google Anayltics via dem Google Tag Manager kommt als Messtool zum Einsatz, natürlich brav nach europäischer Datenschutzvorschrift.
  • Versioniert wird mit Git, geteilt wird auf Gitlab und deployed wird mit den CI/CD-Tools auch von GitLab.
  • Die Lesezeit sollte angezeigt werden.
  • Related Content sollte nach den Artikeln angezeigt werden.
  • Kommentarfunktionen zum Austausch wären bestimmt auch gut!
  • Außerdem möchte ich ein einfaches Formular für eine Newsletteranmeldung implementieren.
  • Hübsch sollte die Seite auch werden. 💅

So, und das alles sollte mit Gatsby machbar sein. Mein Ziel ist ein starter, so heißen die Boilerplates bei Gatsby, zu definieren und zu teilen. Der Focus soll dabei die Infrastruktur und ein Minimum an Tools umfassen. Layouts und Content sollen nicht enthalten sein, damit es universell einsetzbar bleibt.

Warum nicht einfach WordPress?

Ein paar Punkte aus meiner Liste würden grundsätzlich Wegfallen, da sie nicht umsetzbar wären. Die schnelle Ladezeit wäre ein gutes Beispiel. Hier kann man bei WordPress wirklich nur Punkten, wenn man sich auf andere Caching Plugins verlässt. Ein anderes Beispiel wäre das Templating und Theming mit PHP und WordPress‘ Funktionsaufrufen.

Klar, es ist schnell installiert. Aber ich glaube man wirft sich mit diesem System und Herangehen im Jahr 2019 in technische Schulden. Man ist einfach abhängig von vielen verschiedenen Stellen, um auch längere Zeit mit allen wichtigen Sicherheits-Patches weiterhin versorgt zu bleiben. Dazu zählen auch möglicherweise Parent-Themes und Plugins, die in Verwendung kommen. Bricht über Zeit eine Komponenten nur weg, ist der Aufwand plötzlich viel viel Höher. Worst-Case-Szenario: Migration zu anderen Systemen.

Und nun?

Mein Plan ist einfach: Ich nehme die Liste von oben als ToDo-Liste und gehe Punkt für Punkt ab und berichte etwas darüber, wie ich vorgegangen bin. Was gabs schon fertig als Plugin? Was hab ich selbst bauen müssen/können? Die Ergebnisse teile ich gern mit euch!