philosophy

Diese Seite beschreibt Entscheidungen, nicht einen Technologie-Kult

Grundhaltung – Technik soll ruhig, lesbar und dauerhaft bleiben

Ich halte wenig davon, Webseiten unnötig größer oder komplizierter zu machen, nur weil es technisch möglich ist. Vieles, was heute als fortschrittlich verkauft wird, ist in Wahrheit oft nur schwerer, unübersichtlicher und schneller veraltet. Mich interessiert an Webentwicklung nicht, wie man möglichst viel Technik unterbringt, sondern wie man mit möglichst wenig unnötiger Technik eine stabile und ehrliche Lösung baut.

Diese Haltung hat viel mit der Rechnergeschichte davor zu tun. Wer mit Systemen gearbeitet hat, bei denen Speicher, Datenträger und Stabilität reale Grenzen waren, entwickelt fast automatisch eine andere Disziplin. Man überlegt früher, was wirklich nötig ist. Man trennt eher Wichtiges von Schmuck. Man lernt, dass Klarheit nicht altmodisch ist, sondern meist die robustere Lösung.

Für mich ist guter Code deshalb keine Ansammlung cleverer Einfälle, sondern eher eine saubere Ordnung. Wenn ich eine Datei Monate oder Jahre später wieder öffne, sollte sie mir nicht wie ein Fremdkörper vorkommen. Sie sollte lesbar sein, ruhig gebaut und in sich logisch bleiben. Genau das ist für mich technische Qualität.

„Guter Code erklärt sich nicht durch Lautstärke, sondern durch innere Ordnung.“

Einfachheit ist nicht dasselbe wie Simplismus

Eine technische Lösung ist nicht automatisch gut, nur weil sie kurz ist. Gute Einfachheit entsteht, wenn eine Lösung die tatsächliche Aufgabe vollständig erfüllt und dabei möglichst wenig unnötige Komplexität einführt.

Manchmal braucht eine Aufgabe JavaScript, serverseitige Logik, Datenhaltung oder externe Dienste. Dann ist zusätzliche Technik gerechtfertigt. Die Philosophie besteht nicht darin, Komplexität grundsätzlich zu verbieten, sondern sie sichtbar und begründbar zu halten.

„So einfach wie möglich – aber nicht einfacher als die Aufgabe.“

Warum HTML von Hand

Handgeschriebenes HTML ist für mich keine Romantik und auch kein Selbstzweck. Es ist einfach die direkteste und kontrollierbarste Form, eine Seite zu bauen. Ich sehe sofort, was wirklich auf der Seite steht, wie Inhalte gegliedert sind und was später von Suchmaschinen, Browsern und Menschen tatsächlich gelesen wird. Es gibt keine unnötige Zwischenebene, die alles verkompliziert.

Gerade bei kleineren und mittleren Webauftritten ist diese Direktheit ein Vorteil. Statt Strukturen erst aus einem System herauszuverhandeln, kann man sie direkt, sauber und eindeutig schreiben. Überschriften, Absätze, Listen, Navigation, Bilder, semantische Bereiche – das alles lässt sich schlicht und klar aufbauen, ohne dass ein schweres Umfeld nötig wäre.

Das bedeutet nicht, dass alles immer ultraminimal sein muss. Es bedeutet nur, dass jede zusätzliche Schicht begründet sein sollte. Wenn eine Datei mit der Zeit wächst, ist das in Ordnung, solange sie noch eine erkennbare Ordnung hat. Unordnung entsteht nicht durch Länge, sondern durch fehlende Struktur.

HTML ist Struktur und Bedeutung, nicht nur ein Träger für CSS

Der WHATWG HTML Living Standard beschreibt HTML als Sprache mit definierten Elementen, Semantik, Struktur und APIs. Für meine praktische Haltung bedeutet das: Überschriften, Navigation, Abschnitte, Listen, Links, Tabellen und Formulare werden nach ihrer Aufgabe gewählt – nicht nur danach, welche Box sich am leichtesten gestalten lässt.

Semantik hilft dabei mehreren Ebenen gleichzeitig: Menschen, Browsern, Assistenztechnik, Suchsystemen und später auch mir selbst, wenn ich eine Datei wieder öffne.

Handgeschrieben bedeutet nicht ungeprüft

Direkter Code profitiert besonders von maschineller Prüfung: HTML-Conformance, JSON-LD-Parsing, JavaScript-Syntax, interne Links, doppelte IDs und fehlende Sprungziele lassen sich automatisiert prüfen.

