Make it static!

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!