+33-9-7266-3068
contact@gdm-pixel.fr
TL;DR
1984: Der erste Klick hat alles verändert
Vierzig Jahre. So lange bleibt die Frage unbeantwortet.
1984 stellte Apple den Macintosh mit einem einfachen Versprechen vor: Was Sie auf dem Bildschirm sehen, erhalten Sie auf Papier. Das WYSIWYG-Paradigma — What You See Is What You Get — war geboren. Wenige Jahre später eroberte es die Web-Erstellung. Dreamweaver, FrontPage, dann WordPress, Wix, Webflow… Das Versprechen hat sich nie geändert: Erstellen ohne zu programmieren.
Vierzig Jahre später ist die Debatte noch immer nicht entschieden. Und dennoch hat sich in den Workshops und Webagenturen 2024 etwas grundlegend verändert.
Hier ist, was wir tatsächlich in der Praxis sehen — und warum die eigentliche Frage nicht mehr “Code oder visuelle Oberfläche” lautet, sondern “welches für welchen Zweck, in welchem Projektmoment”.
Die Geschichte eines falschen Duells
Stellen Sie einem Webentwickler aus den 2000ern die Frage: Dreamweaver oder Notepad? Sie erhalten eine klare Antwort, oft leidenschaftlich, manchmal verächtlich.
“Reine” Entwickler betrachteten visuelle Tools als Spaghetti-Code-Generatoren. Designer liebten sie, weil sie kein CSS lernen mussten. Die beiden Lager haben sich lange ignoriert — oder bekämpft.
Was man dabei vergisst: Dieses Duell war schon immer künstlich.
Ein WYSIWYG-Tool hat nie beansprucht, einen Senior-Entwickler bei einer komplexen Anwendung zu ersetzen. Und ein Entwickler, der alles von Hand schreibt, war nie die ideale Lösung für ein kleines Unternehmen, das seine “Unsere Leistungen”-Seite einfach einmal im Monat aktualisieren möchte — eine Abwägung, die wir bereits ausführlich zu visuellen Buildern unter WordPress beschrieben haben.
Das Problem: Lange wurden beide Ansätze als gegenseitig ausschließend dargestellt. Entweder Sie programmieren, oder Sie nutzen einen visuellen Builder. Entweder Sie sind professionell, oder Sie machen Wix.
Diese binäre Sichtweise hat vielen Projekten geschadet.
Was mir 15 Jahre Webprojekte gelehrt haben
In den Projekten, die wir bei GDM-Pixel durchgeführt haben, habe ich beide Ansätze eingesetzt. Und vor allem habe ich gelernt, wann jeder einzelne versagt.
Visuelle Tools versagen, wenn:
- Der Kunde eine spezifische Funktion benötigt, die der Builder nicht vorsieht
- Performance kritisch wird (ein vollgeladenes Elementor bedeutet leicht 4–6 Sekunden Ladezeit)
- Die Datenstruktur komplex ist (Produktkatalog mit Varianten, dynamische Preisgestaltung, ERP-Integration)
- Das Projekt 5 Jahre lang weiterentwickelt werden muss, ohne von einem Drittanbieter abhängig zu sein
Reiner Code versagt, wenn:
- Der Kunde Inhalte selbst aktualisieren muss, ohne die Agentur anzurufen
- Das Budget 3 Wochen Entwicklung für 5 statische Seiten nicht rechtfertigt
- Time-to-Market entscheidend ist und man nicht den Luxus hat, alles von Grund auf neu zu bauen
Das ist keine Glaubensfrage. Es ist eine Kontextfrage.
Was wir konkret bei unseren Kunden sehen: Die Projekte, die am besten verlaufen, sind jene, bei denen wir das zur dominanten Anforderung passende Tool gewählt haben — nicht das Tool, das wir standardmäßig bevorzugen.
2024: Der echte Paradigmenwechsel
Hier wird es interessant.
Die Code-vs.-WYSIWYG-Opposition war relevant, als die beiden Lager wirklich getrennt waren. Das ist nicht mehr der Fall.
Figma hat die Grenze auf der Design-Seite aufgebrochen. Sie entwerfen visuell, aber Sie exportieren Design-Tokens, Variablen, eine Struktur, die direkt mit Code kommuniziert. Figma-Komponenten werden auf React- oder Astro-Komponenten abgebildet. Die Lücke zwischen “Ich habe entworfen” und “Es ist programmiert” hat sich dramatisch verringert.
Webflow hat dasselbe auf der Entwicklungsseite getan. Sie ziehen visuell Blöcke, aber dahinter ist der generierte Code sauber, semantisch, wartbar. Es ist nicht mehr der Spaghetti-Code von Dreamweaver 2003.
Und vor allem — KI hat die Spielregeln verändert.
Heute schreibt ein Entwickler, der mit Claude Code oder GitHub Copilot arbeitet, Code “von Hand” nicht wirklich von Hand. Er leitet. Er validiert. Er entwirft die Architektur. Die KI generiert die 70 % Wiederholungscode. Was bleibt, ist die Geschäftslogik, Architekturentscheidungen, Optimierungen.
Damit ist die Grenze zwischen “ich programmiere” und “ich nutze ein visuelles Tool” in beide Richtungen unscharf geworden.
“The best interface is no interface — but until we get there, the best interface is the one your team actually uses.” — Golden Krishna, The Best Interface Is No Interface
Die wahren versteckten Kosten jedes Ansatzes
Wie viele Stunden pro Woche verbringen Sie mit der Verwaltung von Updates einer mit Plugins überladenen WordPress-Website?
Das ist die Frage, die niemand stellt, wenn er ein Tool wählt. Man schaut auf die Erstellungskosten. Selten auf die Gesamtkosten über 3 Jahre.
Eine Website mit Consumer-Visual-Builder:
- Schnelle Erstellung, kontrolliertes Anfangsbudget
- Aber: Abhängigkeit vom Anbieter, oft schlechtere Performance, begrenzte Anpassbarkeit, schmerzhafte Migrationen
- Reale Kosten über 3 Jahre: monatliches Abonnement + Zeit für das Umgehen von Einschränkungen + Überarbeitung, wenn die Anforderungen wachsen
Eine maßgeschneidert entwickelte Website mit modernem Stack:
- Höhere Anfangskosten, längere Lieferzeit (es sei denn, der Workflow wurde industrialisiert)
- Aber: maximale Performance, null Drittabhängigkeit, vollständige Skalierbarkeit, vollständiges Eigentum am Code
- Reale Kosten über 3 Jahre: leichte Wartung, gezielte Weiterentwicklungen, keine parasitären Abonnements
Eine hybride Website (Headless CMS + modernes Frontend):
- Das Beste aus beiden Welten auf dem Papier
- Aber: höhere technische Komplexität, erfordert ein Team, das beide Seiten beherrscht
- Reale Kosten über 3 Jahre: hängt vollständig von der Qualität der anfänglichen Architektur ab
Mein Rat für ein kleines Unternehmen mit begrenztem Budget: Wählen Sie nicht danach, was Sie heute erstellen möchten. Wählen Sie danach, was Sie in 18 Monaten ändern müssen — das bestimmt auch, wann ein Relaunch wirklich notwendig ist statt einer einfachen Weiterentwicklung.
Unser aktueller Stack — und warum wir uns entschieden haben
Bei GDM-Pixel haben wir aufgehört zu debattieren. Wir haben gewählt.
Unser Produktions-Stack für Präsentations- und E-Commerce-Websites: Figma für das Design → Astro + Tailwind für das Frontend → Headless CMS für Inhalte → Claude Code zur Entwicklungsbeschleunigung.
Warum diese Wahl?
Astro generiert standardmäßig statisches HTML. Ergebnis: systematisch Lighthouse-Scores über 95. Kein visueller Builder kann auf diesem Kriterium mithalten.
Tailwind eliminiert 80 % der wiederkehrenden CSS-Entscheidungen. Man programmiert schneller, der Code ist konsistenter, die Wartung ist trivial.
Claude Code generiert wiederkehrende Komponenten (Karten, Abschnitte, Formulare) in Sekunden aus unseren standardisierten Prompts. Was 2 Stunden brauchte, dauert jetzt 20 Minuten.
Das Headless CMS (Sanity oder Directus je nach Projekt) bietet dem Kunden eine klare und einfache Bearbeitungsoberfläche, ohne jemals den Code zu berühren.
Konkretes Ergebnis: Wir liefern 5-seitige Websites in 3 Tagen. Projekte, die vor 5 Jahren 3 Wochen brauchten.
Das ist kein WYSIWYG. Es ist auch kein reiner Code. Es ist ein industrialisierter Workflow, der das Beste aus beiden Welten nimmt.
“Tools are only as good as the workflow they fit into.” — Anonym, aber wahr in jedem Projekt, das wir durchgeführt haben.
Was das für Sie bedeutet — als Unternehmer oder Entscheider
Wenn Sie gerade überlegen, wie Sie Ihre Website neu gestalten sollen, sind hier die drei wirklich entscheidenden Fragen:
1. Wer wird die Inhalte täglich pflegen? Wenn Sie selbst oder ein nicht-technischer Mitarbeiter das sind, brauchen Sie eine einfache Bearbeitungsoberfläche. Nicht unbedingt einen vollständigen visuellen Builder — ein gut konfiguriertes CMS reicht völlig aus.
2. Welche Performance-Anforderungen haben Sie? Eine langsame E-Commerce-Website verliert Verkäufe. Google hat es gemessen: Jede zusätzliche Ladesekunde kann die Conversions um 7 bis 12 % reduzieren. Wenn Performance kritisch ist, ist maßgeschneiderter Code kein Luxus — es ist eine Investition.
3. Muss sich Ihre Website in 2 Jahren weiterentwickeln? Wenn ja, zählt die Architektur genauso wie die Ästhetik. Eine schöne Website auf einem fragilen Stack kostet Sie einen kompletten Relaunch statt einer einfachen Weiterentwicklung. Genau das sichern wir bereits bei der Erstellung Ihrer Website ab.
Diese drei Fragen sind mehr wert als jede philosophische Debatte über Code vs. Visuell.
Zusammenfassung: Drei wichtige Punkte
Die Code-vs.-WYSIWYG-Debatte ist überholt. Die eigentliche Frage lautet: Welche Tool-Kombination entspricht Ihrem Projektkontext, Ihrem Wartungsbudget und Ihren Weiterentwicklungsanforderungen?
KI hat die Kosten maßgeschneiderter Entwicklung radikal gesenkt. Was die Wahl eines visuellen Builders “für schnelle Ergebnisse” rechtfertigte, verschwindet gerade. Schnell mit qualitativem Code zu liefern ist heute zugänglich — vorausgesetzt, man hat seinen Workflow industrialisiert.
Performance ist 2024 nicht verhandelbar. Googles Core Web Vitals sind ein direkter Ranking-Faktor. Eine langsame Website bedeutet weniger Sichtbarkeit und weniger Conversions — unabhängig davon, mit welchem Tool sie erstellt wurde.
Gestalten Sie Ihre Website 2024 neu?
Wählen Sie Ihr Tool nicht, bevor Sie Ihre Hauptanforderung definiert haben.
Bei GDM-Pixel beginnen wir alle unsere Projekte mit einer 30-minütigen Diagnose: Was sind Ihre echten Bedürfnisse, was sind Ihre tatsächlichen Einschränkungen, und welcher Stack beantwortet diese am besten — ohne Overselling und ohne Ideologie.
Wenn Ihr Projekt eher ein technisches Audit als einen kompletten Relaunch benötigt, sagen wir Ihnen das. Wenn ein Standard-CMS ausreicht, verkaufen wir Ihnen keine maßgeschneiderte Entwicklung.
Vierzig Jahre nach dem ersten WYSIWYG-Klick bleibt die beste Oberfläche jene, die Ihnen hilft, Ihre Geschäftsziele zu erreichen — nicht jene, die in der Demo beeindruckt.
Kontaktieren Sie GDM-Pixel für eine unverbindliche Diagnose. Wir sagen Ihnen, was für Ihren Fall wirklich funktioniert.
Soziale Netzwerke
Mit KI analysieren