Der HTML-Standard selbst unterscheidet zwischen Fehlern, die maschinell geprüft werden können, und solchen, die menschliche Beurteilung brauchen. Ein Validator ersetzt deshalb kein Review, aber er verhindert, dass triviale Strukturfehler unnötig menschliche Aufmerksamkeit binden.

Struktur und CSS – Gestaltung soll führen, nicht überdecken

CSS ist für mich kein Ort für Effekthascherei. Natürlich darf eine Seite gestalterisch sauber und stimmig aussehen. Aber Gestaltung soll Inhalte tragen und Orientierung geben, nicht von beidem ablenken. Ich bevorzuge deshalb ruhige Layouts, klare Abstände, nachvollziehbare Farben und eine Schriftwahl, die auch bei längeren Texten nicht ermüdet.

Gerade bei Informationsseiten ist das wichtig. Wenn jede Box, jede Zeile und jeder Bereich Aufmerksamkeit schreit, verliert der eigentliche Inhalt an Gewicht. Gute Gestaltung ist oft eher die Kunst, Unruhe zu vermeiden. Farben, Linien, Rahmen, Hervorhebungen und Abstände sollen nicht dekorativ um ihrer selbst willen sein, sondern logisch.

„Gestaltung soll Inhalte lesbarer machen, nicht lauter.“

Wiederkehrende Muster sind ein kleines Designsystem – auch ohne Framework

Konsistente Abstände, Boxen, Navigationsmuster, Fokuszustände und Typografie erzeugen eine gemeinsame Sprache. Dafür ist nicht automatisch ein großes Komponenten-Framework nötig.

Ein kleiner Satz bewusst gepflegter Klassen kann für eine überschaubare statische Website dieselbe Aufgabe erfüllen: Wiederverwendung, Konsistenz und geringere Fehlerwahrscheinlichkeit.

JavaScript nur dort, wo es wirklich etwas verbessert

Ich habe nichts gegen JavaScript. Ich habe nur etwas gegen JavaScript an Stellen, an denen es nur deshalb eingesetzt wird, weil man sich daran gewöhnt hat, alles damit zu lösen. Viele Webseiten benutzen Skripte nicht als Werkzeug, sondern als Standardreflex. Genau das halte ich oft für einen Fehler.

JavaScript ist für mich dann sinnvoll, wenn es Bedienung verbessert, Barrieren reduziert oder kleine dynamische Aufgaben übernimmt, die ohne Skript unnötig umständlich wären. Ein To-top-Button, eine saubere Lightbox, ein sinnvoller Datumsstempel oder eine gezielte Kartenlogik – das sind für mich vernünftige Einsatzbereiche. Alles andere muss sich erst rechtfertigen.

Gerade statische Seiten profitieren davon. Was nicht dynamisch sein muss, erzeugt keine unnötige Komplexität. Und was nicht unnötig komplex ist, bleibt meist länger wartbar und sicherer. Für mich ist das keine Ideologie, sondern praktische Erfahrung.

Die Grundfunktion zuerst, Komfort darüber

Für Informationsseiten ist ein einfacher Grundsatz besonders robust: Der eigentliche Inhalt, die Links und die Navigation sollten bereits in der HTML-Struktur vorhanden sein. CSS verbessert die Darstellung; JavaScript ergänzt Verhalten.

Das heißt nicht, dass jede moderne Anwendung ohne JavaScript vollständig funktionieren muss. Es heißt, dass eine Funktion nicht unnötig von einer komplexeren Schicht abhängig gemacht wird, wenn die Kernaufgabe auch darunter sinnvoll bestehen kann.

Robuste Seiten planen auch den Ausfall einer Komfortschicht mit ein

SEO und Inhalt – lieber saubere Struktur als leere Tricks

Suchmaschinenoptimierung beginnt für mich nicht bei Tricks, sondern bei Ordnung. Ein sauberer Seitentitel, eine nachvollziehbare Gliederung, ehrliche Beschreibungen, klare interne Verlinkung und stimmige Inhalte sind für mich die eigentliche Grundlage. Vieles, was als SEO-Maßnahme verkauft wird, ist in Wahrheit bloß kurzfristiger Lärm.

SEO ist wichtig. Aber es steht für mich nicht über dem Besucher. Eine gute Platzierung nützt wenig, wenn jemand danach auf einer unklaren, veralteten oder enttäuschenden Seite landet. Sichtbarkeit ist hilfreich, Vertrauen, Orientierung und ehrliche Information sind wichtiger.

