Meine erste eigene Webseite war eine einzige index.html

Der Minecraft-Server brauchte eine Seite. Nicht wirklich — wir waren sechs Leute und hätten alles im Sprachchat klären können. Aber „wir haben eine Webseite" klang nach etwas, und ich wollte wissen, wie das geht.

Also habe ich eine Datei angelegt, sie index.html genannt und hineingeschrieben, was ich aus einem Tutorial abgeschrieben hatte:

<!DOCTYPE html>
<html lang="de">
  <head>
    <meta charset="utf-8" />
    <title>Unser Server</title>
  </head>
  <body>
    <h1>Willkommen!</h1>
    <p>IP: unserserver.ddns.net</p>
  </body>
</html>

Dann habe ich sie doppelt geklickt. Der Browser ging auf, und da stand es. Ohne Installation, ohne Build, ohne irgendetwas. Ich glaube, dieser Moment hat bei mir mehr ausgelöst als jedes spätere Framework.

Die Reihenfolge, in der ich alles gelernt habe

Rückblickend war meine Reihenfolge ziemlich genau die richtige, und zwar aus Versehen.

Zuerst HTML. Nur Struktur: Überschriften, Absätze, Listen, Links, Bilder. Zwei Abende lang war meine Seite hässlich, aber sie funktionierte in jedem Browser und auf jedem Handy, weil ich nichts kaputtgestylt hatte.

Dann CSS. Und zwar in einer eigenen Datei, weil im Tutorial stand, dass man das so macht. Hier ist mir zum ersten Mal aufgefallen, dass es zwei verschiedene Sorten Wissen gibt: Regeln, die man nachschlägt (color, font-size, margin), und Konzepte, die man verstehen muss. Das Boxmodell gehört zur zweiten Sorte. Ich habe zwei Wochen lang nicht begriffen, warum ein Element mit width: 100% und padding: 20px breiter wird als sein Container — bis mir jemand box-sizing: border-box zeigte und erklärte, was es tut.

Dann erst JavaScript. Und zwar nur für Dinge, die ohne es nicht gingen: ein Menü aufklappen, den Serverstatus abfragen. Dass die Seite auch ohne JavaScript lesbar bleibt, war damals keine Haltung, sondern Zufall — ich konnte einfach noch nicht genug, um es kaputtzumachen.

Tipp

Wenn dich jemand fragt, womit man Webentwicklung anfangen soll: eine Datei, ein Browser, kein Build-Schritt. Der Weg über ein Framework führt dazu, dass man drei Werkzeuge bedient, bevor man eine Überschrift zentrieren kann. Der Umweg über die Grundlagen ist kürzer, als er aussieht.

Der Serverstatus, mein erstes echtes Feature

Ich wollte auf der Seite anzeigen, ob der Minecraft-Server läuft und wie viele Leute online sind. Es gab damals frei nutzbare Dienste, die einen Serverstatus als JSON zurückgeben, und mein Code sah ungefähr so aus:

fetch("https://api.example.org/status/unserserver.ddns.net")
  .then((antwort) => antwort.json())
  .then((daten) => {
    document.querySelector("#status").textContent =
      daten.online ? `${daten.players.online} online` : "offline";
  });

Drei Dinge habe ich hier zum ersten Mal am eigenen Leib gelernt:

Netzwerkaufrufe dauern. Zwischen Seitenaufbau und Antwort vergeht Zeit, in der die Seite etwas anzeigen muss. Meine erste Fassung zeigte in dieser Zeit gar nichts, was aussah wie ein Fehler. Ein schlichtes „wird geladen …" hat das behoben.

Fremde Dienste fallen aus. Genau das ist passiert, ungefähr drei Wochen später. Mein Code hatte kein catch, die Seite blieb bei „wird geladen …" stehen, und ich habe eine Stunde in meinem eigenen Code gesucht.

