Warum ich Websites wieder selbst baue

Websites selbst zu bauen klingt zunächst nach einem Schritt zurück.

Schließlich gibt es heute für beinahe alles eine fertige Lösung. Pagebuilder, Komponenten, Frameworks und Erweiterungen versprechen, Entwicklungszeit zu verkürzen und komplexe Layouts ohne großen technischen Aufwand möglich zu machen.

Und genau darin liegt durchaus ein Vorteil.

Auch ich habe über Jahre mit solchen Werkzeugen gearbeitet. Sie ermöglichten schnelle Ergebnisse, flexible Layouts und eine komfortable Bearbeitung. Vieles, was sonst individuell entwickelt werden musste, ließ sich plötzlich über eine Oberfläche konfigurieren.

Mit der Zeit hat sich meine Perspektive darauf jedoch verändert.

Heute interessiert mich nicht mehr nur, wie schnell sich eine Website bauen lässt. Mich interessiert stärker, was danach mit ihr passiert.

Komfort erzeugt Abhängigkeiten

Jede zusätzliche Erweiterung löst zunächst ein Problem.

Gleichzeitig entsteht aber eine neue Abhängigkeit.

Eine Komponente benötigt Updates. Sie muss mit dem verwendeten CMS kompatibel bleiben. Sie kann andere Erweiterungen voraussetzen. Sie bringt eigenen JavaScript- und CSS-Code mit. Und möglicherweise entscheidet irgendwann ein Hersteller darüber, ob sie weiterentwickelt wird.

Bei einzelnen Erweiterungen ist das vollkommen normal und häufig sinnvoll.

Problematisch wird es für mich dort, wo die eigentliche Website nur noch innerhalb eines immer komplexeren Geflechts aus zusätzlichen Systemen funktioniert.

Dann wird aus Komfort schnell Abhängigkeit.

Eine Änderung an einem vermeintlich einfachen Detail kann plötzlich Auswirkungen an mehreren Stellen haben. Ein Update verändert Verhalten. Ein Plugin benötigt ein anderes Plugin. Und ein Layout, das visuell übersichtlich erscheint, besteht technisch aus einer Vielzahl ineinander verschachtelter Ebenen.

Irgendwann stellte sich für mich deshalb eine einfache Frage:

Wenn ich ohnehin verstehen muss, wie all diese Systeme miteinander funktionieren – warum baue ich dann nicht wieder mehr davon selbst?

Kontrolle bedeutet nicht, alles neu zu erfinden

Eine Website selbst zu entwickeln bedeutet für mich nicht, jede technische Grundlage neu zu programmieren.

Ich nutze weiterhin ein Content-Management-System. Ich verwende Standards. Ich arbeite mit vorhandenen Schnittstellen und Funktionen.

Der Unterschied liegt an einer anderen Stelle.

Ich möchte möglichst genau wissen, welche Bestandteile eine Website benötigt und warum sie vorhanden sind.

Ein Template enthält die Struktur, die tatsächlich gebraucht wird. CSS beschreibt die Gestaltung. JavaScript kommt nur dort zum Einsatz, wo eine Interaktion es erfordert. Zusätzliche Erweiterungen werden nicht grundsätzlich vermieden – aber sie müssen einen nachvollziehbaren Zweck erfüllen.

Dadurch entsteht kein komplett unabhängiges System.

Aber eines, dessen Abhängigkeiten überschaubar bleiben.

Weniger Ebenen bedeuten mehr Klarheit

Diese Reduktion wirkt sich unmittelbar auf meine Arbeit aus.

Wenn ich eine Überschrift verändern möchte, muss ich nicht erst herausfinden, welche Einstellung eines Pagebuilders sie erzeugt. Wenn ein Abstand nicht stimmt, kann ich nachvollziehen, an welcher Stelle er definiert wird. Wenn sich die mobile Navigation anders verhalten soll, arbeite ich direkt mit der dafür verantwortlichen Struktur.

Gestaltung und technische Umsetzung liegen dadurch näher beieinander.

Das ist für mich besonders wichtig, weil viele gestalterische Entscheidungen erst während der tatsächlichen Umsetzung präzise werden.

Ein Layout ist nicht nur eine statische Komposition. Es verändert sich auf unterschiedlichen Bildschirmgrößen. Texte werden länger oder kürzer. Navigation muss reagieren. Abstände verändern ihre Wirkung.

Wenn Gestaltung und technische Struktur getrennt voneinander entstehen, muss eine Seite häufig gegen ihr eigenes System gestaltet werden.

Wenn beide gemeinsam entwickelt werden, kann sich das System stattdessen aus der Gestaltung ergeben.

Sicherheit verändert den Blick auf Komplexität

Ein weiterer Punkt hat diese Entwicklung deutlich beschleunigt: Sicherheit.

Jede öffentlich erreichbare Website ist ein technisches System und damit auch potenzielles Angriffsziel. Absolute Sicherheit gibt es nicht. Aber die Angriffsfläche lässt sich beeinflussen.

Je mehr Erweiterungen, Komponenten und zusätzliche Ebenen ein System enthält, desto mehr Bestandteile müssen dauerhaft beobachtet, aktualisiert und verstanden werden.

Dabei reicht es nicht, dass eine Website heute funktioniert.

