Es beginnt meistens mit einem kleinen Problem.

Nicht mit einem großen Drama.
Nicht mit einem brennenden Server.
Nicht mit einem Projekt, das schon beim Start aussieht wie ein Unfallbericht.

Nein.

Es beginnt mit etwas Harmlosen.

Eine kleine Seite.
Ein Formular.
Eine Liste.
Ein Login.
Ein bisschen CSS.
Vielleicht eine Datenbank.
Vielleicht ein paar Karten, ein paar Buttons, ein paar Zeilen JavaScript.

Etwas, das man früher einfach gebaut hätte.

Datei auf.
Code rein.
Speichern.
Testen.
Fluchen.
Korrigieren.
Nochmal testen.
Fertig.

Heute beginnt es oft anders.

Heute fragt dich die moderne Webwelt erst einmal, ob du bereit bist, 400 Pakete zu installieren, damit am Ende ein Button blau wird.

Natürlich nicht irgendein Blau.
Ein modernes Blau.
Ein komponentenbasiertes, reaktives, modularisiertes, baumgeschütteltes Blau mit Buildprozess, Abhängigkeitsbaum und drei Warnungen, die niemand versteht.

Man möchte eine kleine Oberfläche bauen und landet plötzlich in einem Ökosystem, das sich anfühlt, als hätte jemand einen Werkzeugkasten genommen, ihn in einen Betonmischer geworfen und dann gesagt:

„Das ist jetzt Best Practice.“

Und dann sitzt man da.

Mit npm.
Mit node_modules.
Mit package-lock.
Mit Versionen.
Mit Abhängigkeiten.
Mit Abhängigkeiten von Abhängigkeiten.
Mit kleinen Bibliotheken, die kleine Bibliotheken brauchen, die kleine Bibliotheken brauchen, damit am Ende ein Datum formatiert wird.

Und irgendwo dazwischen fragt man sich:

Wollte ich eigentlich programmieren?
Oder adoptiere ich gerade einen digitalen Ameisenstaat?

Das Absurde ist:
Viele dieser Werkzeuge versprechen Vereinfachung.

Sie sagen:
„Du musst das Rad nicht neu erfinden.“

Stimmt.

Aber manchmal möchte ich gar kein Rad neu erfinden.
Manchmal möchte ich einfach nur ein Rad anschrauben, ohne vorher eine globale Lieferkette für Gummi, Metall, Ventile und philosophische Namenskonventionen aufzubauen.

Es ist nicht so, dass Frameworks grundsätzlich böse sind.

Sind sie nicht.

Es gibt Projekte, da machen sie Sinn.
Große Anwendungen. Teams. Skalierung. Wiederverwendbare Komponenten. Komplexe Zustände. Saubere Strukturen.

Alles gut.

Aber irgendwo ist etwas verrutscht.

Aus Werkzeugen wurden Religionen.
Aus Hilfen wurden Voraussetzungen.
Aus „kann man nutzen“ wurde „muss man nutzen, sonst bist du von gestern“.

Und plötzlich fühlt man sich wie der letzte Mensch mit Hammer und Schraubendreher, während nebenan jemand eine Weltraumstation baut, um ein Regal aufzuhängen.

Ich habe nichts gegen moderne Technik.

Ich habe etwas gegen unnötige Abhängigkeit.

Gegen dieses Gefühl, dass einfache Dinge nicht mehr einfach sein dürfen.
Gegen Projekte, die starten, bevor sie überhaupt etwas tun.
Gegen Installationen, die größer sind als die eigentliche Idee.
Gegen Fehlermeldungen, die klingen, als hätte ein Wahrsager mit Burnout sie formuliert.

Und dann kommt dieser schöne Moment:

Man installiert eine Library.

Sie soll etwas können.
Kleinigkeit.
Kein Hexenwerk.

Und dubioserweise ist sie beim nächsten Versuch unvollständiger als vorher.

Irgendeine Funktion ist deprecated.
Irgendein Paket ist unsicher.
Irgendeine Version passt nicht.
Irgendeine Abhängigkeit schreit.
Irgendein Update bricht etwas, das gestern noch funktionierte.

