Webseitenbau

15.10.2020 Jonas L. Technik

Webseiten sind etwas alltägliches geworden, die Erstellung davon aber noch nicht. Daher etwas zu den Möglichkeiten für die Erstellung von Webseiten.

statische Webseiten

Eine statische Webseite klingt erst einmal so, als ob sie unveränderlich wäre. Eine unveränderliche oder veränderbare aber nie veränderte Webseite ist aber nicht statisch, sondern ungepflegt. So viel zur Abgrenzung des Begriffs.

Webseiten werden ja von Webservern ausgeliefert. Im Fall einer statischen Webseite sind diese Webserver dumm - man lädt eine Seite hoch und diese liefern die einfach nur aus. Das Vorteil am dummen Webserver ist, dass er leicht ersetzt werden kann - sowohl bei den Serverprogrammen als auch bei Hostingdienstleistern hat man also eine große Auswahl. Aber auch eine Hochverfügbarkeit bzw. Redundanz ist hier nicht kompliziert, weil sich mehrere Server, die die Seite ausliefern, nicht austauschen müssen*. Die Anfrage muss nur bei irgendeinem ankommen und kann dann beantwortet werden.

* Ja, für SSL-Zertifikat-Erneuerungen und -Rollouts und für das Hochladen einer neuen Seitenversion muss es einen Mechanismus geben. Aber sonst müssen die Server nicht miteinander sprechen.

per Hand schreiben

Das klingt viel zu kompliziert - besonders für diejenigen, die es noch nie gemacht haben. Aber erst dadurch versteht man vollständig, wie eine Seite funktioniert. Man sollte es also einmal gemacht haben. Für die erste Webseite kann es ungünstig sein, weil man sich mit vielen Details beschäftigen muss und man so entsprechend viel Zeit benötigt.

Der Vorteil hierbei ist, dass die entstehende Seite geringe Anforderungen an die Bandbreite der Besucher hat, sofern man es nicht mit Bildern übertreibt - ein riesiges Skript oder Stylesheet muss ja erst mal geschrieben werden.

Man schreibt also manuell HTML- und CSS-Dateien. Bei dieser Variante sieht man auch, was alles ohne JavaScript möglich ist.

Hier empfehle ich https://developer.mozilla.org/en-US/docs/Learn. Als Vorgehensweise empfehle ich:

  • Inhalte und Struktur konzipieren
    • noch keinen Code schreiben
    • über Navigationskonzept nachdenken (z.B. Menüleiste …)
    • an verschiedenen Bildschirmgrößen denken
    • URLs planen (z.B. “Über uns” als /ueber-uns)
    • über Mehrsprachigkeit nachdenken (dann könnte die Sprache in die URL, z.B. /de/ueber-uns, oder man hat mehrere Domains, die man untereinander verlinkt)
  • Inhalte minimal formatiert (Überschriften und fette Schrift; alles, was ohne CSS gut geht) einfügen
    • HTML-technisch beschränkt sich das auf das Grundgerüst (html, head, title, body) und grundlegende Tags (h1, h2, h3, h4, p, b, i, u, a)
    • in diese Grundlagen kann man sich recht schnell einarbeiten
  • CSS bauen und HTML-Dateien daran anpassen, damit das Ziellayout entsteht
    • die HTML-Änderungen sollten so klein wie möglich sein, aber das macht man dann ganz von selbst, weil man nicht alles umschreiben möchte
    • idealerweise fängt man mit dem Fall “kleiner Bildschirm” an und durch Zusatzregeln per Media Query wird es dann so verändert, dass es auch große Bildschirme gut verwendet
    • ein Ziel und die schrittweise Annäherung an dieses (z.B. Navigationsleiste mobil, Navigationsleiste Desktop, Überschriften, …) ist eine passende Vorgehensweise
  • sofern man es unbedingt braucht: Skripte am Ende einfügen; Auch hier wieder die Änderungen an der HTML minimal halten
    • Skripte dienen der Verbesserung der Seite, nicht als Voraussetzung; inhaltlich sollte alles schon vor dem Einfügen der Skripte laufen
    • auch nach dem Einfügen der Skripte sollte man diese abschalten/entfernen können, ohne das zu viel verloren geht
  • in verschiedenen Umgebungen gründlich testen
    • je nach Zielgruppe auch in Browsern, die man nicht mag
  • veröffentlichen

Variation: fertiges CSS und fertiges JS verwenden