Ich versuche deshalb, Seiten so zu schreiben, dass sie zuerst für Menschen verständlich sind. Wenn eine Seite logisch gegliedert ist, echte Information enthält und nicht unnötig um den Punkt herumredet, ist das meist auch technisch die bessere Grundlage. Schlechte Inhalte werden durch Metadaten nicht gut. Gute Inhalte werden durch saubere Struktur auffindbarer.

Dazu gehört auch, dass ich auf künstliche Überoptimierung wenig gebe. Es bringt nichts, Texte mit immer denselben Begriffen zu überladen, wenn sie dadurch schlechter lesbar werden. Gute SEO ist für mich eher eine Form technischer und sprachlicher Disziplin.

„Eine Seite sollte nicht für Suchmaschinen klingen, sondern für Menschen. Saubere Technik hilft beiden – aber der Besucher kommt zuerst.“

Menschen-zuerst ist keine Gegenposition zu sauberem SEO

Google beschreibt SEO selbst als Hilfe für Suchmaschinen, Inhalte zu verstehen, und für Nutzer, diese Inhalte zu finden. Gleichzeitig empfiehlt Google ausdrücklich hilfreiche, verlässliche und „people-first“ Inhalte statt Texte, die primär zur Manipulation von Rankings erzeugt werden.

Das passt zu meiner Haltung: Eine gute Seite darf technisch suchfreundlich sein, ohne sprachlich wie eine Suchmaschine zu klingen. Titel, interne Verlinkung, strukturierte Daten und klare Gliederung unterstützen echte Information – sie ersetzen sie nicht.

Bedienbarkeit – Technik muss nicht nur geladen, sondern auch benutzt werden können

Bedienbarkeit ist für mich kein Zusatz und keine späte Nacharbeit. Sie gehört von Anfang an in die Struktur hinein. Eine Seite, die optisch ordentlich wirkt, aber mit Tastatur, Fokus, Bewegung oder Lesbarkeit schlecht umgeht, ist technisch nicht fertig. Sie ist nur oberflächlich fertig.

Deshalb achte ich auf klare Überschriften, verständliche Fokuszustände, gut lesbare Kontraste, sinnvolle Linktexte, verlässliche Navigation und reduzierbare Bewegung. Gerade kleine Details machen hier viel aus. Eine Seite muss nicht als Spezialprojekt für Barrierefreiheit gebaut sein, um respektvoll und brauchbar zu sein. Aber sie sollte niemanden unnötig ausschließen.

Auch hier gilt mein übliches Prinzip: nicht aufblasen, sondern sauber bauen. Gute Zugänglichkeit entsteht oft nicht durch immer mehr Technik, sondern durch saubere Semantik, klare Logik und die Bereitschaft, auf unnötige Spielereien zu verzichten.

WCAG 2.2 ist ein Prüfrahmen – Bedienbarkeit bleibt praktische Arbeit

WCAG 2.2 ist seit dem 5. Oktober 2023 eine W3C Recommendation und ergänzt unter anderem Anforderungen rund um sichtbaren Fokus, Zielgrößen, Dragging, konsistente Hilfe und zugängliche Authentisierung.

Für meine Seiten bedeutet das nicht, jeden Standardtext in die Oberfläche zu übertragen. Es bedeutet, die eigene Bedienbarkeit an überprüfbaren Kriterien zu messen: Tastatur, Fokus, Kontrast, Bewegungsreduktion, verständliche Namen und robuste Semantik.

Sicherheit und technische Disziplin

Sicherheit beginnt für mich nicht bei dramatischen Maßnahmen, sondern bei Disziplin. Weniger unnötige Abhängigkeiten, weniger bewegliche Teile, weniger fremde Einbindungen und weniger überflüssige Dynamik bedeuten oft automatisch eine kleinere Angriffsfläche. Nicht alles, was modern oder bequem wirkt, ist auch vernünftig.

Deshalb bevorzuge ich bei vielen Seiten statische Lösungen, wenige externe Abhängigkeiten und eine Architektur, die nicht bei jeder Kleinigkeit zusätzliche Risiken einführt. Sicherheit ist für mich nicht nur ein Header-Set oder eine Checkliste, sondern auch eine Frage der Zurückhaltung.

Gerade auf kleinen und mittleren Seiten ist das wichtiger, als viele glauben. Eine übersichtliche technische Basis ist nicht nur leichter zu pflegen, sondern meist auch schwerer kaputtzumachen.

Jede Abhängigkeit ist Nutzen und Verpflichtung zugleich

