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!