1984: Der erste Klick änderte alles
Vierzig Jahre. So lange blieb die Frage offen.
1984 stellte Apple den Macintosh mit einem einfachen Versprechen vor: Was Sie auf dem Bildschirm sehen, erhalten Sie auf dem Papier. Das WYSIWYG-Paradigma — What You See Is What You Get — war geboren. Wenige Jahre später eroberte es die Website-Erstellung. Dreamweaver, FrontPage, dann WordPress, Wix, Webflow… Das Versprechen hat sich nie geändert: Erstellen ohne Programmieren.
Vierzig Jahre später ist die Debatte noch immer nicht entschieden. Und doch hat sich 2024 in Workshops und Webagenturen etwas grundlegend verändert.
Hier ist, was man in der Praxis wirklich sieht — und warum die eigentliche Frage nicht mehr „Code oder visuelle Oberfläche” lautet, sondern „welches Tool für welchen Anwendungsfall, zu welchem Zeitpunkt im Projekt”.
Die Geschichte eines falschen Duells
Stellen Sie einem Web-Entwickler aus den 2000er-Jahren die Frage: Dreamweaver oder Notepad? Sie erhalten eine klare, oft leidenschaftliche, manchmal herablassende Antwort.
„Reine” Entwickler betrachteten visuelle Tools als Spaghetti-Code-Generatoren. Designer liebten sie, weil sie kein CSS lernen mussten. Die beiden Lager ignorierten sich lange — oder bekämpften sich.
Was vergessen wird: Dieses Duell war immer künstlich.
Ein WYSIWYG-Tool hat nie behauptet, 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 Kleinunternehmen, das seine Seite „Unsere Leistungen” einmal im Monat aktualisieren möchte — eine Abwägung, die wir bereits ausführlich am Beispiel der visuellen Builder unter WordPress besprochen haben.
Das Problem: Beide Ansätze wurden lange als gegenseitig ausschließend dargestellt. Entweder man programmiert, oder man nutzt einen visuellen Builder. Entweder man ist seriös, oder man macht Wix.
Diese binäre Sichtweise hat vielen Projekten geschadet.
Was mich 15 Jahre Web-Projekte gelehrt haben
In den Projekten, die wir bei GDM-Pixel durchgeführt haben, habe ich beide Ansätze genutzt. Und vor allem habe ich gelernt, wann jeder einzelne scheitert.
Visuelle Tools scheitern, wenn:
- Der Kunde eine spezifische Funktion möchte, die der Builder nicht vorsieht
- Performance kritisch wird (ein geladenes Elementor erreicht schnell 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 scheitert, wenn:
- Der Kunde seinen Inhalt selbst aktualisieren muss, ohne die Agentur anzurufen
- Das Budget 3 Wochen Entwicklung für 5 statische Seiten nicht rechtfertigt
- Die Time-to-Market kritisch ist und kein Spielraum besteht, alles von Grund auf aufzubauen
Das ist keine Glaubensfrage. Es ist eine Frage des Kontexts.
Was wir bei unseren Kunden konkret beobachten: Die Projekte, die am besten laufen, sind jene, bei denen wir das Tool gewählt haben, das zur dominanten Einschränkung passt — nicht das Tool, das wir standardmäßig bevorzugen.
2024: Der echte Paradigmenwechsel
Hier wird es interessant.
Die Gegenüberstellung Code vs. WYSIWYG war relevant, als die beiden Lager wirklich getrennt waren. Das ist nicht mehr der Fall.
Figma hat die Grenze auf der Design-Seite aufgebrochen. Man zeichnet visuell, exportiert aber Design-Tokens, Variablen, eine Struktur, die direkt mit Code kommuniziert. Figma-Komponenten werden auf React- oder Astro-Komponenten gemappt. Die Lücke zwischen „ich habe entworfen” und „es ist programmiert” hat sich dramatisch verkleinert.
Webflow hat dasselbe auf der Entwicklungsseite getan. Man zieht visuelle Blöcke, aber der generierte Code dahinter ist sauber, semantisch und wartbar. Das ist nicht mehr der Spaghetti-Code von Dreamweaver 2003.
Und vor allem — KI hat die Spielregeln verändert.
Heute, mit Claude Code oder GitHub Copilot, schreibt ein Entwickler, der Code „von Hand” schreibt, ihn nicht wirklich von Hand. Er leitet. Er validiert. Er entwirft Architekturen. Die KI generiert die 70% repetitiven Code. Was bleibt, ist die Geschäftslogik, Architekturentscheidungen, Optimierungen.
Die Grenze zwischen „ich programmiere” und „ich benutze ein visuelles Tool” ist dadurch in beide Richtungen verschwommen.
“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 auf einer mit Plugins überladenen WordPress-Website?
Das ist die Frage, die niemand stellt, wenn man ein Tool auswählt. Man schaut auf die Erstellungskosten. Selten auf die Gesamtbetriebskosten über 3 Jahre.
Eine Website mit einem gängigen visuellen Builder:
- Schnelle Erstellung, kontrolliertes Anfangsbudget
- Aber: Abhängigkeit vom Anbieter, oft beeinträchtigte Performance, begrenzte Anpassungsmöglichkeiten, schmerzhafte Migrationen
- Echte Kosten über 3 Jahre: monatliches Abo + Zeit für das Umgehen von Einschränkungen + Neugestaltung, wenn sich Anforderungen ändern
Eine maßgeschneiderte Website mit modernem Tech-Stack:
- Höhere Anfangskosten, längere Lieferzeit (außer wenn industrialisiert, vgl. unseren Workflow)
- Aber: maximale Performance, null Drittanbieter-Abhängigkeit, volle Skalierbarkeit, vollständige Code-Ownership
- Echte Kosten über 3 Jahre: leichte Wartung, gezielte Weiterentwicklungen, kein überflüssiges Abo
Eine hybride Website (Headless CMS + modernes Front-End):
- Das Beste aus beiden Welten auf dem Papier
- Aber: höhere technische Komplexität, erfordert ein Team, das beide Seiten beherrscht
- Echte Kosten über 3 Jahre: hängt vollständig von der Qualität der anfänglichen Architektur ab
Mein Rat für ein Kleinunternehmen mit begrenztem Budget: Wählen Sie nicht basierend auf dem, was Sie heute erstellen möchten. Wählen Sie basierend auf dem, was Sie in 18 Monaten ändern müssen — das bestimmt auch, wann ein Website-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 Showcase- und E-Commerce-Websites: Figma für das Design → Astro + Tailwind für das Front-End → Headless CMS für den Inhalt → Claude Code zur Entwicklungsbeschleunigung.
Warum diese Wahl?
Astro generiert standardmäßig statisches HTML. Ergebnis: Lighthouse-Werte systematisch über 95. Kein visueller Builder kann bei diesem Kriterium mithalten.
Tailwind eliminiert 80% der repetitiven CSS-Entscheidungen. Wir programmieren schneller, der Code ist konsistenter, die Wartung ist trivial.
Claude Code generiert repetitive Komponenten (Karten, Sektionen, Formulare) in Sekunden aus unseren standardisierten Prompts. Was früher 2 Stunden dauerte, dauert jetzt 20 Minuten.
Das Headless CMS (Sanity oder Directus je nach Projekt) gibt dem Kunden eine klare, einfache Bearbeitungsoberfläche, ohne dass er jemals den Code berühren muss.
Konkretes Ergebnis: Wir liefern 5-seitige Websites in 3 Tagen. Projekte, die vor 5 Jahren 3 Wochen dauerten.
Das ist kein WYSIWYG. Es ist auch kein reiner Code. Es ist ein industrialisierter Workflow, der das Beste aus beiden Welten vereint.
“Tools are only as good as the workflow they fit into.” — Anonym, aber in jedem Projekt wahr, das wir durchgeführt haben.
Was das für Sie bedeutet — Unternehmer oder Entscheider
Wenn Sie entscheiden, wie Sie Ihre Website neu gestalten möchten, sind das die drei Fragen, die wirklich zählen:
1. Wer pflegt täglich die Inhalte? Wenn Sie oder ein nicht-technischer Mitarbeiter dies tun, 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 Sekunde Ladezeit 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 wird Sie eine vollständige Neuentwicklung statt einer einfachen Weiterentwicklung kosten. Genau das sichern wir von Anfang an bei der Erstellung Ihrer Website.
Diese drei Fragen sind mehr wert als jede philosophische Debatte über Code vs. Visuell.
Zusammenfassung: Drei Punkte zum Mitnehmen
Die Debatte Code vs. WYSIWYG ist überholt. Die eigentliche Frage lautet: Welche Tool-Kombination entspricht Ihrem Projektkontext, Ihrem Wartungsbudget und Ihren Weiterentwicklungseinschränkungen?
KI hat die Kosten für maßgeschneiderte Entwicklung radikal gesenkt. Was früher den Einsatz eines visuellen Builders „zum schnellen Vorankommen” rechtfertigte, verschwindet. Schnell mit qualitativ hochwertigem Code zu liefern ist nun 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 vom verwendeten Tool.
Gestalten Sie Ihre Website 2024 neu?
Wählen Sie Ihr Tool nicht, bevor Sie Ihre wichtigste Einschränkung 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 sie am besten — ohne Übertreibungen und ohne Ideologie.
Wenn Ihr Projekt ein technisches Audit statt einer vollständigen Neugestaltung 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 diejenige, die Ihnen hilft, Ihre Geschäftsziele zu erreichen — nicht diejenige, die in einer Demo beeindruckt.
Kontaktieren Sie GDM-Pixel für eine unverbindliche Diagnose. Wir sagen Ihnen, was für Ihren Fall wirklich funktioniert.