Eine Bibliothek, ein Framework, ein CDN oder ein SaaS-Dienst kann viel Arbeit sparen. Gleichzeitig entstehen Updatepflichten, Ausfallmöglichkeiten, API-Änderungen und gegebenenfalls neue Datenschutz- oder Sicherheitsfragen.

Deshalb frage ich bei einer neuen Abhängigkeit nicht nur: „Was kann sie?“, sondern auch: „Was muss ich ab jetzt dauerhaft mittragen?“

Datensparsamkeit kann auch Architektur sein

Was eine Seite nicht erhebt, muss sie nicht speichern, schützen, auswerten oder später erklären. Für rein informative Seiten ist deshalb eine statische Architektur ohne unnötige Tracker, Konten oder Fremdeinbindungen nicht nur einfach, sondern oft auch datenschutzfreundlicher.

Das ist keine Behauptung, dass jede externe Technik datenschutzwidrig wäre. Es ist die bewusstere Frage, ob eine zusätzliche Datenspur für die tatsächliche Aufgabe überhaupt notwendig ist.

Pflege über Jahre – der eigentliche Test guter Arbeit

Viele Webseiten sehen am Anfang ordentlich aus. Die eigentliche Qualität zeigt sich aber später. Nach Monaten. Nach Jahren. Nach vielen kleinen Änderungen, Ergänzungen, Korrekturen und neuen Seiten. Erst dann merkt man, ob die Grundstruktur trägt oder ob alles mit jeder Änderung schwerer und unübersichtlicher wird.

Genau deshalb denke ich bei Code fast immer in längeren Zeiträumen. Kann ich später dieselben Muster wiederverwenden? Bleibt die Datei nachvollziehbar? Ist ein Bereich sauber getrennt? Sind Klassen und Blöcke konsistent genug, dass sie nicht jedes Mal neu erfunden werden müssen? Für mich ist das keine Nebensache, sondern der Kern professioneller Ruhe.

„Der wahre Test von Code ist nicht der erste Eindruck, sondern die dritte Überarbeitung nach mehreren Jahren.“

Ruhige Pflege verändert lieber nachvollziehbar als spektakulär

Wartbarkeit entsteht auch außerhalb des eigentlichen Codes

Dateinamen, Ordnerlogik, Standards, Änderungsnotizen und klare Zuständigkeiten sind Teil der technischen Qualität. Eine gute Datei kann trotzdem schwer pflegbar werden, wenn niemand mehr weiß, welche Fassung maßgeblich ist oder warum eine bestimmte Ausnahme existiert.

Dokumentation muss nicht aus dicken Handbüchern bestehen. Oft reichen wenige präzise Regeln, wenn sie tatsächlich aktuell und verlässlich sind.

Heutige Werkzeuge – KI und Cloud nur nach praktischer Prüfung

Dass ich ruhige, handgeschriebene Seiten bevorzuge, bedeutet nicht, dass ich neue Werkzeuge grundsätzlich ablehne. Es bedeutet nur, dass ich ihnen nicht automatisch glaube. Auch heutige Werkzeuge wie KI-Modelle und Cloud-Dienste interessieren mich – aber nicht als Mode und nicht als Ersatz für Urteil. Mich interessiert, was sie im realen Alltag tatsächlich tragen.

Genau deshalb prüfe ich solche Werkzeuge nüchtern. Nicht nach Werbeton, nicht nach Aufregung und nicht nach bloßem Neuheitswert, sondern nach einer einfachen Frage: Hilft dieses Werkzeug wirklich weiter, oder erzeugt es nur zusätzlichen Ballast? Viele Dinge wirken auf den ersten Blick beeindruckend. Entscheidend ist aber, ob sie auch nach dem dritten, fünften oder zehnten Einsatz noch verlässlich sind.

Für mich sind KI-Modelle deshalb keine Autorität und auch keine Spielerei. Sie sind Werkzeuge. Manche helfen beim Ordnen, Vergleichen, Formulieren oder schnellen Gegenprüfen. Andere erzeugen eher Scheinpräzision, unnötige Länge oder neue Abhängigkeiten. Dasselbe gilt für Cloud-Dienste. Sie können nützlich sein, aber nur dann, wenn ihr praktischer Nutzen größer bleibt als der Aufwand, die Unruhe oder die neue technische Abhängigkeit.

Die eigentliche Haltung bleibt dabei dieselbe wie früher: Werkzeuge müssen sich bewähren. Nicht auf Folien, nicht in Werbesätzen, sondern im echten Gebrauch. Alles andere ist für mich nur zusätzlicher Name ohne belastbare Substanz.