Und man sitzt davor und denkt:

Früher war Software manchmal hässlich.
Aber sie stand wenigstens noch auf eigenen Beinen.

Heute braucht ein einzelner Button offenbar psychologische Betreuung durch 27 Pakete und eine Buildpipeline.

Das ist mein persönlicher Kampf.

Nicht gegen Fortschritt.
Nicht gegen sauberen Code.
Nicht gegen gute Werkzeuge.

Sondern gegen diesen Reflex, alles sofort aufzublähen.

Gegen das 0-8-15-Zusammenklicken.
Gegen Baukastenseiten, die aussehen, als hätte man Individualität aus einem Dropdown gewählt.
Gegen Templates, die schreien: „Ich bin einzigartig“, während fünfzig andere Seiten denselben Heldenbereich, dieselben drei Icons und denselben weichgespülten Call-to-Action verwenden.

„Wir schaffen digitale Erlebnisse.“
„Wir denken neu.“
„Wir sind anders.“

Ja.
Anders wie alle anderen im selben Theme.

Und dann WordPress.

Ach, WordPress.

Dieses System, das gleichzeitig großartig, nützlich, nervig, aufgebläht, praktisch und manchmal ein sehr hübsch lackierter Werkzeugschuppen voller Stolperdrähte ist.

Man kann damit viel machen.
Keine Frage.

Aber man kann sich darin auch verlieren.

Theme hier.
Plugin da.
Pagebuilder dort.
Cookie-Banner.
SEO-Plugin.
Sicherheitsplugin.
Cache-Plugin.
Formularplugin.
Galerieplugin.
Plugin, damit das Plugin vom Plugin nicht weint.

Und am Ende lädt eine Seite drei Sekunden lang, um einen Satz anzuzeigen, den man auch in eine HTML-Datei hätte schreiben können.

Natürlich ist das überspitzt.

Aber nur leicht.

Denn genau das ist der Punkt:
Wir haben uns daran gewöhnt, dass selbst einfache Webseiten klingen müssen wie ein kleines Rechenzentrum.

Dabei kann eine Seite auch leise sein.

Eine HTML-Datei.
Ein bisschen CSS.
Ein paar klare Strukturen.
Vielleicht PHP, wenn es dynamisch werden muss.
Vielleicht JavaScript, wenn es wirklich etwas zu tun gibt.

Nicht als nostalgischer Rückfall.
Nicht aus Trotz.
Nicht, weil früher alles besser war.

Früher war nicht alles besser.

Früher war vieles kaputt, langsam, unsicher, wild zusammengefummelt und manchmal optisch ein Verbrechen mit blinkendem Text.

Aber früher gab es dieses Gefühl, dass man verstand, was man baute.

Man wusste, welche Datei wofür da war.
Man konnte Fehler suchen, ohne erst eine archäologische Grabung im Abhängigkeitsbaum zu starten.
Man konnte etwas öffnen, ändern und begreifen.

Heute ist oft schon der Start eines Projekts eine kleine Verwaltungsreform.

Erst installieren.
Dann konfigurieren.
Dann bauen.
Dann bundlen.
Dann transpilieren.
Dann hoffen.
Dann googeln, warum es nicht geht.
Dann feststellen, dass jemand vor zwei Jahren dieselbe Fehlermeldung hatte und die Antwort lautet: „Nevermind, fixed it.“

Danke, Kevin.

Sehr hilfreich.

Vielleicht bin ich da altmodisch.

Vielleicht auch nicht.

Vielleicht ist es einfach eine Frage von Maß.

Nicht jedes Projekt braucht ein Framework.
Nicht jede Idee braucht einen Baukasten.
Nicht jede Webseite braucht ein Theme mit 800 Optionen.
Nicht jedes Formular braucht ein Plugin.
Nicht jeder Button braucht eine Dependency.

Manchmal braucht es nur jemanden, der versteht, was er tut.

Und genau da liegt für mich der Unterschied.

Zusammenklicken kann funktionieren.
Aber es ersetzt kein Verständnis.

Ein Baukasten kann helfen.
Aber er ersetzt keine Architektur.

Ein Framework kann Struktur geben.
Aber es ersetzt kein Denken.