Da würde dann z.B. Bootstrap ins Spiel kommen. Damit gibt es fertige Elemente und somit ein schnelleres Erfolgserlebnis. Das allerdings auf Kosten der Seitengröße. Und wenn man nicht aufpasst auch auf Kosten des Datenschutzs: Wenn man dem “Quick Start” von der Bootstrap-Dokumentation folgt, dann gibt es Third-Party-Requests - nicht gefährlich, aber auch nicht schön. Es ist schon deswegen von Vorteil, wenn man versteht, was man macht. Auch wenn das Vorgefertigte bei einigen Details nicht passt, ist es von Vorteil, wenn man das so weit versteht, dass man es an den eigenen Bedarf anpassen bzw. für den eigenen Bedarf erweitern kann.

Variation: Hilfswerkzeuge zur Codegenerierung

Das klingt viel interessanter, als es eigentlich ist.

Manchmal nimmt man wahr, dass man sich wiederholt. Das kann z.B. ein immer gleiches Grundgerüst, ein Footer oder eine Auflistung von gleicherartigen Elementen sein. Das widerpsricht dann DRY (don’t repeat yourself).

Mit einer Internetsuche nach “html include” findet man z.B. das. Dort wird die Seite asynchron per Skript nachgeladen. Das bedeutet Skripte, Ajax und unvollständige Seiten nach dem Aufrufen - also aus meiner Perspektive Schwachsinn. Das ist etwas umfangreicher und geht auf mehrere Methoden ein. Allerdings erklärt es nicht das Konzept, sondern zeigt an Beispielen, wie man konkrete Werkzeuge verwendet - einige Vorgehensweisen dort kann ich empfehlen, andere nicht.

Die Lösungstechnologie nennt sich Template-Engine. Eine Template-Engine ermöglichen grundsätzlich zwei Aktionen: Codeblöcke (wieder)verwenden und Daten einsetzen.

Die Grundüberlegung ist, dass man wie bei “normaler” Software arbeitet - man hat einen Quelltext und eine Ausgabe. Im Quelltext steht dann etwas wie {% include "footer.html" %}, in der Ausgabe ist dann dort der Inhalt vom Footer eingefügt.

Die Ausgabe wird natürlich automatisch aus dem Quelltext erzeugt - sonst könnte man sich den Aufwand ja auch sparen. Da gibt es Lösungen wie das gulp-Ökosystem, wo man verschiedene Werkzeuge zusammenfügt, und Alles-in-einem-Lösungen, die direkt für Webseiten konzipiert sind, wie Hugo.

Hugo ist gleich ein ganzes Offline-CMS*. Offline, weil es außerhalb des Webservers läuft, der die Seite ausliefert, indem es eine statische Seite generiert.

* CMS = Content-Managment-System

sonstige Empfehlungen

Versionsverwaltung

Die langweilige Predigt, wie wichtig eine Versionsverwaltung ist, spare ich mir. Wenn man mit git überfordert ist, dann muss man lernen, damit zurecht zu kommen - oder man erstellt Sicherungskopien, bevor man an der Seite bastelt.

Nur auf die Undo-Funktion des Editors zu setzen, ist keine gute Idee.

lokales Arbeiten

Man bastelt nicht in der Produktivumgebung - das gilt auch bei Webseiten. Wenn im Hilfswerkzeug kein Webserver enthalten ist oder man kein Hilfswerkzeug verwendet, dann gibt es die klassischen Webserver, aber auch Programme wie dieses, mit denen man mal eben einen Webserver starten kann, der den aktuellen Ordner ausliefert.

Automatisierung

Maus-schieben macht keinen Spaß. Was für eine Aufgabe gibt es bei statischen Webseiten, die sich häufig wiederholt? Das Hochladen. Aber das kann man gut automatisieren:

#! /bin/bash
set -e
# bei Fehlern abbrechen

rm -rf public
# Löschen vom Ausgabeordner; je nach Tool passiert das von selbst, aber es schadet nicht
# (sofern es nicht die Quelldateien sind)

hugo
# oder was auch immer man benutzt, um die Seite zusammenzubauen und in den Ausgabeordner zu schreiben, falls man ein Hilfswerkzeug verwendet

rsync -r --progress --delete ./public/ myserver.com:/var/www/mysite.com/
# -r = rekursiv, also mit Unterordnern
# --progress = Fortschritt anzeigen
# --delete = Dateien am Ziel entfernen, die nicht mehr an der Quelle vorhanden sind

Variation: Continuous integration