Entscheidend ist auch, ob sie in zwei oder fünf Jahren noch zuverlässig gepflegt werden kann.

Erfahrungen mit kompromittierten Websites haben diesen Aspekt für mich sehr konkret gemacht. Sicherheitsprobleme sind dann keine theoretischen Risiken mehr. Man sieht unmittelbar, was passiert, wenn eine einzelne Schwachstelle Auswirkungen auf ein vollständiges System bekommt.

Daraus entstand bei mir kein Anspruch auf maximale technische Abschottung. Wohl aber der Wunsch nach nachvollziehbaren Strukturen.

Was nicht benötigt wird, muss auch nicht installiert, aktualisiert und abgesichert werden.

Für mich ist technische Reduktion heute keine Einschränkung. Sie ist eine Form von Kontrolle.

Das CMS bleibt – der Ballast geht

Ich habe mich deshalb nicht vom Content-Management-System verabschiedet.

Im Gegenteil.

Ein gutes CMS übernimmt viele Aufgaben, die sinnvollerweise nicht jedes Mal neu entwickelt werden sollten: Benutzerverwaltung, Beiträge, Kategorien, Menüstrukturen, Medienverwaltung, Rechte, Routing und zahlreiche weitere Grundlagen.

Für mich liegt die Stärke heute darin, diese vorhandene Basis wieder stärker zu nutzen.

Statt innerhalb des CMS noch eine zweite vollständige Gestaltungsebene aufzubauen, entsteht das Frontend direkt im Template. Inhalte bleiben Inhalte. Struktur bleibt Struktur. Gestaltung wird dort definiert, wo sie hingehört.

Dadurch wird auch das Backend ruhiger.

Ein Beitrag muss nicht wissen, wie ein bestimmtes Element auf jedem Bildschirm dargestellt werden soll. Er enthält vor allem seine Inhalte. Das Template übernimmt die visuelle Interpretation.

Diese Trennung empfinde ich inzwischen als wesentlich sauberer.

Individuell bedeutet nicht kompliziert

Individuelle Entwicklung wird häufig mit zusätzlicher Komplexität verbunden.

Für mich kann genau das Gegenteil der Fall sein.

Ein universeller Pagebuilder muss möglichst viele Anwendungsfälle abdecken. Er benötigt deshalb Funktionen, Optionen und Strukturen, die eine konkrete Website möglicherweise niemals verwendet.

Ein individuelles Template muss dagegen nur eine einzige Website verstehen.

Es kennt deren Navigation. Ihre Seitentypen. Ihre Typografie. Ihre wiederkehrenden Komponenten. Ihre Breakpoints und ihre gestalterischen Regeln.

Diese Spezialisierung ermöglicht Reduktion.

Nicht jede theoretisch denkbare Variante muss vorgesehen werden. Nur diejenigen, die für das konkrete Projekt sinnvoll sind.

Für mich ist das ein wesentlicher Unterschied zwischen einem System, das möglichst alles können möchte, und einem System, das eine bestimmte Aufgabe möglichst gut erfüllen soll.

Es dauert nicht immer länger

Natürlich kostet individuelle Entwicklung Zeit.

Besonders am Anfang eines Projekts.

Strukturen müssen angelegt, Komponenten entwickelt und responsive Verhalten durchdacht werden. Ein fertiges Werkzeug kann an dieser Stelle schneller sein.

Aber Entwicklungszeit endet nicht mit dem ersten sichtbaren Ergebnis.

Auch spätere Anpassungen, Fehlersuche, Updates und Wartung gehören zur tatsächlichen Lebensdauer einer Website.

Genau dort relativiert sich der vermeintliche Zeitvorteil häufig.

Wenn ich nach Monaten eine Website öffne und unmittelbar nachvollziehen kann, wie ein Bereich aufgebaut ist, spare ich Zeit. Wenn Änderungen keine unerwarteten Abhängigkeiten auslösen, spare ich Zeit. Wenn ein Update nicht mehrere zusätzliche Systeme gleichzeitig betrifft, ebenfalls.

Deshalb betrachte ich Entwicklungsaufwand heute weniger als Momentaufnahme und stärker über den gesamten Lebenszyklus eines Projekts.

Warum ich also wieder selbst baue

Weil ich Websites verstehen möchte.

Nicht nur ihre sichtbare Oberfläche, sondern das System darunter.

Ich möchte wissen, wo eine Funktion herkommt. Welche Abhängigkeiten bestehen. Welche Dateien für eine Darstellung verantwortlich sind. Und welche Bestandteile tatsächlich notwendig sind.

Das bedeutet nicht, grundsätzlich auf fertige Lösungen zu verzichten.

Es bedeutet vielmehr, sie bewusster auszuwählen.

Heute beginnt ein Projekt für mich deshalb häufiger mit einem möglichst schlanken technischen Fundament. Darauf entsteht Schritt für Schritt genau das, was die jeweilige Website benötigt – und möglichst wenig darüber hinaus.

Dadurch habe ich wieder mehr unmittelbaren Einfluss auf Gestaltung, Performance, Wartbarkeit und Sicherheit.

Vor allem aber entsteht eine Website, deren Aufbau ich auch später noch nachvollziehen kann.

Für mich ist das kein Rückschritt.

Es ist die Rückkehr zu einer Arbeitsweise, bei der ich wieder genau weiß, was ich baue und warum es dort ist.