Und eine Library kann Arbeit sparen.
Aber sie nimmt einem nicht die Verantwortung ab.

Vielleicht stört mich deshalb dieses moderne „Hauptsache schnell online“ so sehr.

Weil dabei oft etwas verloren geht.

Handwerk.
Verständnis.
Reduktion.
Der Blick dafür, ob etwas wirklich gebraucht wird oder nur eingebaut wurde, weil es da war.

Ich liebe kleine Lösungen.

Nicht, weil ich kleine Ansprüche habe.
Sondern weil kleine Lösungen ehrlich sein können.

Ein Login, der tut, was er soll.
Eine Datenbankstruktur, die man erklären kann.
Ein Formular, das nicht erst den halben Browser umarmt.
Eine Seite, die lädt, bevor der Besucher vergessen hat, warum er kam.

Das ist nicht rückständig.

Das ist Respekt.

Respekt vor der Idee.
Respekt vor der Zeit.
Respekt vor dem Menschen, der die Seite nutzt.
Und auch Respekt vor demjenigen, der sie später warten muss.

Denn wer schon einmal ein zusammengeklicktes System geerbt hat, weiß:

Man übernimmt keine Webseite.
Man übernimmt eine Ausgrabungsstätte.

Da liegt irgendwo ein Theme.
Darunter ein Child-Theme.
Daneben ein Plugin, das seit 2019 nicht mehr gepflegt wird.
Im Backend ein Pagebuilder mit 94 verschachtelten Containern.
Im CSS drei Notlösungen.
In der Datenbank Reste von Dingen, die niemand mehr kennt.
Und oben drüber steht: „Kannst du nur kurz was ändern?“

Nur kurz.

Der gefährlichste Satz der IT.

„Nur kurz“ bedeutet meistens:
Bitte öffne diese digitale Mumie, aber weck den Fluch nicht.

Und trotzdem macht man es.
Weil man es kann.
Weil man neugierig ist.
Weil man wissen will, wo es knirscht.
Weil man diesen alten Reflex hat: Ich will verstehen, warum.

Vielleicht ist genau das mein Kern.

Ich will verstehen.

Ich will nicht nur klicken.
Ich will nicht nur installieren.
Ich will nicht nur ein Template austauschen und so tun, als wäre das Entwicklung.

Ich will wissen, was passiert.

Wenn ich HTML schreibe, sehe ich Struktur.
Wenn ich CSS schreibe, sehe ich Gestaltung.
Wenn ich JavaScript schreibe, sehe ich Verhalten.
Wenn ich PHP schreibe, sehe ich Logik.
Wenn ich SQL schreibe, sehe ich Daten.

Das ist für mich keine Nostalgie.

Das ist Klarheit.

Und Klarheit ist selten laut.

Sie braucht keine 27 Badges im Footer.
Keine Animation, die beim Scrollen aus dem Nichts hereinschwebt.
Keinen Baukasten, der einem erklärt, dass man jetzt kreativ ist, weil man Block Nummer 14 nach links gezogen hat.

Klarheit fragt nur:

Was soll es tun?
Für wen ist es da?
Was braucht es wirklich?
Was kann weg?

Vielleicht ist das mein kleiner Widerstand gegen diese aufgeblasene Webwelt.

Nicht alles größer machen.
Nicht alles installieren.
Nicht alles verkleiden.

Manchmal reicht es, eine Sache sauber zu bauen.

Nicht perfekt.
Nicht trendig.
Nicht hip.

Sauber.

Und vielleicht klingt das altmodisch.

Aber wenn am Ende eine Seite schnell lädt, verständlich bleibt, wartbar ist und nicht bei jedem Update wie ein Kartenhaus im Wind steht, dann kann ich mit altmodisch ziemlich gut leben.

Denn Fortschritt bedeutet für mich nicht, möglichst viel dazwischenzuschalten.

Fortschritt bedeutet, dass etwas besser wird.

Nicht schwerer.
Nicht abhängiger.
Nicht undurchsichtiger.

Besser.

Und manchmal ist besser eben nicht das nächste Framework.

Manchmal ist besser einfach eine Datei, die man versteht.