Wieder mal etwas, das speziell klingt, aber es nicht ist. Es ist nur die Kombination von der Versionsverwaltung und der Automatisierung - was in der Versionsverwaltung liegt und ggf. freigegeben wurde landet damit automatisch auf der Seite.

Wenn die Versionsverwaltung per Browser genutzt werden kann, dann kann man jederzeit und von überall die Seite anpassen.

Zusätzlich kann man nicht freigegeben Änderungen automatisch an einer anderen, ggfs. versteckten Stelle, veröffentlichen. Damit kann man dann die Änderungen testen, ohne das man dafür irgendwelche Werkzeuge lokal benötigt.

Online-CMS-Systeme

Hätte ich nach den statischen Seiten etwas von dynamischen Seiten schreiben sollen? Das hätte oberflächlich betrachtet natürlich besser gepasst, aber inhaltlich eher weniger.

Bei einem Online-CMS ist der Webserver nicht mehr dumm, sondern er hat das CMS. In der Regel kann man sich dort einloggen, um Inhalte zu verändern. Um die Zuordnung zu erleichtern: Wordpress ist ein bekannter Vertreter dieser Kategorie.

Diese Variante wird oft verwendet, wenn Nicht-Techniker selbstständig Inhalte einfügen können sollen.

Ich halte nicht viel von Online-CMS-Systemen.

Baukästen

Wenn ich Baukasten sage, dann meine ich Werkzeuge, die es nur bei bestimmten Anbietern gibt, die auch gleich das Hosting übernehmen. Das kann am Ende ein Online-CMS-System sein oder ein statischer Seitengenerator mit Online-Editor und Automatisierung - für den Benutzer ist es am Ende egal, was im Hintergrund passiert, solange er es grafisch verändern kann und die Änderung veröffentlicht werden kann.

Der Vorteil ist “bequem”, der Nachteil ein Vendor-lock-in. Auch, wenn man jetzt mit den Preisen, Bedingungen und der Funktionalität einverstanden ist, so ist nicht sicher, dass das so bleibt. Man hat zwar die Rechte an den eigenen Inhalten, aber im schlimmsten Fall darf man die nach einem Anbieterwechsel neu einpflegen und die Seite wird höchstwahrscheinlich danach nicht genau so aussehen wie davor.

interaktive Seiten

Interaktiv meint alles, wo der Besucher etwas machen kann, was die Seite für andere Besucher verändert. Schön umständlich formuliert - das wäre z.B. ein Forum bzw. ein “soziales Netzwerk” oder ein Online-Shop. Die Technik sollte da nicht die größte Sorge sein, sondern die Organisation vom Betrieb und bei Interaktionen zwischen den Besuchern insbesondere die Moderation und das Fernhalten von Bots.

Teilweise reichen hier schon Online-CMS-System, z.T. braucht man “Spezialsoftware”. Für Foren und Shops gibt es schon fertige Programme. Wenn es etwas ganz Spezielles sein muss, dann braucht man eine individuelle Software. So etwas sollten Anfänger besser nicht erstellen, weil es so viele Möglichkeiten gibt, (gefährliche) Fehler zu machen. Panik machen kann aber auch nicht die Lösung sein, weil irgendjemand das Zeug ja entwickeln muss. Es ist auch nicht so, dass die anderen Seitentypen ungefährlich sind, aber bei gespeicherten Benutzerdaten führen Fehler zu deutlich mehr Ärger.

Falls Ihr etwas Neues baut, denkt bitte sehr gut darüber nach, ob es Apache + PHP + MySQL sein muss. Es gibt auch andere Lösungen. In vielen Fällen ist eine SQL-Datenbank sinnvoll, aber es gibt auch noch PostgreSQL. Anstelle von PHP verwende ich Node.JS, aber Go und Rust wären auch noch Alternativen - und es gibt noch mehr. Und auch der Apache-Webserver ist nicht die einzige Möglichkeit. Beim Standardwebhoster gibt es natürlich nur Apache + PHP + MySQL. Das alleine sollte aber keine Entscheidungsgrundlage sein - es ist ja ein Webhoster und kein Applicationhoster. Wenn man betrachtet, in welcher Umgebung Wordpress läuft, dann erklärt sich dieser Zustand bei den Webhostern.

Fazit

Je nach gewünschter Funktionalität der “Seite” braucht man eine andere Lösung. Wenn man viele Seiten baut und immer das gleiche Werkzeug benutzt, dann baut man immer wieder den selben Seitentyp oder es besteht das Risiko, dass man eine “Wunderwaffe” hat.