Die Konsole ist kein Zufallsgenerator. F12, Reiter „Netzwerk", Aufruf ansehen: Status 503, Antwort leer. Das war das erste Mal, dass ich einen Fehler von außen nach innen gelesen habe, statt im Code zu raten. Es ist genau dieselbe Denkweise, die ich ein paar Monate vorher beim Minecraft-Server über den Speicherverbrauch gelernt hatte.

Ins Internet damit

Die Seite lag zunächst neben dem Minecraft-Server auf demselben Rechner, ausgeliefert von einem Apache, den ich installiert und nicht verstanden hatte. Später habe ich sie auf einen kleinen Webspace geschoben — per FTP, mit einem Programm, das Dateien hin- und herschieben konnte.

Was mir damals niemand gesagt hat und was ich lieber früher gewusst hätte: Ausliefern ist ein eigenes Handwerk. Eine Seite, die lokal funktioniert, kann online kaputt sein, weil Groß- und Kleinschreibung auf einem Linux-Server plötzlich eine Rolle spielt. Genau das war mein erster Fehler: Bild.PNG im Ordner, bild.png im HTML. Unter Windows war das egal. Auf dem Server nicht.

Was ich am Anfang falsch verstanden habe

Drei Missverständnisse, die ich in den ersten Wochen hatte und die vermutlich fast jeder hat.

„Die Seite lädt langsam, weil mein Code schlecht ist." Meistens nicht. Meine erste Seite hatte ein Hintergrundbild von 4 Megabyte, das ich direkt aus einer Kamera-Datei genommen hatte. Der Code war irrelevant, das Bild war das ganze Problem. Ich habe seitdem einen Reflex: Bei einer langsamen Seite zuerst nachsehen, was übertragen wird, und erst danach über Code nachdenken.

„Was im Browser funktioniert, funktioniert überall." Meine Seite sah auf meinem Bildschirm gut aus und auf einem Handy furchtbar. Nicht, weil ich etwas falsch gemacht hätte, sondern weil ich nie hingesehen hatte. Die Ansicht mit schmalem Fenster ist zwei Tastendrücke entfernt und ändert die Sicht auf das eigene Werk erheblich.

„Ich brauche JavaScript dafür." Für einen aufklappbaren Bereich, für ein Menü, für eine Anzeige — für vieles davon gibt es inzwischen HTML- und CSS-Mittel, die weniger können und dafür immer funktionieren.

Warum diese Seite trotzdem wichtig war

Sie hatte einen Vorteil, den ich erst später zu schätzen wusste: Ich konnte alles daran verstehen.

Eine Datei, ein Stylesheet, dreißig Zeilen Skript. Es gab nichts, was ich nicht gelesen hätte. Wenn etwas nicht funktionierte, war die Ursache irgendwo in diesen paar hundert Zeilen.

Das ist ein Zustand, den man in gewachsenen Projekten nie wieder hat. Und es ist der Grund, warum ich Anfängern zu diesem Weg rate: Nicht, weil moderne Werkzeuge schlecht wären, sondern weil ein System, dessen Teile man alle kennt, die beste Lernumgebung ist, die es gibt. Man findet Fehler, indem man nachdenkt, statt indem man sucht — und beim Nachdenken lernt man mehr.

Was ich davon behalten habe

Diese Seite existiert längst nicht mehr, und das ist auch besser so — sie hatte einen Farbverlauf im Hintergrund, den ich heute niemandem zeigen möchte. Was geblieben ist:

Struktur zuerst, Aussehen danach. Wenn das HTML ohne CSS sinnvoll ist, ist die Seite mit CSS meistens auch gut.
Jeder Aufruf nach außen kann scheitern. Was passiert, während er läuft, und was passiert, wenn er fehlschlägt, sind zwei Zustände, die man bauen muss — nicht einer.
Der Browser sagt dir, was los ist. Man muss ihn nur fragen.

Ein paar Jahre später habe ich meine Portfolioseite mit einem ausgewachsenen Framework gebaut, mit Serverkomponenten, Datenbank und allem. Das Erste, was ich dort getan habe, als etwas nicht ging: F12 drücken und in den Netzwerkreiter schauen. Manche Werkzeuge lernt man einmal und benutzt sie für immer.