*rc3-nowhere Vorspannmusik*
Herald: Herzlich willkommen auf der Chaos West stage. Der nächste Talk heißt "make it
static" und es wird darum gehen, warum man vielleicht nicht ein fancy CMS hernehmen
sollte, dass eine Menge Abhängigkeiten hat. Und wir wissen ja nicht erst seit
Log4Shell, dass die auch unerwartet große Probleme machen können. Der Talk wird von
einem Studenten an der TU Darmstadt, der Avocado heißt, gehalten. Ein herzliches
Willkommen und ich freue mich schon sehr auf deinen Talk.
Avocadoom: Hi, ja, vielen Dank erst mal für die nette Begrüßung. Du hast es schon
angesprochen. Das wird auch so ein bisschen das Thema werden.
Sicherheitslücken in CMS und wie man das vielleicht mit statischen Seiten umgehen
kann. Erst einmal herzlich willkommen zu meinem Talk make it static. Ich habe noch
kurz eine Slide eingebaut in der ihr einen QR-code habt den ich euch ganz kurz mal
abscannen lasse, wenn ihr den abscannen wollt, da seht ihr die Slides auch noch
mal, falls ihr was nachlesen wollt, oder nicht ganz hinterherkommt oder zum
Beispiel euch die vergrößern wollt. So, jetzt zu mir. Ich bin Avocadoom. Ich
studiere aktuell an der TU Darmstadt bzw. Thilo Billerbeck ist mein richtiger Name
und genau, ihr findet mich auf verschiedenen Social-Media-Kanälen. Ich
mache auch nebenbei tatsächlich Webentwicklung und Webdesign. So ein
bisschen. Deswegen stecke ich in diesem Thema ein bisschen tiefer drin. Und ja,
ich freue mich jetzt auf jeden Fall schon, euch das Thema ein bisschen präsentieren
zu können. Aktuelle Situation ist erstmal so ein bisschen der Einstieg, den ich euch
geben möchte und aktuelle Situation beschreibt es schon ganz gut, weil aktuell
haben wir ja eine Sicherheitslücke, die schon relativ krass und bekannt ist und
ich möchte euch erstmal so ein bisschen sagen, warum vielleicht static sites eine
coole Idee sind. Da habe ich so ein bisschen im Internet etwas rausgesucht.
Das sind Artikel die tatsächlich vor Log4Shell noch erschienen sind. Als ich
diese Präsentation angefangen habe zu erstellen, gab es diese Lücke noch gar
nicht. Und ihr seht jetzt so ein bisschen, die Artikel kommen von Heise oder t3n. Es
geht hier zum Beispiel um Drupal oder WordPress oder irgendein Plugin. Und in
der Regel sind das irgendwie immer Sicherheitslücken, die dann irgendwann
erkannt werden oder entdeckt werden und wo dann zu einem schnellen Update aufgerufen
wird. Und die Sache ist dann immer so ein bisschen, dass man halt auch schnell
agieren muss. Und viele setzen sich halt so ein WordPress oder Drupal so dahin und
richten es einmal ein und pflegen das dann nicht. Und das kann dann halt super
schnell mal anfällig für irgendwelche Sicherheitslücken werden. Und da ist halt
eigentlich immer schnelles Handeln gefragt. Zu dem ganzen Backend Sachen so
ein bisschen bei Content Management Systemen gibt es ja generell immer so zwei
verschiedene Lösungen oder Arten, wie man das angehen kann. Es gibt ja die fertig
Lösungen, die bekannten WordPress, Joomla, Drupal oder auch modernere Systeme und die
brauchen halt in der Regel immer regelmäßig Pflege und Updates, um
vernünftig funktionieren zu können, keine Sicherheitslücken zu bieten. Und auch drum
herum muss immer um alles gesorgt sein. Sie benötigen ein sauberes und sicheres
Setup und das betrifft vor allen Dingen nicht nur das System an sich, sondern vor
allen Dingen auch alle Systeme drumherum, zum Beispiel Datenbanken oder Server an
sich. Na, wenn euer System sicher ist und dann auf einmal jemand durch eine
Datenbank Lücke bei euch reinkommt, dann ist euch halt auch nicht geholfen oder
Rootzugriff auf euren Server bekommt, dann habt ihr halt auch irgendwie ins Gras
gebissen. Da gibt es noch so ein bisschen so eine andere Gattung von Systemen, die
einem immer wieder begegnen. Das sind die sogenannten Eigenbauten. Die haben noch
mal ein bisschen mehr Pfeffer als die Fertiglösung bei manchen Dingen, wenn man
sich da nicht ordentlich drum kümmert. Die haben halt auch die ähnlichen Probleme wie
die Fertiglösungen, das ist ganz klar. Aber vor allen Dingen haben sie auch noch
den Nachteil, dass man halt ganz viele Dinge, die von den CMS berücksichtigt
wurden mit bedenken muss, zum Beispiel SQL-Injection oder Cross Site Scripting
und Ähnliches. Und wenn man sich das halt nicht alles mit anschaut, dann kann einem
das auch ganz schnell um die Ohren fliegen. Und darum muss man sich halt die
Frage stellen: braucht man das wirklich? Weil wenn man einmal in das System
gelangt, über welche Stelle auch immer, hat man meistens relativ schnell Vollzugriff
und wenn man Vollzugriff hat, dann sieht es eher schwierig aus. Gerade
wenn man eine größere Seite ist, kann das sehr unangenehm werden. Ein weiterer
Punkt, den man bei einem Content Management System so ein bisschen beachten
muss, ist der Wartungsaufwand. Ich hatte es gerade eben schon angesprochen die
Dinger müssen regelmäßig und teilweise auch sehr akut gepflegt werden. Man muss
dafür Zeit aufwenden, sie müssen relativ schnell und regelmäßig gepflegt werden und
auch das Hostsystem drumherum braucht regelmäßig Pflege und Updates, weil wenn
das out of date ist, dann geht es halt auch nicht. Viele Systeme können das
inzwischen automatisch übrigens. Aber auch da gibt es zum Beispiel Major Updates, die
meistens manuell eingespielt werden müssen oder Plugins Updates, die auch gerne mal
manuelles Einspielen erfordern. Außerdem kann es sein, dass euch zwischendurch mal
die Features brechen, bei WordPress zum Beispiel oder so im Theming oder Plugin
Bereich. Das heißt, wenn größere Versionen von WordPress oder Co ausrollen und die
halt geupdatet werden müssen, weil Sicherheitsupdates benötigt werden, dann
müsst ihr halt auch entsprechend wieder Zeitaufwand da reinstecken, das alles zu
portieren und entsprechend anzupassen. Weil ansonsten habt ihr irgendwie nicht
eine schöne Seite da liegen, sondern nach dem nächsten Major Update auf einmal
irgendwas, was mehr aussieht wie bekannte Blog Seiten aus dem Internet. Und genau
außerdem müsst ihr immer da einen großen Invest reinstecken. Und dann gibt es noch
etwas, was ich als Plugin-Hölle bezeichnen würde. Das kennt man übrigens auch [bei]
WordPress. Der Begriff fällt heute leider relativ häufig. Es tut mir leid, aber
gerade da sieht man das sehr häufig, dass da halt super viele Plugins reingesteckt
werden. Und das klingt erst mal ganz cool. Ich hole mir irgendwie mein System, dann
hole ich mir lauter Features da rein, pack das alles so in eine Kiste und dann läuft
es, das Problem ist bloß. Je mehr Plugins man eigentlich da rein packt, desto
schlimmer wird es eigentlich und desto mehr Abhängigkeiten erzeugt man. Und wenn
das nächste große Update kommt, kann halt irgendwas kaputt gehen. Und dieser Zustand
ihr sehts auch unten. Der nimmt halt in der Regel mit dem Alter der Seite zu und
irgendwann habt ihr mal irgendwas, was zum Beispiel nicht maintained wird oder nicht
ordentlich mit dem neuen Update funktioniert. Und dann habt ihr plötzlich
eine Seite, die aussieht wie was auch immer oder einfach komplett offline ist.
Noch eine weitere Sache, die einem halt auffallen kann sind Skalierungsprobleme.
Das trifft jetzt kleinere Seiten, die Blogs und Co eher weniger. Aber wenn ihr
zum Beispiel einen Talk über Kopierer haltet und auf einmal plötzlich die halbe
Weltkugel auf eurem Blog habt, dann wollt ihr vielleicht gucken, dass das auch
ordentlich skaliert. So Systeme skalieren meistens an sich sehr gut und auch die
Webserver an sich, die skalieren halt ordentlich. Aber wenn ihr zum Beispiel
eine Seite mit einem relativ komplexen Aufbau habt oder halt eine große Datenbank
dahinter mit Content, viele Queries, also Datenbankaufrufe, die bei einer Seite
durchgeführt werden müssen, dann kann es euch halt super schnell passieren, dass
die Last auf dem Server halt auch ordentlich hoch wird und der nächste Punkt
der noch dabei ist, ist halt eine Datenbank, die skaliert halt auch meistens
relativ gut mit. Aber wenn ihr anfangt irgendwie die Seite zu expandieren auf
mehrere Server oder so, dann seid ihr irgendwann auch relativ schnell an dem
Punkt, wo ihr merkt, dass das gar nicht so einfach ist. Und was ein Problem ist, ist
halt, wenn so eine große Last auftritt, dann ist halt erst mal die ganze Seite
offline und das ist halt auch nicht so cool, weil dann seid ihr gar nicht mehr
erreichbar und nicht nur schlecht, sondern wirklich komplett gar nicht mehr. Und
jetzt kommt natürlich der große Moment Magic Fairy Dust Static Sites to the
rescue oder vielleicht auch nicht, weil vielleicht lösen sie jetzt auch nicht alle
eure Probleme, aber vielleicht einige. Und dazu kommen wir jetzt ein bisschen.
Erstmal natürlich so ein bisschen der Punkt an sich: Was sind denn überhaupt
statische Seiten? So eine statische Seite ist im Prinzip, wie der Name schon sagt,
eine Seite, die halt nicht irgendwie dynamisch generiert wird. Das heißt, da
ist kein Content Management System im Hintergrund, was das Ding zusammenbaut
oder ähnliches, sondern die Seite wird "as is" an den Client ausgeliefert. So eine
Seite besteht dabei meistens aus HTML. Das kennt ihr mit Sicherheit das ist einfach
Hypertext Markup Language, also wie eure Seite aufgebaut ist. CSS - Cascading Style
Sheets. Also wie genau eure Seite am Ende aussehen soll. Wie sie sich verhalten
soll, wenn bestimmte Dinge gehovert werden und so. Und dann gibt es natürlich noch
JavaScript und Co. Habe ich jetzt das mal genannt, weil es auch heutzutage so was
Web Assembly gibt. Und das sind Komponenten, die dafür sorgen, dass eurer
Seite Leben eingehaucht wird und dass sie dynamisch wird. Das habe ich jetzt auch
bewusst ein bisschen gehighlighted, weil es tatsächlich so ist, dass das bei
statischen Seiten euer einziger Anker sein wird, wie ihr Dynamik in eure Seite
reinbringt. Das heißt, ihr macht das nicht mehr serverseitig, sondern ihr macht es
clientseitig über JavaScript und nutzt Scripts, um halt dort die nötigen
Komponenten reinzuziehen und so entsprechend das Ganze ein bisschen
lebhafter zu machen. Um so eine statische Seite zu bauen, habt ihr sogenannte Static
Site Generators. Das ist im Prinzip euer Toolbelt euer Werkzeuggürtel, um halt
entsprechend solche Seiten aufzubauen. Und die verschmelzen im Prinzip Templates und
also Vorlagen und Inhalte zu einem Gesamtkonstrukt. Das Ganze läuft auch
meistens so, dass Inhalte und das Template an sich relativ strikt getrennt sind. Das
heißt, ihr schreibt das nicht irgendwie in HTML Code rein, sondern ihr schreibt eure
Inhalte in einem relativ einfachen Format oder in einem strukturierten Format auf,
schreibt dann auf der anderen Seite, wie das Ganze aufgebaut sein soll und am Ende
verschmilzt das Ganze im Prinzip zu einem Gesamtkonglomerat und wird so zu eurer
statischen Seite. Das heißt aber auch, dass diese Seiten entsprechend schon beim
Deployment, also wenn ihr die Seite auf den Server schiebt, generiert und
fertiggestellt werden. Das heißt, sobald die Seite auf dem Server ist, muss die im
Prinzip gar nicht mehr zusammengebaut werden, sondern einfach nur ausgeliefert
wie eben schon gesagt. Außerdem gibt es da noch ein paar weitere Punkte, nämlich
werden Metadaten generiert. Wenn ihr diese statischen Seiten generiert, das
heißt ihr habt auch entsprechend Zusatzinformationen, die euch der
Generator automatisch zur Verfügung stellt, wie zum Beispiel Autoren, die
Textlänge kann man mit Sicherheit auch bei einigen rausziehen. Das Datum, wann das
ganze erstellt wurde. Irgendwelche Git Informationen. Das sind alles
Informationen, die euch dann helfen, entsprechend den ganzen Content ein
bisschen richer zu machen und ihn auch besser, strukturierbar, auffindbar und
suchbarer zu machen. Und genau das ist auch noch ganz wichtig. Außerdem gibt es
zusätzliche Features, die auch noch beim static site generator dabei sind, nämlich
sowas wie das Anlegen und Rendering von JavaScript oder CSS. Das heißt, dass eure
Stylesheets entsprechend schon minifiziert werden und sowas, was ihr vielleicht auch
von Webentwicklung an sich kennt, falls ihr da schon mal was gemacht habt. Hash
Generierung zur Verifizierung, dass die Dateien richtig übertragen wurden, z.B.
die CSS-Dateien. Dazu komme ich später noch mal. Oder die Bildverarbeitung, um
dafür zu sorgen, dass die Bilder entsprechend relativ klein sind, die ihr in
eurer Seite einbaut. Also alles Convenience Tools, die ihr quasi nutzen
könnt, um in eurer Seite ein entsprechend vernünftiges Erlebnis bieten zu können.
Jetzt denkt ihr euch mit Sicherheit, das nutzt doch keiner so, das klingt doch
total kompliziert und das will ich doch überhaupt nicht haben. Und da habe ich
euch mal ein paar Beispiele mitgebracht. Zum Beispiel seht ihr da oben links
nationalgeographic.co.uk Das ist tatsächlich ein relativ bekanntes und
populäres Beispiel. Die haben gatsby als Static Site Generator eingesetzt, dazu
komme ich auch gleich nochmal. Und ja, da würde man im ersten Moment gar nicht davon
ausgehen, dass die Seite statisch generiert ist. Ist sie aber komplett und
das macht sie entsprechend auch für hohe Lasten relativ gut nutzbar und sorgt auch
dafür, dass die Seite, hohe Anfragen entsprechend gut verarbeiten kann, und
auch schnell beim Nutzer ist. Da habe ich noch ein paar Seiten aus dem Entwickler
Bereich mitgebracht, oben rechts seht ihr das Ionic Framework für mobile Apps. Unten
links, das kann vielleicht auch einige schon. Das ist die 1Password Hilfe für so
Dokumenten- Dokumentation eignet sich das tatsächlich perfekt, sowas statisch zu
generieren, weil das ändert sich nicht so oft. Und unten rechts auch relativ
unbekannt. Nein, Let's Encrypt natürlich auch komplett statisch generiert auch da
hat die Seite große Nachfragen und profitiert natürlich davon, wenn sowas
entsprechend schon fertig generiert ist. Es gibt so ein paar Static Site Generators
die ich hier mal aufgelistet habe. Das sind übrigens, habe noch nicht erwähnt,
alles in der Regel Command Line Programme, das heißt ihr habt kein User Interface,
sondern - also -, kein GUI, kein Graphical User Interface, sondern macht das alles
über die Kommandozeile. Darauf komme ich aber auch gleich noch mal zu sprechen. Ihr
habt oben links Hugo, das ist ein Static Site Generator, der mit GO funktioniert
und als Binary ausgeliefert wird und relativ schnell und einfach funktioniert
und für die meisten Use Cases ausreicht. Daneben Jekyll. Das ist mehr so der
Platzhirsch, den es eigentlich schon seit Ewigkeiten gibt. Ist in Ruby geschrieben,
hat Pluginsupport wird glaube ich von GitHub immer noch für statische Seiten
empfohlen und bietet euch ein bisschen mehr Flexibilität als Hugo, hat aber den
Nachteil, dass es zum Beispiel auch relativ viel Ruby mit sich schleppt, und
man sich mit der Ruby Toolchain mal auseinandersetzen sollte. Für Leute, die
schon mal mit JavaScript gearbeitet haben, gibt es hier zum Beispiel ganz oben rechts
auch Eleventy, wie gesagt JavaScript als Backendsprache und arbeitet ähnlich wie
Hugo und wird auch gerne mal in andere Toolchains mit integriert. Unten links
seht ihr Gatsby das ist ein Static Site Generator der ein bisschen mehr macht als
die anderen. Der arbeitet mit React und kann entsprechend auch Seiten generieren,
die ein bisschen mehr interaktiver sind und die ohne viel Aufwand quasi auch dafür
sorgen, dass bestimmte fortgeschrittene Techniken, die ich euch später noch mal
zeigen werde, auch direkt mit eingebaut werden können und macht eure Seite noch
dynamischer und sorgt dafür, dass sie noch weniger unterscheidbar von klassischen CMS
Seiten ist. Ganz unten rechts habe ich euch noch Astro mal eingefügt. Das ist ein
relativ neues Tool, wenn ihr zum Beispiel schon mit React oder Vue oder Svelte, das
sind alles Frontend Frameworks, gearbeitet habt, ist das vielleicht was für euch. Da
könnte ihr nämlich genau diesen Code schreiben von diesen entsprechenden
Frameworks und dann wird euch das komplett statisch ohne JavaScript raus gerendert.
Das heißt, da müsst ihr nichts neu lernen, sondern einfach easy anfangen eure
statische Seite zu bauen. Genau. Ich trinke mal ganz kurz was und dann erzähle
ich euch mal ein bisschen, wie das ganze überhaupt funktioniert. Und zwar klingt
das alles erst mal ein bisschen überfordernd Ich habe euch jetzt
wahnsinnig viel über Sicherheitslücken und über die Gründe für Static Site Generators
erzählt, aber ihr denkt euch wahrscheinlich wovon rede ich da
überhaupt? Dafür habe ich mir ein Beispiel mitgenommen von meinem Home Hackspace,
weil wir arbeiten tatsächlich mit Static Site Generators, dass ist
darmstadt.ccc.de. Das wird bisher mit Jekyll gebaut. Das habe ich neulich auf
Hugo portiert und in den folgenden Folien seht ihr auch so ein bisschen Code daraus,
deswegen wollte ich euch mal kurz sagen, dass das daher kommt und wir sind damit
auch sehr zufrieden. Und ich erzähle euch auch so ein bisschen warum. Wenn ihr so
einen Static Site Generator erst mal euch rausgesucht und installiert habt, dann
habt ihr meistens so einen Initialisierungsbefehl irgendwann
eingegeben ins Terminal und dann liegt vor euch eine riesen Ordnerstruktur. Diese
riesige Ordnerstruktur ist erst mal vielleicht ein bisschen überfordernd,
gerade wenn man von Content Management Systemen kommt und dann plötzlich damit
Dateien zu tun hat. Dann kann es einen ein bisschen erschlagen. Ich kann euch das
aber mal ein bisschen runterbrechen und vereinfachen. Wir haben hier im Prinzip
vier wichtige Bestandteile in jedem Static Site Generator. Die heißen meistens ein
bisschen unterschiedlich, sind aber relativ ähnlich zueinander. Wir haben
einmal die Inhalte und Daten. Das ist quasi das, wo entsprechend dann das Herz
eurer Seite besteht, so mit Blog-Posts, Seiten. Aber auch strukturierte oder semi-
strukturierte Daten könnt ihr entsprechend da einpflegen. Und ihr habt da zum
Beispiel so Formate vorliegen wie Markdown, YAML, JSON, TOML und so weiter.
Also verschiedene Formattypen. Dann habt ihr Templates und/oder Themes. Das sind
sozusagen die Blöcke eurer statischen Seite, die vorgeben, wie sie später
gerendert werden soll. Wenn euer Static Site Generator die Seite zusammenbaut,
dann nimmt er sich den Content, guckt, wo kommt das ins Template rein und baut das
alles entsprechend zusammen. Das heißt, dass auch eine gewisse Uniformität erzeugt
wird. Und diese Templates und Themes habt ihr im Prinzip an bestimmten Stellen in
diesem Static Site Generator liegen, schreibt sie dort und strukturiert und
teilt sie auch dort auf. Außerdem habt ihr Konfiguration. Das ist ganz klar. Alles
was ihr ins Netz stellt, muss auch irgendwo konfiguriert werden und
entsprechend mit Metadaten versehen werden. Das macht ihr meistens dort. In so
Konfigurationsdateien stellt ihr zum einen meistens ein, wie so'n Static Site
Generator arbeiten soll aber auch zum Beispiel Metadaten, euer Seitenname, eine
Beschreibung für SEO oder so kommt dann meistens auch mit rein und Plugins oder
ähnliches werden dann meistens auch mit rein konfiguriert, wenn euer Static Site
Generator das überhaupt unterstützt. Jetzt habt ihr ganz viel Struktur und Text. Eine
Sache fehlt natürlich noch: Die statischen Assets, wie zum Beispiel Styles, Fonts,
Bilder und Skripte. Also alles das, was sozusagen dafür sorgt, dass das Ganze auf
einem Bildschirm ein bisschen mehr Form und Farbe annimmt und auch ein bisschen
mehr Dynamik. Das ist quasi auch noch eine Sache, die dort mit drinsteckt. Ich habe
von einem Beispiel gesprochen. Wir haben ja die Darmstadt CCC Seite auf Hugo
umgebaut. Ist aktuell noch nicht deployed, aber hier seht ihr schon mal ein bisschen
als Beispiel die Ordnerstruktur von Hugo. Wenn ihr so'n hugo new site-Befehl
ausführt, dann habt ihr die Konfigurationsdatei ganz oben. Das ist die
config.toml. Da definiert wie gesagt die entsprechenden Werte für die Seite schon
drin. Dann habt ihr content. Das ist das für semi- und unstrukturierten Inhalt der
Seite, zum Beispiel Blogposts. Also semi- und unstrukturiert heißt im Prinzip
Markdown und Text einfach so als unstrukturiert und semistrukturiert
könntet ihr auch zum Beispiel HTML-Seiten und so drin schreiben, wenn ihr das
entsprechend braucht. Wenn ihr zum Beispiel irgendwelche Datenbanken habt,
Listen oder ähnliches, die sich relativ ähnlich sehen, habt ihr zum Beispiel den
data-Ordner. Da kommen dann, so YAML-, TOML- und JSON-Dateien rein, die wirklich
einfach formatierte, strukturierte Inhalte haben, die ihr zum Beispiel auch als
Listen in den Templates rendern könnt. Statische Assets ist relativ schnell
erklärt, kommen in static rein. Themes sind komplette Pakete, die ein bestimmtes
Thema enthalten, inklusive Layout und Styles und Ähnlichem. Und unten habt ihr
Layouts. Layouts sind ein bisschen spezifischer als Themes. Darauf komme ich
auch gleich noch mal zu sprechen. Das ist im Prinzip der Teil, wo ihr bestimmt, wie
spezifische Inhalte auf eurer Seite auch unabhängig vom Theme gerendert werden
sollen. Das klingt ein bisschen verwirrend. Ich erkläre euch aber gleich
mal, wo da der Unterschied genau besteht.
Inhalte. Wenn ihr anfangt, so eine
statische Seite zu bauen, dann ist das erste, was euch in den Sinn kommt,
natürlich, dass ihr irgendwo Inhalte reinpacken wollt. Und wie gesagt, kommt
das bei Hugo zum Beispiel in diesem Content Directory. Und dort habt ihr hier
zum Beispiel wie auf der linken Seite zu sehen verschiedene Markdown Dateien bei
darmstadt.ccc.de zum Beispiel. Wir haben das Impressum und so, einen Ordner mit
Posts, mit Blogposts und dort strukturiert ihr euch den ganzen Inhalt rein. In diesem
Fall kommen die Inhalte bei uns halt aus Dateien und sie sind halt strukturiert
oder semistrukturiert und ihr habt verschiedene Formatmöglichkeiten, die ihr
wählen könnt. Das heißt, wenn ihr nicht Markdown schreiben wollt, könnt ihr auch
HTML schreiben oder eine andere Form von Markup Sprache, die euch vielleicht ein
bisschen gelegener ist. Wenn ihr mal so eine Markdown Datei aufmacht, dann fällt
euch auf, dass da nicht nur Markdown drinsteht, wie hier zum Beispiel ab Zeile
10, wo es hier um Freifunk geht, sondern da gibt es auch was oben drüber. Das ist
bei Static Site Generators relativ häufig so. Ihr habt nämlich hier entsprechend ein
paar Metadaten oder wie es bei Static Site Generators häufig genannt wird, front
matter. Dieses front matter sorgt dafür, dass Static Site Generator weiß, worum es
eigentlich in dem Inhalt überhaupt geht und vor allen Dingen auch, wo er genau hin
soll. In diesem Fall haben wir hier zum Beispiel ein Layout, was festgelegt wird,
ist hier das page Layout. Wir haben den Titel der Seite. Das ist zum Beispiel, wie
gesagt, es geht hier um Freifunk, Freifunk und was hier unten ganz cool ist, das ist
ein bisschen spezifischer für den Static Site Generator: Wir legen hier eine
Menüposition fest für den entsprechenden Inhalt. Das heißt, ihr geht nicht
irgendwie, wie im Wordpress, zur Seite, schreibt die, geht ins Menü und zieht das
dann ins Menü rein, sondern ihr schreibt direkt in den Inhalt rein. So, hier, pack
das mal bitte da hin und das macht ihr alles schön von einem Ort raus und der
Static Site Generator übernimmt dann den Rest. Die letzte Variable ist etwas, was
zum Beispiel auch templatespezifisch oder themespezifisch ist. Wird bei uns zum
Beispiel verwendet. Hier für das entsprechende Bild in der jeweiligen Seite
ist hier die Hero-Variable. Die gibt es so im Static Site Generator eigentlich nicht,
wurde von mir sozusagen hinzugefügt. Und genau sowas könnt ihr auch machen, wenn
ihr zum Beispiel spezielle Bedürfnisse für Variablen in euren Templates habt. Wenn
ihr irgendwie mit Markdown und so nicht klarkommt, habt ihr auch andere Optionen,
z. B. CSV, JSON, YAML und TOML, ich habe es eben schon gesagt, strukturierte
Inhalte. Das ist zum Beispiel gut für große Datensätze. Wenn ihr zum Beispiel
ein Team in einer Firma habt, dann wollt ihr das vielleicht nicht alles so in HTML
manuell runter hacken und euch irgendwann denken, ja, doof, und irgendwo habt ihr
vielleicht mal einen Formatierungsfehler drin, dann sieht alles aus wie Grütze. Und
das macht dann eigentlich auch im Prinzip keinen Spaß, weil da macht ihr dann im
Prinzip das Layouting über die Templates und müsst euch da keine Sorgen machen. Ihr
schreibt einmal das Layout und ein Static Site Generator macht dann halt keine
Fehler und bindet euch eure coole Datenbank schön in die Seite rein und dann
ist die da vernünftig zu sehen. Außerdem vermeidet das wie gesagt Inkonsistenz.
Wenn ihr jetzt zum Beispiel, worauf ich auch später noch mal zu sprechen komme,
ein Content Management System habt oder ähnliches, wo ihr Daten rausziehen wollt
oder eine andere Applikation, dann geht das bei den meisten Static Site Generators
auch. Dann geht ihr, sucht euch ne entsprechende API raus. REST ist da
eigentlich der Standard. Viele können auch einen neueren Standard, der sich GraphQL
nennt, wo ihr festlegen könnt, was genau ihr an Inhalten überhaupt abgerufen haben
wollt. Und diese Daten werden dann zur Renderingzeit quasi von der API abgerufen
und in eure statische Seite integriert. Genau, in jedem Content Management System,
normalen Content Management System, gibt es auch, zum Beispiel headless
CMS, da komme ich auch noch mal gleich darauf zurück und auch da geht das
Layouting dann wieder über das Template. Das heißt, ihr zieht euch nur die ganzen
Daten raus und packt sie in dieses Template rein und vermeidet auch da
entsprechende Inkonsistenzen. Jetzt habe ich viel über Thema Themes und Templates
geredet. An dieser Stelle sollte ich vielleicht mal ganz kurz erzählen, was das
überhaupt ist und wie sich das voneinander unterscheidet, weil das klingt ja schon
relativ ähnlich. So ein Theme ist, wie gesagt, so ein Gesamtpaket. Wenn ihr jetzt
kein eigenes Theme in Hugo schreibt, dann ladet ihr euch das irgendwo runter, bei
GitHub zum Beispiel oder so und da ist dann alles drin, da sind Templates drin,
da sind entsprechend Styles drin, Skripte und so weiter, Fonts. Das heißt, ihr
installiert das einmal, startet im Prinzip einen Static Site Generator und seid
gewaschen, gekämmt und die Seite sieht schön aus. So ein Theme stellt das
Grundgerüst der Seite entsprechend und auch die meisten Basistemplates. Das heißt
hier, wie ihr das zum Beispiel links seht, haben wir hier so ein Basistemplate mal
grafisch abgebildet. Wir haben hier eine Kopfzeile, einen Hauptbereich und einen
Footer und so beginnen meistens die Templates auch in Hugo. Das ihr ein
base-of Template habt. Und ab da werden sozusagen die Layouts ineinander immer
weiter verschachtelt und so setzt sich dann eure Seite zusammen. Eine typische
Aufteilung, habe ich wie gesagt schon erwähnt, besteht ja meist aus diesen drei
Blöcken. Ihr habt ein Headertemplate, wo eure ganzen Metadaten das CSS, das
JavaScript und so reinkommt. Ihr habt den Main-Bereich, wo euer Inhalt dann meistens
reinkommt, wo auch entsprechend die einzelnen Inhaltstemplates meistens
eingefügt werden. Und ein vierter Bereich wo euer ganzer JavaScript-Kram und so
reinkommt, wo ihr vielleicht eure Copyright Notice reinpackt und so. Das ist
meistens die Grundstruktur und dort kann es halt auch sein, dass die Templates sich
dann noch weiter verschachteln. Was ist denn so ein mysteriöses Template
überhaupt? So ein Template ist im Prinzip, es sieht, wenn ihr das jetzt mal auf der
linken Seite seht, fast aus wie eine HTML- Seite. Das ist es aber nicht ganz. Es ist
im Prinzip, wie schon der Name verrät, eine Vorlage. Und diese Vorlage sagen dem
Static Site Generator, was er mit eurem Content machen soll. Hier zum Beispiel
habe ich mal so schematisch auf der linken Seite ein bisschen skizziert, wie das
aussehen könnte. Wenn ihr zum Beispiel ein Blogpost rendern wollt, ihr extended hier
meinetwegen euer Basis Template. Extend heißt im Prinzip, ihr sagt eurem Static
Site Generator: Wenn du den Blogpost renderst, dann nutz als Basis bitte das
Template 42, also pack den Rest ins Template 42, damit Template 42 den ganzen
Rest der Seite enthält. Und ich habe zum Beispiel die article Tags wurden über
einen Artikel und so entsprechend eingefügt, das ist jetzt ganz normales
HTML, ist nicht so wichtig und ihr habt hier zwei Variablen, zum Beispiel
Titelvariable hier in Header 1 und unten in dem Div Element mit "rC3-is-awesome"
eure Inhaltsvariable, d.h. da wird der Content vom Blogpost entsprechend rein
gerendert. Und ihr könnt dort nicht nur meistens Textvariablen einbinden, sondern
dort werden auch eure Assets und Ähnliches eingebunden. Das heißt, alles wie sich die
Seite am Ende zusammensetzt, regelt ihr in der Regel über die Templates. Ich habe
euch da mal so ein Beispiel mitgebracht. Ihr seht das hier ganz gut oben. Das ist
ein Auszug aus einer Single HTML in Hugo. Das sieht ähnlich aus wie mein
schematisches Beispiel eben. Ihr extended hier das Template "main", habt dann hier
Titelvariable, zum Beispiel im Header 1 und hier die Contentvariable in main. Und
was Hugo da macht, es ersetzt hier den Titel halt durch den Titel eures
Blogposts, den Content durch den Inhalt und packt das Ganze in euer Main Template,
also in das Restgerüst eurer Seite. Ich habe auch gesagt, Hugo fängt meistens mit
so einem Bassistemplate an, das seht ihr hier unten. Wenn ihr schon HTML
geschrieben habt, kommt euch das vielleicht bekannt vor. Das ist so ein
klassisches Grundgerüst und ihr seht auch schon, hier fängt es z.B. an, dass wir die
lang, also die language der Seite hier schon mit einer Variable festlegen, die
zum Beispiel in diesem Fall bei Hugo global ist. Wir fügen hier schon direkt
ein Template ein, das ist das head Template, also das, was im HTML dieses
head-Element ist, das kommt da mit rein und der Rest kommt hier in den Body rein.
Ist auch nicht so wichtig. Ihr müsst noch nicht alles verstehen. Nur im Prinzip
müsst ihr euch vorstellen, alles was in diesen geschweiften Doppelklammern drin
ist, sind quasi Bausteine, die der Static Site Generator zur Bauzeit quasi einzeln
in die Seite rein setzt und daraus entsteht dann das Gesamtkonstrukt. Ich
habe von der head.html gesprochen, so sieht die ja auch im Prinzip aus bzw. ein
Auszug davon. Ich habe das eingefügt, weil ich euch zwei Dinge mal zeigen wollte,
nämlich könnt ihr auch ein bisschen advancederes Zeug damit machen. Ihr könnt
z.B. Conditionals auch schreiben. Meistens haben diese Static Site Generators eine
Template Language an Bord, die euch viel Dynamik erlaubt und entsprechend euch auch
die Möglichkeit bietet, auf viele Sachen sehr dynamisch zu reagieren. Zum Beispiel
sagen wir hier, wenn die Seite nicht die Homeseite ist, dann hängt bitte den
Seitentitel hinten dran. Oder wir fügen die Description der Seite entsprechend ein
und hier unten, was ganz cool ist. Ich habe schon gesagt, so ein Template bietet
euch ein bisschen mehr Möglichkeit, als nur Textvariablen einzubinden. Ihr habt
hier unten die Möglichkeit, zum Beispiel Ressourcen zu laden. Zum Beispiel haben
wir eine SASS-File, eine SCSS-File, das ist ein Superset von CSS, was sozusagen
kompiliert werden muss, damit es dann eingefügt werden kann. Und das macht unser
Static Site Generator hier mit diesen Befehlen automatisch mit toCSS macht es
das quasi zu CSS und macht es dann auch gleich minifiziert und fingerprinted das.
Fingerprinting heißt, einfach für alle die das nicht kennen, dass man quasi so eine
Prüfsumme generiert. Und dann, wenn wir das alles hier einmal gemacht haben, durch
so eine Pipeline durchlaufen lassen haben, können wir es hier direkt einfügen und
haben quasi einen relativ coolen Style- Tag. der auch relativ viel Sicherheit und
Absicherung, bietet, dass irgendwas schief laufen kann. Und das alles macht ihr hier
im Template und das ist halt in vielen Content Management System deutlich
komplizierter und oft auch manchmal nur mit Plugins zu lösen. Kurz umrissen, damit
ich es nicht ausgelassen habe. Ich habe das meiste ja eigentlich schon erzählt.
Statische Assets kommen in den eigenen Ordner und neben diesen ganzen CSS- und
JavaScript-Kram sind es Bilder und Schriftarten, die da auch gerne
auftauchen. Die könnt ihr meistens dann über absolute Pfade in eure Seite
einbinden und die meisten Static Site Generators bieten euch auch Preprocessing.
Ich habe es hier mit CSS gezeigt. Es geht auch mit Bildern und macht auch meistens
mit Bildern viel Sinn. Das heißt, ihr müsst nicht irgendwie euer
Bilderminifizierungs-Tool aufrufen und da eure Bilder einzeln reinschieben, sondern
ihr schiebt eure Bilder einfach cool in den Content-Ordner rein, sagt dem Static
Site Generator einmal bau das bitte. Und dann fallen am Ende für das Web optimierte
Bilder raus, die entsprechend schon eine angenehme Größe haben. Wenn ihr jetzt
diesen ganzen Prozess einmal durchlaufen habt, ihr euch sicher seid okay, jetzt
möchte ich das schon mal online stellen, dann kommt ihr irgendwann an den Punkt, wo
ihr das auf den Server hochladen wollt. Es ist im Gegensatz zu Content Management
Systemen hier super simpel und relativ easy, weil ihr müsst einfach nur ein paar
Dateien hochladen. Ihr sagt einem Static Site Generator meistens, dass er das
irgendwie bauen soll mit einem Build- Command. Und wenn ich diesen Build-Command
ausgeführt habt, dann kommt da ein Haufen statischer Dateien raus. Die schiebt ihr
dann meistens in ein sogenanntes Content Delivery Network oder auf einen
statischen, also auf einen normalen Webserver. Das ist beides das gleiche,
außer dass ein Content Delivery Network halt, meistens auf viele Nodes verteilt
sind. Stichwort Skalierung. Und die Last ist halt gering, weil es auch keine
Runtime gibt. Das heißt egal wo ihr das hinschiebt, die Webserver haben damit
meistens nichts zu tun, weil die müssen im Prinzip einfach nur die Seite auf die User
werfen, wenn die Seite aufgerufen wird. Das ist halt ein super einfacher Prozess.
Viele Anbieter von so Content Delivery Networks haben auch die Möglichkeit, eine
sogenannte Continuous Integration und Continuous Delivery anzubieten. Das heißt,
da müsst ihr euch nicht mal ums Bauen kümmern, da verknüpft ihr einfach das Git-
Repository und dann, wenn ihr was pusht, dann kommt es automatisch sozusagen zum
Anbieter, wird zusammengebaut und deployt. Das heißt es ist für euch super einfach,
ihr macht eine Änderung, pusht die einfach und dann wird der Rest vom entsprechenden
Anbieter übernommen. Oder ihr baut euch selbst eine CI oder eine Continuous
Delivery. Das geht natürlich auch. Das wird dann entsprechend über Webhooks
getriggert. Kommen wir noch kurz zum Vergleich. Es ist schon ein bisschen her,
aber ihr erinnert euch vielleicht noch an den Anfang. Ich habe so ein paar Punkte
gemacht und die möchte ich mal ein bisschen dem Static Site Generator
gegenüberstellen. Zum ersten waren es Sicherheitsupdates. Ihr habt natürlich
hier kein Zugriff aufs Backend. Das heißt, es wird natürlich erst mal schwierig, das
Content Management System, was hier entsprechend nicht vorhanden ist,
natürlich anzugreifen. Das heißt, ihr müsstet euch an den Webserver oder
ähnliches machen, um überhaupt Zugriff zu bekommen. Und wenn die Seite einmal online
ist, dann braucht die auch erst mal keine Sicherheitsupdates. Außer vielleicht, wenn
mal Frontend-Updates, wenn irgendwelche bestimmten Standards auslaufen. Wenn ihr
eure Seite mit HTML 1.0 geschrieben habt, dann wird die vielleicht irgendwann nicht
mehr dargestellt oder wenn ihr die für den Internet Explorer optimiert habt. Das
Backend benötigt natürlich Wartung, auch die Hosting Hardware und Software benötigt
Wartung. Das ist natürlich selbstverständlich, aber es ist halt schon
deutlich geringerer Aufwand. Die Features können überhaupt nicht wirklich kaputt
gehen, weil die Inhalte meistens über Standards kommen, das heißt HTML ist
standardisiert, CSS ist standardisiert und auch JavaScript ist standardisiert. Das
veraltet irgendwann, aber bis das veraltet, habt ihr wahrscheinlich eure
Seite schon mal umgebaut und die Portierung auf ein anderes System oder
auch von einem entsprechenden Content Management System ist halt super einfach
weil diese Standards halt existieren. Die Plugin-Hölle, die gibt es eigentlich so
nicht mehr wirklich. Es gibt Static Site Generators, die halt entsprechend Plugins
euch bieten, aber die machen euch erst mal keine Probleme, wenn die outdated sind und
ihr habt relativ viel Zeit auch entsprechend dort eine eigene Lösung zu
implementieren oder auf eine andere Lösung zu wechseln, weil diese Plugins halt nicht
irgendwo online liegen, sondern die sind halt bei euch lokal und bauen nur die
Seite. Und wenn da mal was kaputt geht oder outdated ist, dann ist das nicht
direkt für Nutzer sichtbar. Genau. Ich habe eben schon kurz von Skalierung
gesprochen. Das ist halt bei Static Sites super einfach, natürlich auch nicht
unendlich erweiterbar. Wenn so ein Webserver irgendwie eine riesen
Menschenmasse abkriegt, dann geht der irgendwann auch mal in die Knie. Aber dass
das passiert ist halt wesentlich später. Auch cool ist halt, dass ihr im Content
Delivery Network die Seite verteilen könnt auf verschiedene Nodes und euch so
entsprechend ein bisschen Skalierungsaufwand ersparen könnt. Das
Ausrollen ist außerdem sehr einfach. Das heißt, wenn ihr eine Änderung haben wollt,
dann müsst ihr nicht anfangen, irgendwie Datenbanken zu migrieren, die PHP-Version
zu updaten, irgendwelche Plugins zu enabeln, sondern ihr schiebt einfach die
Dateien auf den Server und es läuft. Eine Datenbank gibt es natürlich in diesem Fall
dann auch entsprechend nicht. Die muss nicht mit skalieren. Das einzige was es
geben kann, ich habe es vorhin gesagt, wenn ihr z.B. eine API verwendet und ihr
wollt zum Beispiel auch die API nicht nur vom Static Site Generator direkt beim
Rendering aufrufen lassen. Dazu komme ich nämlich gleich, sondern auch über über
JavaScript z.B. wenn jemand die Seite aufruft, dann muss diese API entsprechend
auch mit Skalieren und auch entsprechend abgesichert sein. Aber das ist dann ein
Problem, mit dem man sich dann beschäftigen muss. Und es gibt auch da ein
paar Vorteile, weswegen man trotzdem einen Static Site Generator verwenden möchte.
Kommen wir jetzt mal noch ein bisschen zu advancteren Themen. Ich habe gerade eben
schon gesagt, wie ist das denn, wenn ihr eine API abrufen wollt? Wenn ihr zum
Beispiel eine statische Seite generiert, aber trotzdem vielleicht Änderungen
schnell sichtbar haben wollt? Weil das kann häufiger schon mal sein. Da gibt es
einen Prozess, der sozusagen sich darum kümmert, dass wenn ihr eine Seite aufruft,
dass sie dann entsprechend mit Inhalt gefüllt wird, dass sie sozusagen mit
JavaScript Wasser übergossen wird und dann anfängt, auf einmal neue Inhalte
nachzuladen. Dieser Prozess nennt sich Hydration. Da gibt es zwei verschiedene
Techniken, da gibt es einmal das partial hydration. Das heißt, bestimmte Inhalte
der Seite werden einfach nur sozusagen mit Dynamik versehen, mit JavaScript. Das
heißt, ihr seht es auch unten in der Grafik: Die Seite läd, dann wird die Seite
aufgerufen, dann hat die ein bisschen Inhalt, der ist hier halt noch orange und
dann kommt die Hydration in diesem orangenen Bereich und hängt sich da rein,
sozusagen mit JavaScript und lädt vielleicht Inhalte nach. Und auf einmal
sind da plötzlich drei Blogposts, weil vielleicht der Rendering Prozess noch
nicht hinterher gekommen ist, weil die den halt gerade just veröffentlicht ist. Oder
ihr habt eine ganz hitzige Kommentarspalte und viel zu rendern, das lohnt sich jetzt
einfach mal gerade nicht. Ihr könnt es auch mit lazy Hydration machen. Das hat
sogar noch den Vorteil, dass ihr entsprechende Inhalte nur hydrated, wenn
sie überhaupt in den Sichtbereich kommen. Das ist, wenn ihr viel Hydration nutzen
wollt, sinnvoll, weil ihr dann nicht anfangt, dem Client irgendwie mit ganz
viel JavaScript um die Ohren zu werfen. So, wir kommen auch langsam Richtung Ende,
keine Sorge. Wir haben hier noch die deferred Static Site Generation. Das ist
ein cooler Mittelweg, wenn ihr zum Beispiel sagen wollt: Okay, ich hätte gern
trotzdem noch den Server und ich hätte gerne schnelles Rendering und es soll
alles schnell bereitgestellt werden. Ist das hier ein cooler Weg. Ihr habt einen
Server im Hintergrund, der quasi wie ein CMS läuft. Hier ist es zum Beispiel unten
in der Grafik von Gatsby, und ich sehe, die Quelle ist abgeschnitten. Das sollte
vielleicht mal fixen danach ist auch egal. Ich habe jetzt gesagt von gatsby.org ist
das gerade und dieser Server, der läuft im Hintergrund und liefert die Seite aus. Und
jedes Mal, wenn diese Seite ausgeliefert wird und es gab eine Inhalts-Änderung,
dann wird ein Abbild automatisch generiert. Das wird im Cache abgelegt und
wenn die nächste Person kommt, kriegt die nur den Cache zurück geworfen. Das heißt
im Prinzip habt ihr immer ein Abbild, was sozusagen inkrementell mitgeneriert wird
und es fühlt sich an wie eine statische Seite, skaliert auch ähnlich. Aber ihr
habt eben immer noch die Dynamik des Servers hinten dran und könnt schnell auf
Änderungen reagieren. Wenn ihr sagt, okay, ich will mein Content Management System
nicht komplett aufgeben, dann gibt es auch so coole hybride Ansätze und auch Plugins
für viele Content Management Systeme. Seid gewarnt, ihr nehmt natürlich die vielen
Nachteile des Backend-Servers dann mit euch. Aber wenn ihr sagt, ihr wollt nur
skalieren und Sicherheitsupdates sind für euch kein Problem, ist das vielleicht für
euch ein Ansatz. Ihr habt auch dort die Möglichkeit, entsprechend dafür zu sorgen,
dass auch die Leute weiterhin die Seite pflegen können. Mir fällt auch auf, dass
da eine Slide irgendwie fehlt mit dem mit dem Workflowwechsel, deswegen baue ich das
hier schnell ein. Die Leute können halt weiterhin sozusagen über eure Seite
entsprechend den Content pflegen für eure Redakteure. Wenn ihr ein größeres Team
habt, ändert sich nichts. Und so habt ihr weiterhin alles im Griff und habt trotzdem
die Möglichkeit, die Dinge statisch zu skalieren und teilweise bieten auch die
Content Management Systeme die Möglichkeit, das in ein Content Delivery
Network zu schieben. Das heißt noch nicht mal euer Server hat eine wirkliche Last
und der Server, auf dem die Seite liegt, ist kein Angriffsvektor für euer Content
Management System. Kurz als Ergänzung, weil das vorhin gefehlt hat aus
irgendeinem Grund: Wenn ihr ein Content Management System habt, bietet es meistens
auch eine API um dort Inhalte abzurufen. Das heißt, wenn ihr entsprechend WordPress
oder ähnliches habt, hat es meistens eine Rest API und ihr könnt auch die natürlich
mit dem Static Site Generator anzapfen, um entsprechend Inhalte abzurufen und sie
dann rein zu generieren. Das heißt, es ist für euren Workflow eigentlich ganz cool,
weil ihr da nicht viel ändern müsst. Also für eure Redakteure oder ähnliches ändert
sich nichts, sondern es generiert sich einfach eine Seite hintendran mit und das
Editing Frontend bleibt quasi gleich. NEOS ist übrigens auch ein bekanntes Beispiel.
Ist ein bisschen anders. Das generiert komplett statische Seiten, ist aber auch
TYPO3 ähnlich. Das heißt für kleinere Installationen vielleicht nicht so ganz
geeignet. So, das war jetzt viel Inhalt. Kommen wir zum Fazit. Sind Static Site
Generators die Lösung für alles? Ist das irgendwie das, was man einfach die Magie,
die man über alles drüber gießen kann und dann funktioniert alles? Nein, das sind
sie eigentlich nicht. Ich will ja auch nicht Content Management Systeme
runtermachen, aber sie sind eine coole Möglichkeit, um euch hohe Flexibilität zu
bieten, um euch hohe Skalierbarkeit zu bieten und euch zum Beispiel auch die
Wartung zu nehmen. Wenn ihr sagt, ihr baut ein kleines Blog zum Beispiel, da habt ihr
ja keine große Instanz von WordPress, sondern ihr schreibt euer Blog, ihr postet
den Eintrag, dann geht er online und dann müsst ihr euch da keinen Kopf drum machen.
Der liegt irgendwo. Und wenn ihr Aufmerksamkeit mit eurem Inhalt generiert,
dann ist das für euch kein Problem, weil der Blog skaliert dann ordentlich mit. Und
ihr habt auch hohe Aufrufgeschwindigkeiten. Was ich übrigens
vorhin noch nicht erwähnt habe, was auch sehr cool ist, ist, dass ihr natürlich
sofort mit dem Inhalt da seid. Das heißt, ihr müsst es nicht dynamisch nach
generieren. Und wenn ihr zum Beispiel jemanden oder eine Suchmaschine habt, die
Inhalte in der Seite sucht, dann sind die Inhalte auch sofort da. Oder zum Beispiel
eine Person mit Screenreader. Dann hat sie auch sofort ein statisches Abbild der
Seite, wo nichts irgendwie noch komisch mit Magie nachgeneriert wird und die
Person kann die Seite auch sehr schnell und ordentlich durchsuchen. In diesem
Sinne vielen Dank fürs Zuschauen oder Zuhören oder wie auch immer und ich bin es
auf jeden Fall mal gespannt auf eure Fragen und hoffe, ich habe euch nicht
allzu sehr mit dem ganzen Inhalt erschlagen. Und ja, cool.
Herald: Ja, danke für diesen super Vortrag. Wenn ihr jetzt noch Fragen habt,
könnt ihr die gerne auf Twitter und Mastodon stellen unter dem Hashtag
#rC3cwtv, also rC3 Chaos West TV. Unser Signal Angel wird sie dann mir schicken,
damit ich sie stellen kann. Gleich am Anfang ist die Frage gestellt worden,
können auch Videos eingebettet werden? Vielleicht kann man noch darstellen, was
mit Static Sites geht und was nicht? Avocadoom: Du schneidest bei mir manchmal
mit dem Audio ein bisschen ab, aber ich glaube, ich habe das meiste von der Frage
tatsächlich verstanden. Die Videos können tatsächlich eingebettet werden. Ich glaube
Tooling, um Videos zu optimieren, gibt es meistens nicht. Aber natürlich habt ihr
die Möglichkeit, wie bei allen anderen statischen Assets auch, dass ihr einfach
die Videos auf dem Webserver mit hochladet. Meistens in diese Static
Directory sozusagen, wenn euch das lieb ist und sie da entsprechend einbettet und
dann dort sozusagen mit Video Elementen im HTML oder mit einem Video Player Library
in JavaScript entsprechend diese Dinge einbettet. Es gibt natürlich auch die
Möglichkeit, dass ihr anfangt irgendwie YouTube oder Vimeo oder was auch immer mit
der API anzuzapfen und so entsprechend Videos einbettet. Also da sind euch die
Möglichkeiten relativ offen. Ihr müsst nur ein bisschen darauf gefasst sein, dass
natürlich Videos eine hohe Last für den Webserver bieten. Das heißt, da fließen
relativ viele Daten, aber in der Regel ist es auch kein großes Problem.
Herald: Danke! Könntest du noch ein Beispiel bringen, was man nicht mit einer
statischen Seite realisieren kann. Avocadoom: Nicht mit einer statischen
Seite realisieren? Im Prinzip kann man sehr viel mit einer statischen Seite
realisieren. Was man natürlich nicht realisieren sollte oder könnte ist
natürlich, sind Seiten mit sehr viel dynamischen Inhalt, sage ich mal so. Also
wenn ihr zum Beispiel jetzt anfangt, ich habe es vorhin mit der hitzigen
Kommentarspalte gesagt, wenn ihr jetzt irgendwas habt, wo ihr viele Kommentare
drin habt und ihr wollt da nicht viel mit JavaScript oder so arbeiten, sondern das
relativ statisch lassen, dann werdet ihr schnell auf das Problem stoßen, dass
nicht, wenn jemand alle 10 Sekunden kommentiert, dass ihr dann anfangen könnt,
die Seite neu zu rendern, weil das queued dann ewig ab und irgendwann zieht eure
Seite nur noch so hinterher mit dem Rendering oder das Rendering wird dauernd
abgebrochen. Das heißt, wenn ihr sehr, sehr, sehr viele dynamische Inhalte habt,
dann könnte es tatsächlich irgendwann ein Problem werden, das zu realisieren. Aber
ansonsten kann man eigentlich relativ viel mit statischen Seiten realisieren.
Herald: Dann noch eine Frage zur Geschwindigkeit. Es kommt dann öfter vor,
dass man Kilobytes an Frameworkcode preloaden muss, bevor die Seite überhaupt
reagiert. Gibt es da Tipps, wie man die Ladezeit bei static sites gering hält?
Avocadoom: Da gibt es tatsächlich Tipps, also wenn man zum Beispiel mit einem
JavaScript Static Site Generator arbeitet, wie Gatsby oder so, gibt es dort die
Möglichkeiten, dass man, wenn man dort ein Framework wie React einbindet, das sie
sogenannte Tree shaking mit sich bringen. Das heißt im Prinzip, dass sie sozusagen
an dem Dependency-Baum, den man aufbaut, um es mal bildlich zu beschreiben,
schütteln, d.h. sie schütteln da so lange dran, bis nur noch das Notwendigste
dranhängt und werfen den Rest des Frameworkcodes weg. Das heißt, ihr habt am
Ende ein gebündeltes JavaScript, was quasi relativ minimal ist. Natürlich ist es
trotzdem immer noch ein bisschen Frameworkcode. Viele bieten auch
sogenanntes Code Splitting an, das heißt im Prinzip, dass ihr nur den für die Seite
notwendigen Code ladet. Und wenn ihr eine neue Seite ladet, dann ladet ihr den
restlichen notwendigen Code. Das kann man auch manuell machen. Ich habe es ja von
darmstadt.ccc.de genannt gehabt. Da haben wir es tatsächlich so gemacht, dass wir
den Kalender mit JavaScript realisiert haben, weil wir dort iCal parsen und das
ist auch relativ dynamisch. Und dort ist es tatsächlich so, dass wir diesen Code
nur laden, wenn die entsprechende Seite aufgerufen wird mit einer entsprechenden
Templatevariable, die dann sozusagen auf wahr gesetzt wird. Und dann wird dieses
JavaScript eingebunden. Das heißt im Prinzip die Dinge, die man dann da
mitnehmen kann, ist zum einen halt es manuell aufzuteilen, nicht einfach nur die
Binaries irgendwie aus den Release Renders oder aus den Release Builds quasi einfach
in den Header einzubinden, sondern Bundler zu verwenden, auch wenn es ein bisschen
schmerzhaft ist oder halt auch einfach das Ganze manuell aufzuteilen.
Herald: Danke! Dann noch eine Frage, was du von verschiedenen Frameworks...
Avocadoom: Du bist gerade super leise, kannst du gerade mal gucken ob du...
Herald: Geht es besser? Avocadoom: Ähh ja, naja, es geht.
Herald: Okay, was ist deine Meinung zu headless CMS für static site generator?
Avocadoom: Tatsächlich eine sehr gute. Headless CMS ist tatsächlich was, wo ich
auch in gewisser Weise die Zukunft sehe und viele etablierte CMS Lösungen arbeiten
natürlich auch auf diesen Punkt hin, dass sie zum headless CMS werden können oder
zumindest zum teilweise headless CMS. Wenn ihr nur 'ne static site habt, ist es
natürlich erst mal nur so die halbe Miete, aber da ist es halt auch schon ganz cool.
Aber was halt vor allem der Vorteil ist, wenn ihr anfangt, die Inhalte noch auf
weitere Endgeräte zu bringen. Das heißt zum Beispiel, wenn ihr jetzt eine
Newsseite seid und ihr baut euch jetzt eine mobile App, dann müsst ihr nicht noch
eine API dafür schreiben, sondern die API liegt halt einfach schon da. Und das
bietet euch natürlich viele Vorteile. Das heißt, wenn ihr verschiedene Zielgeräte
damit ansprechen wollt, habt ihr halt sofort eine API und die API ist halt auch
unsere einzige source of truth. Das heißt, die könnt ihr pflegen, da könnt ihr dafür
sorgen, dass sie ordentlich läuft und habt so die Möglichkeit halt auch das
entsprechend in andere Services mit einzubinden. Oder auch, weiß ich nicht,
ein Sprachassistentenskill, was weiß ich. Es läuft halt alles auf die selbe source
hinaus und ich finde das sehr gut. Das ist eine sehr gute Lösung. Auf jeden Fall.
Herald: Cool. Was ist deine Einschätzung zu Graph?
Avocadoom: Du bist wieder super leise, sorry.
Herald: Was ist deine Einschätzung zu Graph, du hast es ja vorher einmal kurz
erwähnt. Avocadoom: Meine Meinung zu, jetzt warst
du wieder laut noch mal.. Herald: Was ist deine Einschätzung zu
Graph? Avocadoom: Zu Graph? Meine Einschätzung zu
Graph ist tatsächlich auch eine relativ gute. Graph arbeitet ja an sich nicht
unbedingt direkt mit static site generation, sondern cached das ganze, ja,
in so Blöcken quasi, also im Prinzip werden keine Seiten raus gerendert,
sondern die Seite speichert sich oder das CMS speichert sich quasi so Blöcke der
Seite ab und fügt die am Ende nochmal kurz mit PHP zusammen. Es gibt aber auch die
Möglichkeit, das statisch zu machen, aber so oder so ist es ganz sinnvoll. Graph
legt damit ja so ein bisschen so eine Mitte, weil es ja aus diesem Bereich der
flat file Content Management Systeme bekommt. Das heißt, für alle, die das
nicht kennen. Das sind Content Management Systeme, die über das Dateisystem arbeiten
und nicht über eine Datenbank. Und ja, es ist auf jeden Fall ein cooler Mittelweg.
Es ist halt trotzdem ein System, was Sicherheitsrisiken bieten kann und wo man
natürlich immer ein Backend mit schleppt. Aber es bietet halt auch hohe Flexibilität
und Performance halt gerade dadurch, weil es mit diesem Cachingmechanismus arbeitet
oder über ein Plugin sogar mit static site rendering. Und ja, es ist auch eine sehr
positive Meinung, die ich dazu habe und es auf jeden Fall ein cooler Einstieg, wenn
man mal so ein bisschen in diese Richtung gehen will von: Wie sieht das alles aus,
wenn ich was sozusagen einfach statisch mache und nicht so krass hoch dynamisch
und vor allem wenn ich mal eine große Datenbank wegwerfen will.
Herald: Die nächste Frage wär: Ist aus deiner Sicht PHP noch zeitgemäß?
Avocadoom: Ja, PHP ist zeitgemäß. Tatsächlich weiß ich, dass viele PHP total
abhaten, aber ich finde der PHP-Entwickler oder der PHP-Schöpfer, ich weiß seinen
Namen gerade nicht. Ich habe mal einen Talk von dem gesehen, vor einem Jahr
glaube ich ungefähr. Und er gibt sich halt große Mühe bzw. sein Team gibt sich große
Mühe, dass die Sprache immer moderner wird, immer aktueller. Klar ist es nicht
die schönste Sprache, mit Sicherheit, aber PHP ist halt immer noch in seiner
Möglichkeit, dass man es einfach relativ easy in HTML z.B. einbauen kann oder
dadurch, dass es fast auf jedem Webserver läuft, eigentlich fast ungeschlagen. Und
ja, ich weiß, es ist wirklich von der reinen Theorieperspektive mit Sicherheit
nicht die schönste Sprache, aber es ist definitiv immer noch zeitgemäß.
Herald: So, im Chat, wie IRC, der... Okay, geht besser?
Avocadoom: Von wem jetzt, von mir schon? Ah, okay, das erklärt auch, warum er immer
wieder leise ist. Aber ja, gerade übrigens, ich überbrück' das mal ein
bisschen, gerade mit dieser ganzen Geschichte, mit PHP 7 und PHP 8 sind ja
viele Änderungen reingekommen, die der Sprache einen ordentlich modernen Anstrich
verleihen. Und es gibt auch immer wieder neue Frameworks und Ansätze, die PHP-
Entwicklung immer leichter machen und immer moderner. Und ich denke schon, dass
das auch Zukunft hat. Herald: So, ich hoffe, man hört mich?
Avocadoom: Ja, man hört dich. Herald: Wie sieht es mit der
Kompatibilität für Smartphones bei statischen Seiten aus?
Avocadoom: Da ändert sich eigentlich nichts, also es ändert sich ja quasi nur
was wie die Seite ausliefert. Aber wie die Seite dargestellt wird, ist quasi ja für
euer Smartphone das gleiche. Das heißt nur, wie die Seite quasi vorher
zusammengebaut wird und so, das ist quasi das wichtige, was sich ändert. Aber wie
die Seite dann dargestellt wird also mit JavaScript und CSS und so. Das bleibt ja
das gleiche. Wenn ihr jetzt noch ein Content Management System habt, wo ihr so
eine spezielle mobile Seite habt, was man in der Regel heute nicht mehr haben
sollte, weil man das inzwischen gut mit CSS und Co lösen kann, dann habt ihr
vielleicht ein Problem, dass ihr zwei Seiten bauen müsst, aber ansonsten ist
eigentlich die Kompatibilität mit Smartphones ziemlich super und die meisten
Smartphones können auch, also da können die eigentlich alle auch JavaScript
vollständig ausführen, die haben ja mit Safari oder Chrome oder was auch immer
eine vollständige JavaScript-Engine mit drinnen, also die Kompatibilität ist
eigentlich komplett gegeben und viele Newsportale und so arbeiten ja schon mit
diesen Techniken, das heißt dass ist eigentlich auch schon etabliert und
getestet, dass das läuft. Herald: Noch eine Frage, so einem Chat wie
der IRC. Wäre es da eine gute Idee, eine statische Seite daraus zu machen, wenn der
Chat dass einzige ist, was man machen will? Weil so wie ich das verstehe, wäre
es dafür ja eher mehr Last für den Server, oder?
Avocadoom: Ja, das ist wie gesagt das gleiche Beispiel mit der Kommentarspalte.
Wenn ihr dynamischen Inhalte wie ein Chat habt, dann wollte ihr die nicht immer
statisch rendern, weil die ändern sich ja ständig. Also das sind ja Inhalte, die
immer immer wieder sozusagen entsprechend sich ändern. Das heißt, was ihr da machen
könnt, wäre zum Beispiel ihr baut so eine Frontend Anwendung und macht es nur mit
JavaScript und zieht euch das darüber. Aber das ist nicht das, was ich unter
einer statischen Seite sozusagen verstehe, weil eine statische Seite ist für mich
was, wo der Inhalt quasi schon generiert ist und in HTML vorliegt, wenn ihr die
Seite aufruft. Also da gibt es eigentlich nur die zwei Wege: Entweder man macht das
komplett über eine Backend Anwendung oder man macht es komplett im Frontend, aber
man kann halt sozusagen also das halt vorher auszuliefern in gegossenes HTML,
was sozusagen Accessibility Tools oder eine Suchmaschine lesen können, dass ist
eigentlich eher unvorteilhaft, weil dann müsste man alle paar Sekunden die Seite
neu rendern und das ist ja viel zu viel Last.
Herald: Ja, braucht man dann für eine statische Seite mehr Leistung beim Client?
Avocadoom: Nein, in der Regel eigentlich nicht. Also viele Seiten setzen
heutzutage, also das Einzige was halt viel Leistung braucht ist JavaScript. Aber
viele Seiten setzen ja heutzutage schon auf JavaScript, auch wenn sie vom
Conten tManagement System kommen. Und das JavaScript, was zum Beispiel verwendet
wird, um Hydration zu betreiben, ist nicht unbedingt etwas, was die Leistung zieht.
Also der Leistungsunterschiede ist eigentlich quasi gleich Null. Und wenn du
zum Beispiel komplett auf JavaScript verzichtet, dann habt ihr sogar noch einen
Leistungsboost eigentlich in der Regel. Außer ihr schreibt jetzt komplett
verrücktes CSS, aber das ist dann auch wieder eine Sache die euch auch mit
Content Management Systemen passieren kann. Also eigentlich ist der
Leistungsunterschiede der gleiche bzw. vielleicht habt ihr sogar mehr Leistung
wenn in eine statische Seite baut. Je nachdem wie viel JavaScript ihr sozusagen
in eure Seite einfügt. Wenn ihr da jetzt natürlich das große 3D Rendering, ich zieh
mir ständig Content rein JavaScript baut, dann hat sie natürlich mehr
Leistungsverbrauch, aber das ist nicht zwingend ein Problem einer statischen
Seite. Herald: Du hast ja zum Ende von deinem
Vortrag noch Barrierefreiheit angesprochen. Muss man da auf irgendwas
achten, dass es dann für Screenreader und so gut lesbar ist?
Avocadoom: Also was ich mir dabei gedacht habe, ist im Prinzip, dass so ein
Screenreader natürlich einfach glaube ich besser damit klarkommt, wenn er schon
vorher das ganze HTML vorliegen hat. Was ich halt prinzipiell beachten würde, das
einfach die generellen Accessability- Guidelines zu beachten sind, von der W3C
und ähnlichen, das ist sowieso immer klar. Das sollte man auch generell, wenn man
eine Seite mit was auch immer baut machen. Aber was ich sehr gut finde ist halt, dass
wenn man zum Beispiel jetzt kein JavaScript enabed hat, weil man damit
vielleicht nicht klarkommt, wenn man Accessability Tools hat und nur die Seite
statisch rausgerendert sehen möchte, ohne irgendwelche Hydration oder ähnliches,
dann kann man halt mit den Accessability Tools quasi relativ easy darüber gehen.
Und beachten muss man dabei eigentlich nichts Spezielles. Ich sehe es einfach nur
als Vorteil, wenn das HTML quasi direkt vorliegt und so ein Tool sich nicht darum
kümmern muss, dass irgendwo noch was dynamisch hinzugefügt wird, sondern
Screenreader direkt anfangen kann, das einmal von oben nach unten abzuarbeiten.
Also beachten muss man dabei nichts. Ich habe das mehr erwähnt, weil ich das
einfach sehr sinnvoll finde, dass man damit mehr Leute sozusagen auch targeten
kann und dass man dafür sorgen kann, dass man nicht darauf achten muss, dass die
jetzt vielleicht irgendein Tool verwenden, was mit ich "füge hier mal mit Dynamik
ganz viel Spaß hinzu" irgendwie nicht klar kommen kann.
Herald: Ah ja, cool. Welches Backend würdest du für Nutzer empfehlen, die kein
Markdown schreiben wollen? Avocadoom: Hmmm, das kommt drauf an, was
man machen will. Wenn man einen Blog hat würde ich tatsächlich entweder auf ein
Blog Service setzen, also so was wie Medium oderso und mich da an der an die
API anschließen, weil das einfach relativ gute editing experience bietet oder auch
an anderen Hosting Service oder z.B. auch einfach ein klassisches Content Management
System wie WordPress oder ähnliches verwenden. Es gibt tatsächlich auch so
Frontends für einige Static Site Generators, die euch das sozusagen
ermöglichen, dass man dann so einen Editor davor hat, der dann Markdown am Ende
hinten raus rendert, aber die haben meistens den Nachteil, dass die oft auf
dem Client laufen und dann bei euch laufen, auf dem Desktop quasi, und dass
man dann trotzdem sich immer noch darum kümmern muss, dass das dann irgendwo in
git gepusht wird und ähnliches und dann irgendwo hoch kommt. Und daher würde ich
eher sagen Notfalls, wenn man zum Beispiel mit Wordpress schon mal gearbeitet hat
oder mit einem ähnlichen System gucken ob das erst mal eine Rest-API anbietet und
sich darüber versuchen mit dem Static Site Generator zu verständigen.
Herald: Es kommt noch viel: "Danke für deinen coolen Talk" rein.
Avocadoom: Gerne. Ich hoffe euch hat es Spaß gemacht.
Herald: Genau. Vielleicht noch eine letzte Verständnisfrage. Der Nutzer fragt / oder
die Nutzerin: Ich verstehe jetzt noch nicht zu 100 Prozent was genau man mit
statischen Sites verhindern will? Ist es, dass der Client nicht direkt mit dem
Server interagiert oder dass es keine User Eingaben gibt, die an einen Server
weitergegeben werden? Avocadoom: Beides will man nicht unbedingt
verhindern. Was man vor allem verhindern will ist, dass man sich, dass man zum
Beispiel ein System auf dem Server liegen hat, wie zum Beispiel ein, also wenn ihr
ein klassisches Content Management System habt, ich erkläre es mal so, so ein
WordPress oder so, oder ein Joomla oder ein Drupal oder was auch immer dann
generiert euch das beim Aufruf der Seite das HTML, was dann an den Client
ausgeliefert wird. Dass heißt das System, wenn so ein Client das aufruft, dann
interagiert das System damit. Oder habt ihr zum Beispiel eine Suche drin und so
eine Suche die sucht natürlich in der Datenbank. Das heißt, wenn ihr diese Suche
entsprechend manipulieren würdet und es wäre jetzt bekannt, dass in eurem Content
Management System eine SQL-Injection möglich wäre, dann können Sie so rüber ins
System kommen. Das heißt, wenn das System nicht vernünftig wartet und ihr dieses
SQL-Injection Problem Update nicht installiert, dann ist diese Lücke
sozusagen da, dann stehen da sozusagen die Tore offen. Das heißt, das ist zum
Beispiel der Punkt, dass ihr da sagen könnt diese statische Seite bietet einfach
kein direktes Einfallstor in euer System, weil sie quasi keine direkte Interaktion
mit dem Backend ermöglicht. Das bietet halt auch den zweiten Vorteil, dass ihr
Performance habt, weil ihr quasi nicht bei jedem Aufruf anfangt, die Seite neu zu
generieren, sondern ihr habt einfach die fertig generierte Seite und liefert sie
nur noch an das Endgerät aus. Das heißt ihr interagiert immer noch mit einer Art
Server, aber ihr interagiert nicht mit dem Content Management System und habt nicht
die Möglichkeit, dass sie zum Beispiel in eurer Datenbank einfallen. Und das sind
eigentlich die zwei hauptsächlichen Gründe, weswegen man Static Site
Generation vorziehen möchte. Außerdem hat es halt den großen Vorteil, dass dadurch,
dass alles vorgerendert ist, dass diese entsprechende Last, also diese
Performance, ich habe es ja schon erwähnt, dass quasi einfach das passiert, ihr
schiebt die Seite einfach einmal hoch und dann ist sie da und dann wird sie
abgerufen und ihr müsst nicht gucken, dass irgendwo was kaputt gehen kann.
Herald: Ja, danke für das Beantworten der Fragen und auch für diesen super coolen
Vortrag hier bei Chaos West.
*rc3-nowhere Abspannmusik*
Untertitel erstellt von c3subtitles.de im Jahr 2021. Mach mit und hilf uns!