#21 Static Site Generators & DIE Webseite

Statische Websites sind wieder cool und wir springen mit der eigenen Website direkt auf den Hype.

Eine Episode mal in (teilweise) eigener Sache: Nach 6 Monaten und 20 Episoden haben wir eine eigene Website gebaut. Mit einem Static Site Generator. Wieso wir eine eigene Website haben wollen, was wir uns davon erhoffen, wie der technische Unterbau aussieht, wo wir recht dreckige Hacks eingebaut haben, was Static Site Generatoren sind und wozu sie eigentlich gut sind, bei welchen Use-Cases diese nicht geeignet sind und warum ein Produkt-Name zu Weltraum-Ergebnissen bei Google führen kann, klären wir in dieser Episode.

Bonus: Was die Toten Hosen, Broilers und Rammstein mit Static Site Generators zu tun haben und wieso Österreich so gut im Marketing ist.

Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk

Sprungmarken

(00:00:00) Intro

(00:03:59) Die Engineering Kiosk Website: engineeringkiosk.dev

(00:04:44) Historische JavaScript-Frameworks: MooTools, Prototype.js und script.aculo.us

(00:06:40) Andys Agentur-Background

(00:07:32) Warum braucht der Engineering Kiosk eine Website?

(00:14:37) Warum haben wir jetzt erst eine Website?

(00:16:06) Die Technik hinter der Engineering Kiosk Website

(00:21:00) Was ist ein Static Site Generator?

(00:31:29) Kritik am Static Site Generator Hugo

(00:34:56) Welcher Static Site Generator wurde für die Engineering Kiosk Website verwendet?

(00:39:09) Was ist das coole an Astro und wie wurde Website umgesetzt?

(00:41:30) Wie bekommen wir die Podcast Episoden in die Website rein?

(00:46:06) Technischer Unterbau mit Astro, tailwind, Python, Netlify

(00:50:05) Feedback und Contribution zum Engineering Kiosk Website Setup

(00:52:29) Outro

Hosts