„Neue Werkzeuge interessieren mich nur dann, wenn sie im Alltag wirklich tragen – nicht wenn sie bloß modern klingen.“

KI kann Arbeit beschleunigen – Verantwortung bleibt beim Menschen

KI kann beim Vergleichen, Formulieren, Strukturieren, Übersetzen, Prüfen oder beim Entwurf technischer Varianten nützlich sein. Ihre Ausgabe wird dadurch aber nicht automatisch richtig.

Besonders bei Code, Recht, Sicherheit und technischen Details gilt: Ergebnis gegen Quelle, Bestand und reale Umgebung prüfen. Eine plausible Formulierung ist kein Beweis.

Für mich ist KI deshalb am stärksten als Gegenleser, Werkzeug und Beschleuniger – nicht als unsichtbarer Ersatz für Urteil, Verantwortlichkeit oder eigene Kenntnis des Systems.

Cloud-Nutzen wird gegen Abhängigkeit und Portabilität abgewogen

Ein Cloud-Dienst kann Verfügbarkeit, Zusammenarbeit oder Komfort verbessern. Gleichzeitig hängt ein Teil der Arbeit dann von Anbieter, Konto, Preis, API und Exportmöglichkeiten ab.

Deshalb gehört zur Bewertung die Ausstiegsfrage: Lassen sich Daten vollständig exportieren? Bleiben offene Formate? Gibt es einen lokalen oder alternativen Workflow? Wie schwer wäre ein späterer Wechsel?

Automatisieren, was wiederholbar ist – sichtbar lassen, was schiefgehen kann

Automatisierung ist dann gut, wenn sie reproduzierbare Arbeit zuverlässig übernimmt und Fehlerzustände sichtbar macht. Sie ist schlecht, wenn niemand mehr versteht, was sie verändert.

Gerade bei Build-, Upload-, Backup- oder Übersetzungsabläufen sollten Eingaben, Ausgaben und Rückweg dokumentiert bleiben.

Was ich eher meide

Ich meide nicht Technik an sich. Ich meide vor allem Technik, die ihren eigenen Aufwand nicht rechtfertigt. Dazu gehören für mich aufgeblähte Strukturen, unnötige Framework-Last, Effekte ohne echten Nutzen, überladene Oberflächen, austauschbare Standardlösungen ohne Handschrift und Konstruktionen, die sich nur schwer wieder lesen lassen.

• unnötig schwere Frontend-Konstruktionen für einfache Seiten
• JavaScript als Standardreaktion statt als bewusstes Werkzeug
• optische Unruhe, die Lesbarkeit und Orientierung schwächt
• SEO-Tricks ohne inhaltliche Substanz
• Strukturen, die beim späteren Pflegen mehr Schaden als Nutzen bringen
• Technik, die beeindruckend aussehen soll, aber im Alltag unnötig bremst

Das heißt nicht, dass ich grundsätzlich gegen moderne Werkzeuge bin. Es heißt nur, dass ich von Technik erwarte, ihren Platz zu verdienen. Ein Werkzeug ist gut, wenn es ein Problem ruhiger löst – nicht wenn es nur zusätzlichen Namen, zusätzlichen Ballast und zusätzlichen Wartungsaufwand einführt.

Die Philosophie ist eine Prüffrage, kein Dogma

Ich lehne ein Framework nicht ab, weil es ein Framework ist. Ich lehne eine Cloud nicht ab, weil sie eine Cloud ist. Ich lehne JavaScript nicht ab, weil es JavaScript ist.

Die eigentliche Frage ist immer dieselbe: Wird die Lösung dadurch nachvollziehbar besser – oder nur größer, abhängiger und schwerer zu pflegen?

Der langfristige Maßstab

„Technik verdient ihren Platz nicht durch Neuheit, sondern dadurch, dass sie ihre Aufgabe dauerhaft trägt.“

Technische Referenzen

Die externen Quellen dienen der technischen Einordnung einzelner Standards und Empfehlungen. Die eigentliche Haltung dieser Seite bleibt persönliche Erfahrungsdokumentation und wird nicht als allgemeingültige Pflichtarchitektur für jede Website ausgegeben.

Querverweise im SSLXY-Archiv

• Zur SSLXY-Hauptseite
• Webmaster
• Webentwicklung seit 1996
• Server-Härtung
• Software- und Tool-Alltag
• KI-Werkzeuge
• Repair Attitude
• The Vault