Wolfgang Gassler (https://twitter.com/schafele)
Andy Grunwald (https://twitter.com/andygrunwald)

Engineering Kiosk Podcast: Anfragen an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Andy Grunwald (00:00:02 - 00:00:58)

Episode 21 vom Engineering-Kiosk. Heute mal ne richtige Kiosk-Folge. Wolfgang und ich sprechen über ein Thema, wo wir beide wirklich wenig Ahnung von haben. Frontend. Das ganze machen wir nicht freiwillig, sondern eher in eigener Sache. Nach knapp 6 Monaten und 20 Episoden haben wir eine eigene Webseite am Start. Ich freue mich wie Bolle, ich sag's euch. Gebaut mit einem Static-Side-Generator. Und das sind auch schon unsere Themen. Warum denken wir, dass wir eine eigene Webseite brauchen? Warum hat das ganze sechs Monate gebraucht? Wie sieht der technische Unterbau aus und welche Hipster-Technologie wurde verwendet? Was ist eigentlich ein Static Site Generator und wozu ist er gut oder auch schlecht? Bei all dem klären wir auch noch, was die Toten Hosen, die Broilers und Rammstein mit Static Site Generators zu tun haben, warum Österreich richtig gut im Marketing ist und ob Buhl der neue Kneipensport wird. Wir springen direkt rein. Viel Spaß! Was ist das letzte was du gelernt hast Wolfgang?

Wolfi Gassler (00:00:58 - 00:01:11)

Boule, gestern, das erste mal Boule gespielt, ich glaube es heißt Boule oder mit diesen Kugeln, wo man diese andere Kugel probiert zu treffen, das was in Frankreich so alle alten Menschen spielen, ich bin jetzt auch langsam so alt, hab das in Amsterdam in einer ganz hippen Bar gespielt.

Andy Grunwald (00:01:11 - 00:01:19)

Und kannst du bitte die Szenerie mal von dieser hippen Bar beschreiben, ich würde gerne wissen ob das jetzt ein Hipster Trend ist, den ich bald auch in Deutschland zu erwarten habe?

Wolfi Gassler (00:01:20 - 00:01:41)

Es war relativ cool, es war so eine klassische Bar und da hat es ja viele Spiele gegeben und einfach drei Subul-Bahnen mit Schotterfläche am Boden und man hat sich die mieten können und halt auch Bier trinken und dann waren noch so Streetfood-artige Stände, wo man Streetfood bekommen hat. War alles relativ klein, aber eigentlich sehr cool, ja.

Andy Grunwald (00:01:41 - 00:01:44)

Weißt du denn, was ich dieses Wochenende gemacht habe?

Wolfi Gassler (00:01:44 - 00:01:47)

Du warst Kegeln unter sehr viel Biereinfluss.

Andy Grunwald (00:01:47 - 00:01:56)

Nein, ich habe uns für unser Side Project Engineering Kiosk eingesetzt. Ich habe Tag und Nacht durchgearbeitet, nur für uns, für unseren Erfolg.

Wolfi Gassler (00:01:57 - 00:02:15)

Ich würde jetzt gerne sagen, das ist weit übertrieben, aber nachdem man mittlerweile mit GitHub so gut informiert wird und ständig Notifications bekommt, wenn irgendwas geclosed worden ist oder ein neues Commit kommt, und wenn ich ständig diese Notifications am Handy bekommen habe, dass da irgendwas passiert ist, muss ich dir, glaube ich, leider recht geben. Du hast wirklich das ganze Wochenende gearbeitet.

Andy Grunwald (00:02:15 - 00:02:35)

Für die Hörerinnen und Hörer ein bisschen Kontext. Der Wolfgang und ich teilen uns ein Slack-Workspace. weil ihm meine nachrichten im whatsapp so auf die eier ging weil er nicht die whatsapp nachrichten auf andre setzen konnte und dann mit threads da arbeiten kann und dann nach und nach antworten kann.

Wolfi Gassler (00:02:35 - 00:02:38)

Ordentliche strukturierte kommunikation nennt sich das und.

Andy Grunwald (00:02:38 - 00:03:08)

Er hat dann gemeckert ich übersehe immer alles okay dann hat er sich ein slack workspace eingerichtet mich eingeladen hat wir da sind nur wir beide drin, Wir haben aber sieben Channels oder so. Und er hat eine ... Er hat einen Gitterbot reingeholt, was natürlich bei jedem Commit auf jedem Branch und bei jedem Ticket irgendeine Pushnachricht in den Slack packt. Und deswegen ist der Wolfgang eigentlich schon so ein kleiner Spion oder Stalker von mir. Zumindest am Wochenende, hab ich das Gefühl.

Wolfi Gassler (00:03:08 - 00:03:19)

Ich hab gerade mal gecheckt, die letzten 30 Tage haben wir 3.189 Messages im Slack gesendet. Zu zweit. Wobei da die Bots vielleicht mitgezählt sind, da bin ich mir jetzt nicht ganz sicher.

Andy Grunwald (00:03:19 - 00:03:21)

Aber du kriegst auch eine Analyse pro Person, oder?

Wolfi Gassler (00:03:21 - 00:03:26)

Nur in der kostenpflichtigen Version. Die können wir uns leider nicht leisten. Zu viele User.

Andy Grunwald (00:03:26 - 00:03:30)

Aber 3.000 Nachrichten ist jetzt erstmal nur eine Zahl. Ist das viel oder wenig?

Wolfi Gassler (00:03:30 - 00:03:35)

Für 30 Tage, das sind im Durchschnitt 100 Messages am Tag. Ist eigentlich ganz gut.

Andy Grunwald (00:03:36 - 00:03:42)

Die ein oder andere Community, beziehungsweise Gruppe an Menschen in Slack, die sich Community nennt, hat weniger.

Wolfi Gassler (00:03:42 - 00:04:03)

Definitiv, aber da gibt's ja nicht so aktive Leute wie dich, die die ganze Zeit irgendwas schreiben und irgendwelche Links posten, die so durch die Welt fleuchen. Ich kann da mal kurz zitieren, zum Beispiel aus dem Random Channel ist gestern irgendwas mit Knifte und Stulle wieder dahergekommen, wo mir der Andi irgendwas erklären wollte. Also solche Messages sind da vor allem unterwegs.

Andy Grunwald (00:04:03 - 00:04:17)

Okay, zurück zum Thema. Was habe ich dieses Wochenende gemacht? Ich habe mich dieses Wochenende hingesetzt und fokussiert an der Engineering-Kiosk-Webseite gearbeitet. Tada!

Wolfi Gassler (00:04:19 - 00:04:21)

Ist was Gutes dabei rausgekommen?

Andy Grunwald (00:04:21 - 00:04:27)

Ich habe es deployed. Ich habe es geschippt. Ihr könnt das Resultat unter engineeringkiosk.dev sehen.

Wolfi Gassler (00:04:27 - 00:04:50)

Also ihr könnt jetzt direkt auf engineeringkiosk.dev gehen und die neue Webseite von Andi bewundern. Alles, was ihr an Feedback habt, wenn irgendwas nicht klappt, bittet direkt an Andi. Nein, diese E-Mail-Adresse gibt es nicht. Ihr müsst sie ja stetig an engineeringkiosk.dev schicken. Oder direkt auf Twitter könnt ihr direkt den Andi adressieren, was er falsch gemacht hat. Aber ich muss dazusagen, meiner Meinung nach ist sie wirklich gut geworden.

Andy Grunwald (00:04:50 - 00:04:58)

Habt bitte Mitleid. Eine Infrastruktur-Backend-Person hat 2022 versucht, Frontend zu machen.

Wolfi Gassler (00:04:58 - 00:05:02)

Moment, Moment, Moment. Du bist aufgewachsen in einer Webagentur.

Andy Grunwald (00:05:03 - 00:05:17)

Ich habe die WEG Agentur vor neuneinhalb Jahren verlassen. Vor neuneinhalb Jahren waren immer noch so Sachen wie jQuery, Prototype, Mutools, Scriptaculous und Co. am Start.

Wolfi Gassler (00:05:17 - 00:05:25)

Oh, was ist Scriptaculous und Mutools? Ich glaube, das musst du erklären. Ich habe keine Ahnung, ob das jeder oder jede von unseren Hörerinnen noch kennt.

Andy Grunwald (00:05:26 - 00:06:09)

Mit jQuery konnte man immer so tolle Animationen machen, wie bewegt dieses Element von rechts nach links oder oben in die rechte Ecke oder ähnliches. Oder wenn du da drauf geklickt hast, dass das wegfaded. Scriptaculous war noch davor. Das war so 2010 bis 2012 oder ähnliches. Da konnte so ein Browser das alles noch gar nicht. Und die Jungs und Mädels von Scriptaculous, die haben da richtige Magie gemacht. Und da musstest du richtiges Tuning betreiben, damit die Browser das ruckelfrei hinkriegen. Und die ganzen Kunden, die wollten natürlich so was. Und Mootools war da auch ganz groß, bevor dann wirklich mal jQuery kam und das dann, ich will nicht sagen, ordentlich gemacht hat, aber ich glaube, schon sehr viel aus Scriptaculous und Mootools und Prototype.js gelernt hat.

Wolfi Gassler (00:06:10 - 00:06:22)

Also ich glaube, Mood Tools war nach jQuery, oder? Das war eigentlich so eine, wo man schon komplexere Dinge dann schreiben konnte, was so Backbone, Backbone.js Zeiten waren.

Andy Grunwald (00:06:22 - 00:06:29)

Ja, ich glaube, die, ich glaube, die Nachfolger waren dann, waren dann so Backbone.js, Lodash und solche Geschichten, genau.

Wolfi Gassler (00:06:30 - 00:06:49)

Mein anderes Side-Project, das F-Online-AT, diese Führerschein-Lernplattform, die ich schon öfters erwähnt habe, die läuft noch auf Marionette. Das ist ein Framework, was auf Backbone aufsetzt. Läuft noch einwandfrei, sehr gut, muss man sagen. Außer wenn ich was ändern muss, dann ist es der ziemliche Horror.

Andy Grunwald (00:06:49 - 00:07:36)

Aber in der tat mein mein background ist ne klassische webagentur mit damals mit der focus auf typo 3 natürlich habe ich auch hier und da ein bisschen wordpress gemacht und alles was dazu gehört ja und landing pages etc etc aber damals stand ich schon auf kriegsfuß mit css und. Ja javascript ist nicht so aber ich sag das javascript damals ein anderes javascript war als das was man heute hat und somit war ich zu circa neuneinhalb zehn jahre eigentlich gar nicht mehr so tief in der in der frontendwelt drin klar hier und da man mpm install und so weiter und sofort und Auch mal ein Jeopardy-Game, irgendwie ein paar Sachen gefixt und, nein, alles was dazugehört, aber mal so eine richtige Webseite mit Tailwind und JIT-Compiler und Frontmeta und was nicht da noch alles zugehört.

Wolfi Gassler (00:07:36 - 00:08:25)

Ich bin ja schon froh, dass du nicht mit Flash angekommen bist oder so, wie wir vereinbart haben, dass du die Webseite machst. Aber vielleicht würden wir mal, bevor wir da in die technischen Details reinspringen, mal einen Schritt zurückgehen. Warum brauchen wir denn eigentlich eine Webseite? Warum haben wir entschieden überhaupt, dass wir eine Webseite brauchen? Weil eigentlich das, was wir so bekommen von der Podcast Hosting Plattform, also in unserem Fall Red Circle, die uns die Plattform zur Verfügung stellen, dass wir das Podcast distributen können, Also was eigentlich heißt, ein RSS-Feed generieren aus unseren mp3-Dateien und vielleicht noch die Download-Zahlen-Tracking. Also das nennt sich dann die Red Circle Plattform in unserem Fall. Und die bieten natürlich auch eine kleine Webseite an, wo man die Episoden runterladen kann, anhören kann. Also das hat schon funktioniert. Also warum eine eigene Webseite überhaupt?

Andy Grunwald (00:08:25 - 00:08:50)

Also wer ein podcast starten möchte redcircle.com für die ersten 20 folgen für die ersten sechs monate haben wir uns voll auf diese plattform verlassen und bereuen es nicht und haben dort auch die standard webseite von denen genutzt da haben wir eigentlich unsere topper domain drauf gelenkt da konntest du alle episoden sehen alle episoden anhören auch die show notes lesen, hat eigentlich recht geklappt.

Wolfi Gassler (00:08:50 - 00:08:57)

Jetzt sagst du auch schon die die episoden ansehen anschauen hast du dir letztes mal noch beschwert dass wir in österreich die episoden anschauen?

Andy Grunwald (00:08:58 - 00:09:03)

Jetzt wo du das sagst würde mich aber wirklich mal interessieren wie viele leute dann wirklich auf diese website gegangen sind das können wir leider nicht sehen.

Wolfi Gassler (00:09:03 - 00:09:40)

Und da haben wir schon ein großes Problem, warum wir auch eine eigene Webseite wollen, weil die Visibility einfach extrem schlecht ist und wir keine Ahnung haben, ob wirklich Leute zum Beispiel die Webseite verwenden, ob die dort auf den Playbutton drücken oder ob alle Leute nur in der eigenen App, Spotify, Bucketcasts, Apple, wo auch immer das Podcast hören. Oh, ich muss übrigens der Podcast sagen. Hat ein Hörer sich ganz stark bei mir beschwert, dass wir oft das Podcast sagen. Es heißt der Podcast. Und der kommt sogar aus Österreich. Ich habe gedacht, in Österreich sagt man immer des Podcast. Aber es ist der Podcast. Also ganz wichtig. Steht auch im Duden zu drinnen.

Andy Grunwald (00:09:41 - 00:09:47)

Der Duden ist ja nicht das Regelwerk, wie man das schreibt, sondern nur eine Empfehlung, oder?

Wolfi Gassler (00:09:47 - 00:09:48)

Keine Ahnung, du bist der Deutsche.

Andy Grunwald (00:09:48 - 00:09:51)

Soviel ich weiß, ist der Duden nur eine Schreibempfehlung.

Wolfi Gassler (00:09:51 - 00:10:08)

Also der Duden gilt ja in Österreich grundsätzlich schon mal nicht, weil es gibt ja das österreichische Wörterbuch, das ist ja das Pendant des Dudens, aber keine Ahnung, ob es das noch wirklich gibt und ob man da online das checken kann, aber wir in der Schule hatten das österreichische Wörterbuch, das war so ein grünes Ding, hat jeder bekommen bei uns in der Schule.

Andy Grunwald (00:10:09 - 00:10:16)

Wird das noch aktualisiert, weil der Duden hat ja zum Beispiel Worte wie googeln drin und so weiter. Steht sowas auch im österreichischen Wörterbuch?

Wolfi Gassler (00:10:16 - 00:10:37)

Ja, keine Ahnung, ob das mittlerweile sich erledigt hat oder ob man nur dem Duden vertraut. Bitte an all die Österreicherinnen dort draußen, falls ihr da eine Info habt, bitte lasst uns doch wissen. Gibt es das österreichische Wörterbuch noch? Ich kenne auch leider keine so jungen Leute, ob man das heutzutage noch bekommt. In der Grundschule heißt es bei euch, bei uns heißt es Volksschule. Ist ja was für das Volk.

Andy Grunwald (00:10:37 - 00:10:45)

Ich weiß nicht warum, aber irgendwie muss ich jetzt an folgenden Witz denken. Das haben die Österreicher doch prima hingekriegt. Aus Hitler haben sie einen Deutschen gemacht und aus Beethoven einen Österreicher.

Wolfi Gassler (00:10:46 - 00:11:01)

Ja, das zeigt nur, dass wir extrem gut im Marketing sind und im Tourismus. Ihr kommt ja nicht umsonst immer nach Tirol zum Skifahren und zum Wandern. Ist ja klar, im Marketing können wir. Definitiv. Außerdem, warum ist das eigentlich ein Witz? Wo ist das Problem?

Andy Grunwald (00:11:01 - 00:11:04)

Wenn du sagst Marketing, dreht ihr die Corona-Geschichte jetzt eigentlich irgendwie?

Wolfi Gassler (00:11:04 - 00:11:11)

Ja, es waren ja nicht wir, die mit Ischgl den Virus verbreitet haben, sondern ihr Deutsche, die in Ischgl den Virus aufgenommen habt und dann verbreitet habt.

Andy Grunwald (00:11:11 - 00:11:55)

Wir werden jetzt am besten mal kein Pandemie Leugner Podcast, weil sonst werden wir bestimmt auch auf Spotify gesperrt. Deswegen zurück zur Webseite. Warum haben wir eine Webseite gemacht und warum auch erst jetzt? Und zwar haben wir sehr viele Hörer durch unser Netzwerk bekommen und sehr viele Hörer auch durch Twitter und Reddit. Doch irgendwann merkt man in der Kurve, neue Hörer zu kriegen. Da ist so langsam Flaute, weil wir haben gefühlt alle Marketingkanäle, die uns so einfallen, schon ausgeschöpft. Natürlich kann man die konstant bespielen, aber wir machen auf jeden Fall immer noch ein Audioformat und Suchmaschinenoptimierung und Audioformat ist ein bisschen schwierig ohne eigene Webseite.

Wolfi Gassler (00:11:55 - 00:12:05)

Noch zumindestens. Vielleicht arbeitet Google schon dran, aber bisher gibt es mal noch keine automatische Transcription von allen Podcasts. Meines Wissens zumindestens.

Andy Grunwald (00:12:05 - 00:12:16)

Und auch wenn es das geben würde bin ich mir nicht sicher ob die pottisch und deine sprache, ob es denn wirklich tief österreichisch ist weiß ich auch nicht wirklich gut transkripten können.

Wolfi Gassler (00:12:17 - 00:12:29)

Ja, ein Freund von uns hat gerade probiert, eine Episode zu transkribieren, automatisch, mit einem Tool. Es war nicht so schlecht wie erwartet, aber es ist schon sehr österreichisch gescheitert, muss man schon dazu sagen.

Andy Grunwald (00:12:29 - 00:13:15)

Die Grundidee war, die ganzen Folgen, die ganzen Episoden, die wir haben, auf die Webseite zu packen, dass man die sich da auch anhören kann, dass die Shownotes natürlich dann auch mit der Top-Level-Domain-Engineering, kiosk.dev, indexiert werden und dass wir ein bisschen Suchmaschinenoptimierung kriegen, weil Das ganze CEO war natürlich vorher auf der Red Circle Domain, was wir aber so langsam mal auf unserer Domain haben wollen. Die zweite Geschichte ist, dass wir vorhaben, ein paar Blogposts zu schreiben mit speziellem Fokus auf die Episoden, die wir so gemacht haben, weil wir hier und da Hörer-Feedback bekommen haben. Hey, super tolle Sachen, die ihr da im Podcast macht. Doch irgendwie ist das alles ein bisschen viel. Wenn ich euch 40, 45, 50 Minuten zuhöre, dann habe ich immer zehn Sachen, die ich gleich ausprobieren möchte. Mal so ein Write-Up von der ganzen Thematik wäre ganz gut.

Wolfi Gassler (00:13:15 - 00:13:51)

Und Andi schreibt ja auch extrem gerne. Alle, die uns brav verfolgen und immer hören, wissen das ja schon, dass der Andi ein großer Befürworter des Schreibens ist. Und es ist natürlich schon ein zusätzlicher Channel, den wir da einfach aufmachen können, weil nicht jeder ist im Audioformat zu Hause. Und wenn man mal irgendwie eine Info braucht oder so, kann man halt auch im Idealfall danach googeln und findet in einem unserer Shownotes vielleicht eine Antwort oder einen Link oder vielleicht eben auch in einem Blogpost, dass dann die jeweils die Frage beantwortet. Also da probieren wir auch schon, den zweiten Channel zu nutzen und den Text-Channel auch zu bespielen.

Andy Grunwald (00:13:51 - 00:14:12)

Ich finde Schreibskills unglaublich wichtig, nicht nur beim Bloggen, sondern eigentlich auch primär bei der Arbeit, speziell bei der asynchronen Arbeit, speziell bei der Remote-Arbeit. Leider nehme ich mir nie so viel Zeit fürs Schreiben, wie ich wirklich gerne möchte, aber so muss man sich auf jeden Fall zwingen, um seine Schreibskills zu trainieren.

Wolfi Gassler (00:14:12 - 00:14:33)

Und den anderen Punkt natürlich mit der Visibility, was wir schon besprochen haben, dass wir einfach die Kontrolle über das Ganze haben und einfach auch mal einen Tracker einbauen können, Analytics, einfach wissen, wie wird unsere Webseite verwendet, wie wird der Podcast gehört, damit wir da einfach mehr Infos bekommen, die uns dann auch helfen, mit dem Podcast weiterzumachen.

Andy Grunwald (00:14:34 - 00:14:52)

So, auf jeden Fall die Idee. Schauen wir mal in drei, vier, fünf Monaten, wie viele Blogposts wir wirklich haben. Vielleicht bleibt es auch einfach bei keinem Blogpost und das war nur eine tolle Idee. Aber nur gut. Aber Wolfgang, sag mir mal, sag mir bitte ganz kurz, warum haben wir jetzt erst eine Webseite? Ich meine, wir quatschen ja schon ein paar Monate.

Wolfi Gassler (00:14:53 - 00:16:29)

Ja, es hat natürlich mehrere Gründe. Wir haben es ja auch am Anfang schon mal erwähnt, wir wollten möglichst lean starten, das heißt nicht viel Zeit investieren, sondern möglichst schnell den Podcast rausbringen, Episoden shippen, wie der Andi so schön immer sagt, shipp it. Und jetzt sind doch schon 20 Folgen vergangen, das heißt ungefähr fünf Monate jetzt. Und wir hatten ganz einfach bisher kaum die Zeit, um sowas aufzubauen, weil schlussendlich braucht es dann doch immer irgendwie länger, als man so denkt. Und die Red Circle Seite war ja vorhanden, das heißt, wir hatten grundsätzlich eine Webseite. Und jetzt haben wir uns aber einfach dazu entschlossen, okay, es macht Sinn, diese Arbeit zu investieren und in dem Fall danke Andi. Andi hat die ganze Arbeit gemacht, weil ich ja vor allem Schneiden übernehme, hat Andi gesagt, okay, er, obwohl er keine Ahnung von dem ganzen Frontend-Zeug hat, ich habe doch ein paar Frontend-Sachen in letzter Zeit auch gemacht, notgedrungenermaßen, bin auch kein Profi, aber er hat gesagt, ich als Backendler werde mal wirklich probieren, was ich so hinbekomme. Und das ist jetzt auch unser Thema für heute, um mal so einen Einblick zu bekommen, wenn jemand, der gar nicht so up-to-date ist mit diesen Frontend-Tools und eigentlich aus dem Backend-Bereich kommt, probiert eine Webseite zu bauen. Was kommt dabei raus? Wie sind die Erfahrungen? Und ist das Ganze sinnvoll, was dann am Ende rausbootselt? Das könnt ihr dann selber entscheiden, wenn ihr auf die Webseite geht. Aber starten wir mal mit der Technik dahinter. Andi, du als Backend-Mensch, SRE, wie bist du die ganze Sache angegangen und was hast du verwendet? Ist jetzt kein Test, also du kannst jetzt wirklich sagen, was du einfach verwendet hast. Ich werde jetzt nicht automatisch dann immer berichtigen, was du verwenden hättest sollen.

Andy Grunwald (00:16:30 - 00:17:53)

Ganz am Anfang standen zwei große Fragen und Entscheidungen. Die erste Frage ist, welches Template nutzen wir? Denn der Wolfgang hat Geschmack wie stinkende Socken und ich und Design, sorry, das wird einfach auch nichts. Ich habe auch keinen Stil. Und Punkt ist, Wolfgang und ich haben einfach nichts für Design über. Wir sagen, das sieht gut aus, das sieht toll aus, aber selbst ein Design erstellen, ich glaube, da gibt es deutlich bessere und talentiertere Personen als wir beide. Deswegen haben wir uns auf ein fertiges Template verlassen. Da ging erstmal die große Recherche los. Okay, kaufen wir ein Template? Gibt es irgendwo ein freies Template? Da habe ich einfach ein paar Vorschläge gemacht und wir haben uns auf ein Template geeinigt. Es nannte sich Podcast X Template von Webflow. Webflow ist so ein Homepage-Buchkasten unter anderem. Und im Endeffekt haben wir dieses Template nicht genommen. Wir haben dann ein anderes Template genommen, weil der Wolfgang irgendein Service gekauft hat. Nennt sich Shuffle.dev. Shuffle.dev ist ein Online-Service für die Erstellung von Templates mit CSS-Frameworks wie Material-UI, Tailwind, Twitter-Bootstrap und so weiter und so fort. Und da kann man seine Komponenten zusammenziehen. Und dort gab es ein Template, was sehr ähnlich mit diesem PodcastX-Template aussah. Und das haben wir dann einfach genommen.

Wolfi Gassler (00:17:53 - 00:19:21)

Vielleicht als Hintergrund, warum wir das vorgefertigte Template nicht genommen haben. Es war jetzt nicht teuer gewesen oder weiß sogar gratis. Nein, ich glaube es hätte was gekostet, aber das war jetzt nicht das Problem gewesen. Meine Erfahrung ist einfach mit diesen Templates, dass die sehr gut ausschauen, gar keine Frage, aber man muss sich immer im Detail den Code anschauen, wie gut er wirklich dahinter zusammengestöpselt ist auch. Weil wenn man dann irgendwas customizen will, ist es teilweise extrem schwierig und darum war es uns eigentlich auch wichtig, dass wir irgendwie auf Tailwind zum Beispiel, also einem CSS-Framework aufbauen, damit wir im Falle, wenn wir was ändern wollen, das auch sinnvoll ändern können, ohne da sich komplett in ein neues Framework einzulesen. Tailwind kennen wir schon, oder ich zumindestens, habe da sehr gute Erfahrungen damit gemacht. Manchmal verwenden diese Templates gar kein Framework oder irgendein sehr altes Framework oder sind dann wirklich extrem customized, dass man kaum etwas anpassen kann und man macht dann immer sehr viel kaputt, wenn man was anpasst. Und darum wollten wir einfach einen sauberen Start haben, damit wir da auch möglichst flexibel sind. Und darum haben wir eigentlich auf Tailwind gesetzt, beziehungsweise zusammen mit diesem Shuffle, was eigentlich nur so ein visueller Editor ist, eigentlich für so Templates, dass man da was zusammenstellen kann und dann auch schnell ändern kann und in Zukunft sind wir dann komplett flexibel und können jederzeit etwas customisen, dazubauen und da sind wir eigentlich üblicherweise dann einfach schneller und darum würde ich das auch stark jedem empfehlen, auf so ein Framework aufzusetzen.

Andy Grunwald (00:19:21 - 00:19:32)

Das war die erste frage temple ausgesucht wahnsinn die zweite frage und da gab es mehr streit zwischen wolfgang und mir. Welche plattform nehmen wir denn welche technologie nehmen wir denn was heißt was heißt.

Wolfi Gassler (00:19:32 - 00:19:34)

Streit ich wurde einfach overruled.

Andy Grunwald (00:19:34 - 00:20:16)

Overruled pass mal auf ich hab hier ich hab hier ein kompromiss gemacht und den kompromiss erzähle ich dir jetzt ich war infrastruktur bedingt. bin ich sehr nah an der sprache gogolang von google und wenn man go und static site generator in einem satz erwähnt dann ist da nur eine antwort die nennt sich hugo der wolfgang wollte irgendwas javascript basiert ist der der der fing mit an der fing mit gatsby an und nax js next js und so weiter und so fort und Javascript und ich, wir kennen uns, sind jetzt aber noch nicht so oft essen gegangen, als dass wir sagen können, best friends forever. Auf jeden Fall hab ich mich dann weichschlagen lassen und habe nicht Hugo genommen.

Wolfi Gassler (00:20:16 - 00:20:17)

Warum nicht?

Andy Grunwald (00:20:17 - 00:21:05)

Weil du es primär nicht wolltest. Du wolltest irgendwas Javascript-basiertes. Und ich hab mir gedacht, da hab ich mir Next.js und Nuxt.js und Gatsby angesehen, und das sind ja schon wirklich ... Das sind ja keine klassischen Static-Site-Generators, sondern schon sehr, sehr nah an wirklich Application-Frameworks. Wo man auch wirklich große Dinge mitbauen kann und da habe ich gesagt ich will jetzt aber hier nicht wirklich alles von neu aufbauen eigentlich brauche ich ja nur einen Block oder eigentlich brauche ich ja nur zwei Blocks und zwar einmal einen wirklichen Block und dann einmal die Postkastepisoden, die ja auch nur irgendwie ein Block sind nur dass du da keinen Artikel hast, Sondern die Shownotes, was ja auch ein Artikel irgendwie ist, und ein Player. Und vielleicht ein paar Kapitelangaben und so weiter und so fort. Aber eigentlich sind das zwei Blocks in einem Framework. Dafür brauche ich ja keinen Next.js, Nuxt.js und wie sie alle heißen, um ein richtiges Applikationsframework zu bauen.

Wolfi Gassler (00:21:07 - 00:21:22)

Erklär mal schnell, was ein Static Site Generator überhaupt ist. Warum? Wenn du klassisch eine Webseite machst, könntest du ja auch, keine Ahnung, WordPress oder so verwenden. Was ist denn ein Static Site Generator? Und warum waren wir da beide eigentlich sofort auf einem grünen Zweig, dass wir einen Static Site Generator verwenden?

Andy Grunwald (00:21:23 - 00:23:05)

Static Site Generator ist eigentlich eine vorgenerierte Webseite. Man hat jetzt also keine dynamische Webseite, sondern wirklich statischen HTML-Code auf irgendeinem Server liegen. Man hat unten drunter zum Beispiel seinen, nehmen wir mal einen ganz klassischen Block. Ein Block hat Artikel. Diese Artikel werden zum Beispiel in Markdown-Files geschrieben und dann drückt man auf Generate. Und dann geht der Static Charts Generator hin, nimmt sich alle Markdown-Files, überführt den Inhalt in ein vorgefertigtes Design und spuckt fertige HTML-Dateien aus, die du dann auf irgendeinen Server packen kannst. Der große Unterschied zu Applikationen wie WordPress oder Content-Management-Systemen wie Joomla, Typo3, Drupal oder was es da nicht noch immer gibt, ist einfach, dass es deutlich einfacher und simpler ist, weil du brauchst keine Datenbank zum Beispiel, du brauchst kein komplexes Server Setup etc. etc. Das bedeutet aber natürlich auch, wenn du eine statische Webseite hast, dass du keine Dynamik auf dem Server haben kannst. Beispiel Themen wie ein einfaches Kontaktformular werden dann natürlich etwas schwieriger. Warum? haben wir uns eigentlich schon fast ohne Abstimmung auf dem Static Site Generator geeinigt. Ganz einfach, weil wir haben keine Zeit für Maintainance. Wir wollen die ganze Sache nicht maintainen. Ich möchte keine Security Updates fahren oder ähnliches. Bei statischem HTML auf dem Server, natürlich kann es da immer noch Security Issues geben. Nehmen wir mal irgendwelche Cross Site Scripting Geschichten oder ähnliches. Dennoch muss ich mir da nicht die PHP-Version updaten, den Server unten drunter Kernel-Upgrade machen, etc. etc. Ich bin ja auch.

Wolfi Gassler (00:23:05 - 00:25:26)

Ein gebranntes Kind mit WordPress. Ich habe ja auch einige WordPress-Instanzen maintained. Und das ist einfach so eine Virenschleuder. Es ist besser geworden, muss man sagen. Und da kann jetzt WordPress unter Umständen gar nicht so viel dafür. Das ist halt wie überall. Für Windows gibt es halt Viren, weil Windows jeder verwendet. Für Linux gibt es wesentlich weniger Viren. Einfach aus dem Grund, weil es nicht so viele Leute verwenden. Das gleiche war mit WordPress. Es verwendet einfach jeder. Und da hat es halt einfach genug Script-Kiddies gegeben, die halt probiert haben, einfach die WordPress-Instanzen zu hacken, im weitesten Sinne dann vielleicht E-Mail-Spam zu versenden oder ähnliche Dinge. Und das war einfach immer ein Problem mit diesen WordPress-Instanzen. Und daher war ich auch so froh, wie dieses Static Site Generator Konzept aufgekommen ist, dass man einfach das Ganze nicht mehr braucht, weil einen klassischen Hoster, der nur HTML-Files hostet, das ist natürlich viel viel einfacher, beziehungsweise gibt es da mittlerweile einfach auch Anbieter wie Netlify, die das komplett übernehmen und noch viele zusätzliche Sachen da anbieten. Aber dass man einfach diese Einfachheit hat. Und es ist ganz interessant, wenn ich mich zurück erinnere, ich habe mal 2002, ich habe gerade nachgeschaut, ein CMS programmiert, das war vor dieser ganzen Open-Source-Zeit, wo die CMS auch wirklich teuer waren, da hat man auch ordentlich Geld auf den Tisch legen müssen für so ein CMS. Und diese ganzen Enterprise-CMS, die es damals gegeben hat, die waren eigentlich getrennt. Die hatten einen Teil, wo wirklich die Redakteure gearbeitet haben, den Content erstellt haben, die Webseiten erstellt haben, und dann wurde der gesamte Code von dem erstellten Content auf den eigentlichen Webserver übertragen. Das heißt, vor über 20 Jahren hatte man eigentlich ein ähnliches Konzept schon, dass man diese Trennung hatte, primär, weil es einfach zu langsam war. Früher hat man das einfach nicht alles dynamisch rechnen können. Das heißt, man hat es vorberechnet und dann auf den Server gelegt. Dann ist die ganze dynamische Zeit gekommen mit BHB und Co., wo alles dynamisch gerechnet worden ist und jeder Hit hat bedeutet, man holt sich die Daten aus der Datenbank, baut dann die HTML-Seite, die man dann ausliefert. Und jetzt kommt man wieder zurück eigentlich zu diesem Konzept, dass man sagt, man generiert alles im Vorhinein, weil meistens braucht man diese dynamische Fähigkeit gar nicht am Server und delivert dann nur die HTML-Seiten zu dem Server und der Server liefert dann nur mehr die HTML-Seiten mit dem JavaScript, wo man dann vielleicht ein bisschen Dynamik reinbekommt über JavaScript, an die BesucherInnen aus.

Andy Grunwald (00:25:26 - 00:26:01)

Aber auch sehr, sehr viele aktuelle Content-Management-Systeme machen genau das, um hochfrequentierte Seiten sehr schnell zu bekommen. Also ich weiß zum Beispiel, wenn es an den Vorverkaufsstart von Konzertkarten von zum Beispiel Toten Hosen, Broilers oder Rammstein geht, die Shops dahinter und die Services dahinter generieren fast den ganzen Ticketshop statisch raus, damit die Seiten einfach statisch gesurft werden können, um nicht mehr so viel Dynamik auf dem Server und nicht mehr so viel Last auf dem Server zu generieren, weil wenn Broilers toten Hosen oder Rammstein oder ähnliches Karten verkaufen, dann ist da schon ordentlich Traffic drauf.

Wolfi Gassler (00:26:01 - 00:26:50)

Früher hat man das halt auch oft über einen Cache probiert zu lösen, aber da ist halt trotzdem immer nur irgendwo Dynamik dahinter. Und ich glaube, da hat es mal bei Facebook einen ziemlich großen Outage gegeben, weil zur gleichen Zeit weltweit ein Großteil der Caches invalidiert worden sind zur gleichen Zeit und dann plötzlich alle Caches bzw. alle Anfragen wieder direkt auf die Datenbanken gegangen sind und die Seiten neu generiert haben und dann ist das ganze System zusammengebrochen. Und das Problem hat man dann natürlich auch nicht mehr. Also man ist viel flexibler, wenn man sagt, okay, man baut es wirklich, wenn man neuen Content hat und oft weiß man ja wirklich, wann man neuen Content hat und kann den dann wirklich auf, eigentlich ist es ja nichts anderes als ein Cache auf diesen Cache raufspielen und der liefert dann einfach die statischen Seiten aus. Also man hat keinen Pull-Mechanismus am Cache sozusagen, sondern einen Push-Mechanismus, wenn man es so sehen will.

Andy Grunwald (00:26:50 - 00:27:47)

Lassen wir nochmal ganz kurz zusammen. Ein paar Vorteile von Static Site Generators. Man hat keinen dynamischen Code auf dem Server. Nenne ich hier als Vorteil, weil man sich genau um den ganzen Code auch nicht kümmern muss. Das Hosting der Webseite ist relativ einfach. Man kann die ganze Statische HTML-Seite auf Github Pages ausliefern lassen. Netlify ist zum Beispiel ein Service, der ist Mit einem sehr großen Free-Tier ausgestattet reicht in der Regel, Github Pages ist komplett umsonst. Man kann aber auch sowas wie Edgeworker von Cloudflare nehmen oder ähnliches. Und weil man gerade nur statischen Code, keinen dynamischen Code auf dem Server hat, ist es natürlich ratenschnell in der Auslieferung, weil Alles ist ja vorgeneriert und Security-mäßig hat man relativ wenig Angriffsfläche, weil man hat ja kein PHP dahinter, keine große dynamische Applikation, was irgendwie Query-Parameter verarbeiten muss, Datenbank-Connections aufbauen muss etc. Und Netlify und.

Wolfi Gassler (00:27:47 - 00:28:20)

Die Edge Worker von Cloudflare. Also Netlify verwendet eine CDN und Cloudflare ist quasi die CDN. Wenn man dann sowas verwendet, dann wird dieser Content auch noch dupliziert und möglichst nahe an die Besucher und Besucherinnen gespeichert auf sogenannten Edge Nodes. Also dann gibt es eine Kopie in Europa oder irgendwo in Deutschland und dann vielleicht noch eine in Spanien und eine vielleicht in Amerika und dadurch wird es natürlich auch nochmal zusätzlich beschleunigt und wenn man keine dynamische Code-Generierung hat, ist das natürlich auch möglich, sonst wäre das gar nicht möglich.

Andy Grunwald (00:28:20 - 00:28:22)

Welche Nachteile fallen dir ein?

Wolfi Gassler (00:28:22 - 00:30:08)

Ja, natürlich, dass es nicht dynamisch ist. Das heißt, alles was irgendwie dynamisch ist, auch nach einem Login, wird wesentlich schwieriger. Es gibt da schon Möglichkeiten, dass man das auch mit einem Static Site Generator machen kann, in Kombination mit Netlify zum Beispiel, dass die dir den Login anbieten und du dann darüber eine Authentifizierung machen kannst über Tokens. Das funktioniert teilweise, auch wenn man CMS verwendet, das funktioniert mittlerweile relativ gut, wenn es dann in Richtung Previews geht. Das heißt, wenn man im CMS wirklich sofort sehen will, wie schaut denn dann die Seite aus, das ist dann schon ein bisschen schwieriger, weil man ja eben die ganze Seite dann jedes Mal generieren muss und da hat man natürlich jetzt nicht die gleiche Qualität wie in einem WordPress, würde ich mal sagen, von der User-Seite. Aber gerade für Leute, die da mehr damit arbeiten oder auch Leute, die dieses Konzept verstehen, für die sollte es sowieso kein Problem sein. Aber auch wirklich für End-User sind die CMS-Systeme, die es mittlerweile gibt für Static Site Generator, doch schon relativ weit. Und man kann da auch wirklich End-User drauflassen, das ist überhaupt kein Problem. Die schaffen das ganz gut, meiner Erfahrung nach, das ist überhaupt kein Problem. Also es gibt nicht viele Nachteile, aber umso dynamischer man sein will, natürlich umso schwieriger ist es mit diesem Stack. Aber seien wir uns ehrlich, für die meisten Projekte reicht es eigentlich aus. Und zum Beispiel, wir haben jetzt gerade bei F-Online umgestellt, dass wir die eigentliche Webseite auch auf Static Site Generator Basis haben und die eigentliche App, die dann dynamisch ist, die ist natürlich klassisch mit Server Code und klassisches PHP. Setup, aber die Seite, die Startseite, die Landingpage und die Contentseiten sind alle mit einem Static Site Generator gebaut und die sind dann stabil auf Netlify gehostet und dann, wenn die Leute wirklich lernen, gehen sie quasi in die App, die dann dynamisch ist.

Andy Grunwald (00:30:08 - 00:31:06)

Wer ein bisschen Dynamik in seine statisch gerenderte Webseite reinbringen möchte, sollte sich mal mit dem Begriff Jamstack auseinandersetzen. Jamstack steht für JavaScript, API und Markup. Wurde vom CEO von Netlify 2015 das erste Mal genannt. Ist nicht Thema der heutigen Episode. Machen wir vielleicht irgendwann mal in Zukunft was, aber das ist so der Begriff, mit dem man sich mal auseinandersetzen sollte. Jamstack. Und speziell mit der Firma Netlify, weil die ist da, denke ich, einer der Vorreiter in der Industrie, was das angeht. Bieten auch ein Content-Management-System an, was dann, glaube ich, unten drunter Git-basiert ist, Kontaktformulare und so weiter, Login-Mechanismen für statische Webseiten und so weiter und so fort. Klingt alles wie Magie, ist es vielleicht auch ein bisschen, aber unten drunter, wenn ihr euch damit mal auseinandersetzt, ist das natürlich alles Standardtechnologie, nur ein bisschen gedreht und ein bisschen anders eingesetzt.

Wolfi Gassler (00:31:06 - 00:32:25)

Und ohne Maintenance, also es funktioniert dann quasi in der Cloud oder jemand anderer kümmert sich darum, was natürlich dann schon ganz praktisch ist, um schnell Webseiten online zu bekommen. Aber vielleicht noch mal zurückzukommen, weil du dich ja so beschwert hast, dass ich so gegen Hugo geschimpft habe. Ich verwende ja selber Hugo für meine private Webseite und bin ja eigentlich ganz glücklich damit, weil Hugo wirklich super einfach ist. Was mein Problem immer mit Hugo ist und warum ich mittlerweile auf JavaScript eigentlich bin, ist, dass die Erweiterbarkeit extrem schwierig in meinen Augen ist. Das heißt, wenn ich irgendwo mal was Komplexeres machen will, irgendeine Vorschleife oder irgendwas generieren will, oder vielleicht paar komplexere If-Statements habe, ob irgendwas generiert werden soll oder nicht auf der Webseite, dann ist es für mich zumindest in Hugo immer extrem aufwendig gewesen. Superschwieriger Syntax, dem man einfach nicht gewöhnt ist. Man kann auch nicht so viel automatisch machen in den Templates. Ich weiß nicht, vielleicht kann man dann Plugins oder Ähnliches schreiben. Bin kein Hugo-Spezialist, muss ich dazu sagen. Aber sobald man ein bisschen mehr braucht als der Standard, dann wird es einfach schwieriger. Und in JavaScript kann ich halt immer einfach eine Vorschleife irgendwo reinschreiben. Das ist überhaupt nie ein Problem. Und darum bevorzuge ich mittlerweile JavaScript-basierte Frameworks nicht mehr, Hugo.

Andy Grunwald (00:32:25 - 00:33:21)

Seine Kritik ist teilweise angebracht, teilweise nicht. Also Hugo, immer noch ein rattenschneller und granatenhafter Static Site Generator. Besonders wenn ihr ne Standard-Webseite haben wollt, ne Standard-Blog, irgendwie sowas. Top-Dingen. Bei der Flexibilität, da sehe ich zwei Elemente. Die eine Sache ist die Erweiterbarkeit. Da hast du einen Punkt, weil in Go, das ist natürlich eine statisch typisierte Sprache, wo du mit dynamischen Plugins mal eben in die Binary reinladen und so, ist da halt nicht. Natürlich kannst du sowas dynamisch nachladen, da wird es dann aber doch schon relativ kompliziert für zumindest den normalen Anwender. Wenn es an die Templatesprache geht, was du gerade angesprochen hast mit Vorschleifen und so weiter und so fort, Da hast du schon richtig gesagt, du bist es einfach nicht gewohnt. Die Go-Templating-Sprache, Templating Language, ist, bin ich ganz ehrlich, gewöhnungsbedürftig.

Wolfi Gassler (00:33:21 - 00:33:22)

Sehr schön ausgedrückt.

Andy Grunwald (00:33:22 - 00:33:41)

Wenn du aus anderen Bereichen kommst, JSX, Twig bei PHP oder ähnlichen, die ist schon gewöhnungsbedürftig. Sie hat auch ihre Limits. ist auch richtig? Hast du sie einmal verstanden oder hast du einmal die Konzepte von der Go-Templating-Language verstanden? Läuft die einfach wie jeder andere?

Wolfi Gassler (00:33:41 - 00:33:59)

Ich glaube, ich habe bisher einfach das noch nicht verstanden. Ich gebe voll und ganz zu. Ist mir aber auch zu schwierig, um ehrlich zu sein. Also wenn ich so lange brauche, um irgendwas zu verstehen, dann ist das schon ein Problem. Aber wie gesagt, Hugo, ich bin trotzdem noch ein Fan davon, ist super schnell und einfach und für viele Use Cases ist das wirklich perfekt.

Andy Grunwald (00:33:59 - 00:34:32)

Nochmal ganz kurz zu der Lernkurve. Leute, die aus dem Infrastrukturbereich kommen und sehr viel mit Golang machen, haben auf der JavaScript-Seite eine ähnliche Lernkurve. JSX, Modules, NPM, Import, SAS, SCSS, Tailwind, irgendwelche JIT-Compiler, die mir automatisch die Tailwind-Klassen aus meinem JSX-Templates rausparsen. Sorry, wie viel Magie soll ich noch nennen? Die Lernkurve ist also für Infrastruktur-Leute auf dem Frontend-Bereich auch da.

Wolfi Gassler (00:34:32 - 00:34:58)

Okay, lassen wir das mal so dahingestellt. Würde uns natürlich auch freuen, eure Meinung dazu. Was ist einfacher, Hugo oder ein JavaScript-Framework? Aber für was hast du dich jetzt schlussendlich entschieden? Also ich hab dich auf JavaScript jetzt drunter verhandelt, oder besser gesagt drauf verhandelt, auf eine sinnvolle Sprache. Was hast du dann schlussendlich verwendet? Mein Favorite wäre ja gewesen irgendwas mit Gatsby oder Nuxt zumindestens.

Andy Grunwald (00:34:58 - 00:37:07)

Genau, du hast mich halt in die Gatsby, Nuxt und Nuxt.js-Richtung geschubst. Ich hab mir die ganzen Sachen noch angesehen, aber irgendwie war ich nicht sold, weil das war halt nicht so Static Site Generator, das war ja wirklich mehr Applikationsframework, da kannst du ja dicke Dinger mitbauen. Und ich hatte ein bisschen Erfahrung mit einem richtigen Newcomer auf dem ganzen Markt. Und zwar nennt er sich Astro. Astro.Build oder Astro.New. Und wieso habe ich da ein bisschen Erfahrung? Kurz bevor ich Trivago verlassen habe, da müsst ihr wissen, den Trivago Techblock habe ich damals mit Matthias Endler ins Leben gerufen. Damals 2015, 2016 oder ähnliches. Und fairerweise zu dem Zeitpunkt gab es schon einen Trivago Techblock. Grüße an René und an Mario. Den haben wir damals von WordPress runtergezogen auf einen Static Site Generator. Erst waren wir da auf Skypin. Skypin ist ein Static Site Generator auf PHP-Basis. Dann sind wir irgendwann auf Hugo gewechselt. Und so haben wir, Matthias und ich, den größtenteils B- und G-Trieben. Und kurz bevor ich Trivago verlassen habe, musste ich natürlich irgendwen finden, der dieses Baby übernimmt, dieses Baby-Tech-Block. Und das war so die Zeit, wo die meisten Leute bei Trivago weg von PHP und mehr zu JavaScript sind und dann kam ein JavaScript-Engineer. Schöne Grüße an Gadi um die Ecke und hat einfach mal einen kompletten Prototyp gebaut, hat den ganzen Trivago Techblock auf Astro umgebaut, hab ich gesagt hey cool, super sieht gut aus und er hat mir auch ein paar gute Argumente gegeben wie zum Beispiel, dass Trivago zu dem Zeitpunkt sehr, sehr viele JavaScript-Engineers hat und deswegen man auch fast eigentlich jede React, Preact, Swelte, Vue.js-Komponente mit einbinden kann und somit die Maintenance für Trivago als Firma deutlich einfacher ist als mit Hugo Go-Templating-Language, all das, was wir gerade besprochen haben. Und deswegen kannte ich die ganze, kannte ich das Framework zumindest schon mal so ein bisschen. Ich habe damit nie was gebaut, aber deswegen habe ich gedacht, komm, das ist jetzt kein Mission Critical Projekt hier, das ist ja nur unser Podcast.

Wolfi Gassler (00:37:07 - 00:37:47)

Also es ist ja sehr schön, weil der Andi erzählt immer, dass es so wichtig ist, Boring Software einzusetzen. Weil wenn man ein Problem hat, dann kann man das einfach googeln und findet 18 Antworten auf Stack Overflow. Und bei so neun jungen Projekten findet man einfach genau nichts und kann sich dann durch irgendeine schlechte Doku fressen. Und ich habe gerade mal nachgeschaut, Astro wurde vor zwei Tagen, wirklich vor zwei Tagen, released als 1.0.0 Beta. Also unser Blog baut jetzt auf, auf der richtig heißen neuen Scheiße. Ich hoffe, es wird auch dann irgendwann wirklich bekannt, damit ich es auch verstehe.

Andy Grunwald (00:37:47 - 00:37:59)

Beta 36 und ich muss zugeben, wir sind auf Beta 31, weil 36 können wir nicht nehmen, weil da der Markdown-Parser irgendwas mit unserem Content macht, was ich noch nicht ganz verstanden habe. Deswegen sind wir auf der Beta 31 erstmal gepinnt.

Wolfi Gassler (00:38:01 - 00:38:03)

Okay.

Andy Grunwald (00:38:03 - 00:38:16)

Also, prinzipiell bin ich da voll bei dir. Boring Software ist für all das, wo ich nachts aufstehe. Es tut mir leid, dass ich jetzt dein Herz breche. Für die Podcast-Webseite stehe ich nicht nachts auf und bin auch nicht auf Rufbereitschaft.

Wolfi Gassler (00:38:17 - 00:38:21)

Was heißt, wenn die Webseite offline ist, dann stehst du nicht auf?

Andy Grunwald (00:38:21 - 00:38:22)

Nicht für die Podcast-Seite, nein.

Wolfi Gassler (00:38:22 - 00:38:30)

Genau. Musst du nämlich auch nicht, weil wir das auf Netlify hosten und dann Netlify sich einfach darum kümmert, dass die wieder on kommt. Also davon geht es zumindest hoffentlich aus.

Andy Grunwald (00:38:30 - 00:38:45)

Wenn der Podcast-Player, der Integrierte, auf dieser Seite nicht funktioniert, dann stehe ich damit nicht nachts auf. Das meine ich damit. Und deswegen kann man hier mal schön experimentell sein und gucken, was jetzt hier die Zukunft von JavaScript-basierten Static-Site-Generatoren so liefert.

Wolfi Gassler (00:38:46 - 00:39:05)

Okay, by the way, wir sind von keiner dieser Technologien, auch von Netlify, nicht gesponsert. Wir sind einfach nur überzeugt von denen und nutzen die. Also, wenn wir sagen, irgendwas ist cool, dann sind wir auch der Meinung und werden nicht dafür bezahlt, nur als kleine Nebenbemerkung. Aber jetzt erzähl mal, was ist das Coole an Astro und wie hast du das umgesetzt?

Andy Grunwald (00:39:05 - 00:40:12)

Wenn ich das jetzt wüsste. Was ist das coole? Im direkten Vergleich zu Hugo. Was ist das wirklich coole? Und zwar ist der FileTree 1 zu 1 deine Navigation. Und das ist schon mal eine ganz coole Geschichte. Und jede Datei in diesem FileTree ist halt wirklich eine Seite. Und wie ihr das aus vue.js zum Beispiel kennt, hat diese einen Script-Teil, wo ihr jeglichen JavaScript Homebook machen könnt und darunter einfach nur klassisch HTML und CSS integrieren könnt und somit kann natürlich recht einfach jede Webseite in unserer Podcastseite ganz anders aussehen und natürlich eine gewisse Art von Dynamik haben. Zum Beispiel das Listing von allen Podcast Episoden. Jede Podcast Episode ist ein Markdown-File und das Listing hole ich mir einfach per glob gibt mir mal alle markdown episoden dateien und die rinder ich dann durch als als front mit das dann natürlich schon eine ganz angenehme geschichte da teilweise paar sich dann irgendwie so headlines raus und halt so dynamischen kram den man bei hugo einfach so nicht einfach machen.

Wolfi Gassler (00:40:12 - 00:40:22)

Kann jetzt hast du mir das vor weggenommen jetzt wollte ich gerade fragen wie würdest du es bei hugo machen aber du hast ja schon selber gesagt mit hugo ist sowas extrem schwierig wenn du irgendwas rauspassen willst oder so zum beispiel.

Andy Grunwald (00:40:23 - 00:40:48)

Ganz genau da, da muss ich schon zugeben, ziemlich coole Geschichte. Wo es natürlich dann ein bisschen hakelig wird, und da ist das einfach nur meine Lernkurve, ist halt mit Schleifen und Map-Funktionen in Templates, wenn ich also irgendwie über ein Array oder ein Objekt irgendwie iterieren möchte, und dann ein Listing zu generieren. Das ist jetzt nicht so meine Welt. Ich glaube, ich nutze da JavaScriptX, JSX oder ähnliches. Ist das richtig? Nennt man das so?

Wolfi Gassler (00:40:50 - 00:41:04)

Ich bin überfragt, was du genau verwendest, aber du musst ja auch nicht die ganzen funktionalen Sachen von JavaScript verwenden. Du kannst ja auch eine ganz alte, boring Vorschleife verwenden, aber es ist cool, wenn du jetzt die funktionalen Konstrukte wie Map und so weiter mal lernst und anonyme Funktionen.

Andy Grunwald (00:41:04 - 00:41:24)

Also die Seitengenerierung, die Contentgenerierung war schon ziemlich cool und da kann man natürlich jeglichen Schabernack mitmachen. Sogar irgendwelche YAML-Dateien oder JSON-Dateien als Data, als Static Data irgendwie zur Seite legen und zum Beispiel Autoren zu mappen. Also das muss ich schon zugeben, hat mir schon sehr, sehr, sehr gut gefallen.

Wolfi Gassler (00:41:25 - 00:41:31)

Jetzt haben wir ja auf der Webseite die ganzen Episoden, wie bekommst du die Episoden dort rein?

Andy Grunwald (00:41:31 - 00:42:03)

Da muss man wissen, wir haben uns jetzt für die Webseite zwei Content-Typen ausgedacht. Und zwar einmal die klassischen Blog-Artikel, wie ein klassischer Blog mit einem Blog-Post, ein bisschen Bilder und so weiter und so fort. Und der andere Content-Type sind halt unsere Podcast-Episoden. Wie im Intro schon erwähnt, ist das eigentlich fast dasselbe. Ein Blog-Artikel hat einmal den Blog-Content und oben im Front-Meta, das Front-Meta sind so eine Art Meta-Daten pro Artikel, ist da ein Titel drin, das Datum, wer hat den geschrieben, gibt's da Tags bei und so weiter und so fort.

Wolfi Gassler (00:42:03 - 00:42:07)

So wie die Header-Elemente in HTML-Datei quasi.

Andy Grunwald (00:42:08 - 00:43:20)

Ja ganz genau eine Podcast Episode die hat halt als Content halt die Shownotes und in den Metadaten im Frontmatter hast du halt das Datum der Veröffentlichung, den Link zur MP3, die Kapitel, den Titel und so weiter und so fort. Und da wir unseren Podcast natürlich nicht in Astro, nicht in AestheticSite Generator irgendwie maintainen, sondern in Extend Service Red Circle dafür nutzen, da laden wir unsere MP3-Datei hoch und die generieren ein RSS-Feed. Und dieser RSS-Feed wird dann bei Spotify, bei Amazon Music und so weiter und so fort hinterlegt und somit hört ihr hoffentlich unseren Podcast. Wie bekomme ich jetzt die Folgen da rein? Ich muss alle enttäuschen, nicht mit JavaScript. Und zwar habe ich da Python gewählt. Und zwar habe ich mir ein kleines Python-Skript geschrieben, was mir den RSS-Feed crawlt, die ganzen Daten daraus parst, mir das Markdown-File mit dem Frontmatter ordentlich aufbereitet und dann auf Disk schreibt. Warum Python in der Hinsicht? Relativ einfach, weil ich da bei GitHub Actions gar nicht mehr so viel machen muss, weil GitHub Actions Python recht nativ ausführen kann. Und somit ist das Setup von dem GitHub Actions für mich super einfach.

Wolfi Gassler (00:43:21 - 00:43:26)

Aber die muss man jetzt händisch anschmeißen, oder, wenn eine neue Episode rauskommt?

Andy Grunwald (00:43:26 - 00:44:00)

Ja und nein. Also, da wir ja ein festes Release-Schema haben, jeden Dienstag morgen soll hoffentlich eine neue Episode rauskommen, können wir natürlich die GitHub Action jeden Dienstag auf 8 Uhr oder 9 Uhr morgens stellen. Dann geht der einmal los, passt den SS-Feed, generiert die Markdown-Dateien und lädt das Cover-Image einmal runter, committet das wieder zum GitHub-Repository als GitHub-Actions, also als Cron-Job. Da wir ein automatisches Deployment bei jedem Commit in den Mainbranch von Netlify haben, geht das dann natürlich auch sofort live.

Wolfi Gassler (00:44:00 - 00:44:29)

Das heißt, wir könnten jetzt aber auch, wenn wir z.B. einen MD5-Hash oder irgendeinen Hash generieren über den RSS-Feed und diesen Hash mitspeichern oder mitcommitten besser gesagt, dann könnten wir auch einen Jack bauen, der das regelmäßig prüft, hat sich dieser Hash geändert und wenn sich dieser Hash geändert hat, generiere ich die Episoden neu und speichere die oder committe die ins GitHub-Repository und dann wird der Build wieder getriggert und automatisch alles nach Netlify hochgeladen.

Andy Grunwald (00:44:30 - 00:45:06)

Das wäre möglich, dass du hast eine Herausforderung, dass du dann zum Beispiel, wenn du das Cover-Image aktualisierst oder die mp3-Datei änderst, dass du das nicht mitbekommst, weil der md5-Hash ja natürlich nur über den Content des ss-Feeds ist und die mp3-Datei ja nicht als Content da im ss-Feed hinterlegt ist, sondern nur als Datei und der ss-Feed nicht den md5-Hash von der mp3-Datei mitliefert. Somit wenn du die mp3-Datei zum Beispiel nochmal editierst oder wenn du Tippfehler in dem Coverimage machst und das Coverimage neu hochlädst, dann kann das sein, dass die Coverimage-URL dieselbe ist, aber da ein anderes Bild hinter steckt.

Wolfi Gassler (00:45:06 - 00:45:10)

Aber die MP3-Datei liegt jetzt nicht im GitHub-Repo, oder?

Andy Grunwald (00:45:10 - 00:45:12)

Nein, die MP3-Datei jetzt nicht, aber Okay.

Wolfi Gassler (00:45:12 - 00:45:37)

Das heißt, also wenn sich die mp3 Datei ändert, wäre es egal, aber das Cover Image zum Beispiel müsste man updaten. Wobei das checken wahrscheinlich die meisten Player auch nicht. Wenn jetzt wir das File ändern, dann checkt das wahrscheinlich Spotify genauso wenig, weil sonst müssten die ja ständig irgendwie dieses File auch nochmal checken. Könnte man ja eben, wenn man es jetzt wirklich sauber machen will, könnte man ja dann auch nochmal checken, hat sich das Bild geändert, aber das wäre dann schon extrem viel Aufwand.

Andy Grunwald (00:45:38 - 00:45:46)

Wir unterhalten uns hier aber grad auch über ein theoretisches Problem, weil ich kann mich in 20 Episoden nicht daran erinnern, dass wir jemals das Cover-Image einmal ausgetauscht haben.

Wolfi Gassler (00:45:46 - 00:46:02)

Das MP3-File aber schon, weil das hab ich schon oft genug versaut. Oder nicht oft genug, ich glaub, einmal hab ich's wirklich versaut, da hab ich an das Intro vergessen, da hab ich die falsche Datei hochgeladen. Und einmal ist mir ein anderer Fehler passiert. Aber das hab ich Gott sei Dank relativ schnell ändern können.

Andy Grunwald (00:46:02 - 00:46:51)

Aber zurück zum Technische Setup. Also Static Site Generator, Javascript basiert, Astro nennt er sich. Und ich gebe zu, Astro ist so ungefähr der beschissenste Term zu googeln. Immer wenn ich irgendwas mit Astro gegoogelt habe, komme ich immer irgendwie auf irgendeine NASA Webseite oder irgendwelche Leute mit Weltraum und so weiter und so fort. Und du musst enorm viele Keywords wie Javascript und Tailwind und so weiter und so fort heranpacken, damit man irgendwie da rankommt. Es gibt noch nicht ganz so viele Ressourcen zu Astro, muss ich zugeben. Also wir sind da recht hipster unterwegs. Und ja, beim Astro-Upgraden bin ich auch mehrmals in irgendeine fehlerhafte Version gelaufen. Und ich habe mich gefragt, wieso funktioniert die nicht. Und einen Tag später gab es ein neues Release, was da genau wieder diesen Bugfix drin hatte. Also ich gebe zu, ich bin sehr, sehr viel in Early-Bugs gelaufen. Die wurden aber auch sehr, sehr schnell gefixt.

Wolfi Gassler (00:46:52 - 00:47:06)

Aber es muss jeder mal diese erfahrung machen an die der neu in dieser it welt ist und ganz frisch begonnen hat als neuling in dieser it welt dass man einfach mal gegen die wand rennt und dann entscheidet okay man nimmt die zukunft die ältere software muss jeder mal lernen ist schon okay.

Andy Grunwald (00:47:06 - 00:48:09)

Auch hier habe ich mich einfach mal auf die experimentelle schiene begeben hab mir mal angesehen okay, Was macht denn diese JavaScript Welt so? Und ich muss zugeben, beim Website bauen hatte ich jetzt schon ein bisschen Spaß. Static Site Generator, Astro, CSS Framework, Tailwind. Ich habe noch nicht so viel mit Tailwind gemacht. Okay, Tailwind, Atomic, CSS Framework, alles super. Das bedeutet, wenn ich ein Text Decoration Doppelpunkt Underline haben möchte, dann packe ich die Klasse Underline darunter. Also jede CSS Rule hat eigentlich eine Klasse. Ist aber auch super konfigurierbar und ihr könnt alles vorgenerieren. Ihr introduziert wirklich nur die Klassen, die ihr wirklich braucht, weil es da so Logiken gibt, wie Tailwind untersucht deine HTML-Dateien und deine HTML-Templates und schaut, welche CSS-Klassen genutzt werden und nur diese Klassen werden dann in CSS mit reingeneriert. Also das ist schon eine super Sache. Gehostet ist die ganze Geschichte, also Source Code wird auf GitHub gehostet unter github.com slash engineeringkiosk. Ist auch Open Source, könnt ihr euch alles ansehen, was ich da gemacht habe.

Wolfi Gassler (00:48:09 - 00:48:13)

Ihr könnt auch direkt Kommentare geben, wenn ihr irgendwas tolles findet.

Andy Grunwald (00:48:13 - 00:48:36)

Der ganze Source Code ist auf jeden Fall öffentlich und auch das Python-Skript. Schaut da rein, wenn ihr was zu lachen haben wollt. Ansonsten ist das das dreckigste, was ich je geschrieben habe, weil ich schön mit Regex und String Replace HTML parse. Also, das, was ich da mache, mach das bitte nicht zu Hause. Und mach das bitte, bitte, bitte, bitte, bitte niemals in Produktion bei irgendwas, was gut laufen soll, ja?

Wolfi Gassler (00:48:36 - 00:48:49)

Wir haben das auch ganz professionell gemacht, wie wir das damals auch bei Code-Reviews schon besprochen haben. Das heißt, wir haben ein Pull-Request erstellt, haben dann kein Code-Review gemacht. Ihr habt diesen Code wirklich noch nie gesehen. Andi hat den komplett alleine geschrieben.

Andy Grunwald (00:48:50 - 00:48:54)

Das war auf jeden Fall sehr pragmatisch, nenn ich das, sehr dreckig. Aber hey, es funktioniert.

Wolfi Gassler (00:48:55 - 00:49:02)

Lean Start heißt es. Es ist nicht dreckig. Es ist einfach pragmatisch und lean, schön schnell was geschickt.

Andy Grunwald (00:49:02 - 00:50:05)

Deployment ist auf Netlify. Das bedeutet, wir pushen ins GitHub-Repository und Netlify schnappt sich den letzten Comet. baut das ganze Paket und hostet das fertig generierte HTML. Und DNS-technisch lenken wir unsere Domain engineering-keys.dev dann einfach auf Netlify und das war es eigentlich schon. Summa summarum haben wir keine Kosten außer für die Domain. Wir haben keine Maintainance Kosten. Wir nutzen freies Service wie GitHub und Netlify, zumindest im Free-Tier. Wir müssen nicht nach aufstehen, weil uns irgendein Scammer und Hacker unsere Webseite aufgemacht hat und in die Kommentarspalte zugespampt hat, weil wir haben keine Kommentare. Somit eigentlich ein relativ schmales Setup. Die Erfahrung mit Astro war auch sehr positiv. Sie ist natürlich noch sehr, sehr früh im Entwicklungsstadium. Aber kann ich nur empfehlen, falls wer mal eine neue Webseite bauen möchte, vielleicht die persönliche Webseite, vielleicht mal ein Portfolio, ein Blog oder ähnliches, schaut euch mal astro.build an. Ziemlich, ziemlich cooles Ding an.

Wolfi Gassler (00:50:06 - 00:50:50)

Und sonst würde uns natürlich interessieren, was ihr von dem Setup grundsätzlich haltet. Es war jetzt so eine wirkliche Kiosk-Folge dieses Mal. Irgendwie zwei Leute reden über Zeug, wo sie eigentlich nicht viel Ahnung haben und einfach mal was probiert haben. Also so sollte es ja auch sein. Darum würde uns natürlich auch unbedingt eure Meinung interessieren, was ihr auch so von den ganzen Static Site Generatoren hält, ob das was sinnvolles ist oder auch was ihr verwendet, ob jetzt Hugo, Astro, Jacky, Gatsby, Next, Nuxt, Sculpin, falls es noch gibt. Ob ihr da irgendwas von diesen Sachen verwendet oder auch den CSS Frameworks, was ihr empfehlen könnt und ganz ganz wichtig natürlich, was ihr von der Webseite hält und da würden wir uns natürlich auch auf Feedback freuen.

Andy Grunwald (00:50:50 - 00:51:46)

Nicht nur Feedback, sondern auch Pull-Requests. Schaut euch den Quatsch mal an, den ich da verbrochen habe. Macht ruhig direkt Pull-Requests. Wir würden uns um jede Contribution freuen. Und wenn ihr neu in dem ganzen Thema Static Site Generators seid, googelt doch einfach mal Static Site Generator und dann eure Programmiersprache eurer Wahl. Es gibt so jeder Programmiersprache Static Site Generators. Hugo für Go, Astro, Gatsby, Next.js, Nuxt.js, Eleventy für JavaScript zum Beispiel, Sculpin für PHP, Jekyll für Ruby und so weiter und so fort. In Python und Rust gibt es auch welche. Es gibt gefühlt jede Woche neun Static Site Generator auf dem Markt. Schaut euch die mal an, ob das nicht gegebenenfalls auch mal für die nächste Landingpage oder sowas, die ihr für euer Sideprojekt machen wollt, weil ihr macht ja alles Sideprojekt, oder? Ob ihr sowas da nicht einfach mal integrieren wollt und einfach mal ein bisschen was Neues lernen wollt und mal nicht immer nur ein WordPress oder ein Drupal aufsetzen müsst und das wieder updaten und maintainen und ach, ihr kennt den, ihr habt die Schmerzsache.

Wolfi Gassler (00:51:47 - 00:51:53)

Falls WordPress oder Drupal überhaupt noch CMSchen, die man heutzutage so viel verwendet. Keine Ahnung, ehrlich gesagt.

Andy Grunwald (00:51:53 - 00:52:07)

Ich meine, die könnten natürlich alternativ auch irgendwelche Homepage-Baukästen wie Wix oder Jimdo oder den 1&1 Homepage-Baukästen nehmen. Auch alles super, ja. Oder Card. Card ist zum Beispiel auch sowas. So ein Online-Service, wo man sich einfach ganz schnell eine Website zusammen klicken kann. Gar nicht so schlecht.

Wolfi Gassler (00:52:07 - 00:52:56)

Können wir auch gern verlinken, ist wirklich super, wenn man ganz eine schnelle Landingpage bauen will. Und vielleicht auch nochmal ganz nebenbei, warum wir kein Wix Jimdo oder so verwendet haben. Wir wollten es einfach halt auch selber besitzen, die Kontrolle über das haben und da kommen halt dann auch die technischen Vorlieben von uns an die Oberfläche, dass wir das einfach gerne selber bauen würden. Also gebt uns Feedback, schreibt uns dann stetig at engineeringkiosk.dev oder auf Twitter ING Kiosk. Wie immer, wir freuen uns auf jedes Feedback, auch wenn wir da vielleicht böses Feedback bekommen, was wir da alles so zusammen gebaut haben, was überhaupt keinen Sinn macht. Ich leite es dann gerne weiter und Andy ist überhaupt kein Problem. Und dann wünsche ich euch noch eine schöne Woche und hoffentlich nächste Woche wieder mit einem Thema, wo wir ein bisschen mehr Ahnung haben, als über was wir heute geredet haben.

Andy Grunwald (00:52:56 - 00:53:09)

Also ich gebe ja auch zu, mit JavaScript kannst du mich echt jagen. Tailwind komme ich ganz klar, aber Flexbox verstehe ich bis heute auch nicht. Wie dem auch sei, vielen Dank fürs Zuhören. Ich bin gespannt, was ihr darauf zu sagen habt und bis bald.

Wolfi Gassler (00:53:09 - 00:53:18)

Ciao. Und, mit wieviel Pulverquests rechnest du?

Andy Grunwald (00:53:18 - 00:53:19)

Wie viele Hörer haben wir gerade?

Wolfi Gassler (00:53:19 - 00:53:20)

Tausende.

Andy Grunwald (00:53:20 - 00:53:34)

Also ich rechne schon mit dem einen oder anderen Pulverquest, der mir meine Tailwind-Vergewaltigung da oder mein HTML-Copy-Paste mit diesen genesteten Strukturen ein bisschen aufräumt, weil die einfach nur sagen, das kannst du doch nicht im Internet stehen lassen, das geht nicht.