Warum Bricks, Builderius und Etch das richtige Problem auf der falschen Ebene lösen

Jahrzehntelang gab es im Web eine Sprachbarriere. Auf der einen Seite: menschliche Absicht. Auf der anderen: Maschinencode. Dazwischen: Jahre Lernaufwand, spezialisiertes Handwerk, teure Entwickler. Wer keine dieser drei Dinge hatte, brauchte eine Übersetzungsschicht. So entstanden Page Builder.

Diese Übersetzungsschicht verschwindet gerade. Nicht durch bessere Builder. Sondern weil die Sprache selbst zugänglich wird.

Natürliche Sprache ist der neue Pinsel für das Web. Wer heute "baue mir eine responsive Produktseite mit Hero, Features und CTA" in ein Sprachmodell eingibt, bekommt produktionsreifen Code. Kein Drag-and-Drop. Kein Panel-Konfigurieren. Kein proprietäres Zwischenformat. Die Barriere zwischen Absicht und Ergebnis kollabiert.

In diesem Kontext betrachten wir Bricks Builder, Builderius und Etch in der Wordpress-Welt. Nicht als Antwort auf diese Verschiebung, sondern als Konsequenz einer Einsicht, die noch vor ihr entstand: dass klassische WordPress-Builder strukturell kaputt sind. Das stimmt. Und es reicht trotzdem nicht.

Themebuilder, nicht Pagebuilder: ein Unterschied, der zählt

Aus den Fehlern der ersten Generation an Pagebuildern, hat eine neue Kategorie von Tools gelernt. Bricks Builder, Builderius und Etch haben eine Designentscheidung getroffen, die Elementor nie getroffen hat: HTML-Output als primäre Qualitätsgröße zu behandeln, nicht als Nebenprodukt.

Bevor die technischen Konsequenzen besprochen werden, muss eine Unterscheidung gemacht werden, die in den meisten Builder-Debatten fehlt.

Elementor ist primär ein Pagebuilder. Er wird auf einem bestehenden WordPress-Theme eingesetzt und steuert den Inhalt einzelner Seiten. Header, Footer, Template-Hierarchie bleiben weitgehend außerhalb seiner Kontrolle.

Bricks, Builderius und Etch sind Themebuilder. Sie steuern die gesamte Site-Architektur: globale Templates, Header, Footer, Archivseiten, Single Post Templates, Custom Post Type Templates. Ein Themebuilder, der Code-Qualität ernst nimmt, kann die gesamte Seite konsequent sauber halten. Ein Pagebuilder wie Elementor kann immer nur so gut sein wie der Theme-Code, in dem er eingebettet ist.

Was sauberer Code im KI-Kontext bedeutet

KI-Modelle wurden auf Webstandards trainiert: HTML, CSS, JavaScript. Je näher ein System an diesen Standards bleibt, desto besser kann eine KI damit arbeiten. Kevin Geary, der Entwickler hinter Etch, hat das direkt formuliert: KI kennt HTML, CSS und JavaScript. Sie kennt keine Builder-Syntax.

Das ist der entscheidende strukturelle Vorteil dieser Themebuilder gegenüber Elementor, und er hat nichts mit KI-Features im Builder zu tun. Er liegt in der Grundarchitektur.

Aber er hat eine harte Grenze. Sauberer HTML-Output bedeutet nicht, dass die Datenschicht darunter sauber ist. Und die Datenschicht ist das eigentliche Problem.

Was keine Builder-Generation reparieren kann: das Fundament

Hier liegt der Kern, den weder Elementor noch Bricks noch Etch lösen können.

WordPress wurde 2003 entworfen. Das Datenbankschema ist für eine Welt ohne Cloud-native Architektur, ohne Serverless, ohne KI-native Workflows konzipiert.

WordPress führt je nach Seitentyp zwischen 20 und 100 Datenbankabfragen pro Seitenaufruf durch. Die wp_postmeta-Tabelle, in der Builder-Layouts, Custom Fields und Plugin-Einstellungen als Key-Value-Paare gespeichert werden, ist bei komplexen Sites einer der häufigsten Performance-Bottlenecks. Die wp_options-Tabelle lädt Autoload-Daten bei jedem Request, unabhängig davon ob diese Daten auf der aktuellen Seite gebraucht werden. WordPress-Plugins laufen im selben Ausführungskontext wie WordPress Core, ohne Sandbox, ohne Berechtigungsmodell: 96% aller Sicherheitsprobleme auf WordPress-Sites haben ihren Ursprung in Plugins (Cloudflare, 2026).

Elementor kann diese Eigenschaften nicht ändern. Bricks kann sie nicht ändern. Etch kann sie nicht ändern. Die zweite Builder-Generation baut saubereren Code auf demselben Fundament. Das ist ein echter Fortschritt. Es ist kein Ausweg.

Und KI? Das gemeinsame Muster: Alle drei Themebuilder haben sauberen Code-Output, aber ihre KI-Strategien behandeln aktuell die gleiche Grundfrage wie ein Elementor: Wie bringe ich KI dazu, durch WordPress-Strukturen zu navigieren? Die Antwort auf diese Frage ist strukturell ineffizienter als die Alternative, KI direkt auf Webstandards arbeiten zu lassen.

Wer braucht noch ein visuelles Interface für Entwicklung?

Hier liegt eine Verschiebung, die direkter gestellt werden sollte als es die Builder-Industrie tut.

Ein visuelles Entwicklungs-Interface hatte zwei Funktionen. Erstens: Entwicklern helfen, schneller zu prototypen und zu iterieren. Zweitens: Nicht-Entwicklern ermöglichen, ohne Code zu arbeiten.

KI verändert beide Funktionen fundamental.

Für Entwickler ist das visuelle Interface des Themebuilders zunehmend optional. Wer heute in Werzeugen wie Cursor oder mit Claude Code arbeitet, hat einen Coding-Partner, der Template-Hierarchien versteht, komponentenbasierte Architektur aufbaut und Iterationen in Minuten durchführt. Das UI eines Builders ist in diesem Workflow ein Umweg, kein Vorteil. Etch bewirbt sich explizit als Cursor-ähnliche Erfahrung. Die ehrlichere Frage ist: Wenn Cursor bereits Cursor ist, warum dann Etch?

Was bleibt, ist die zweite Funktion: Content-Pflege durch Redakteure, Marketingteams, Nicht-Entwickler. Diese Gruppe braucht ein Interface. Aber sie braucht kein Entwicklungs-Interface. Sie braucht ein sauberes CMS-Interface für Inhaltsaufgaben.

Die sinnvollste Aufteilung moderner Workflows ist nicht "welcher Builder", sondern die Trennung zweier Aufgaben, die Builder künstlich vereint haben: Entwicklung über KI-direkten Code auf Webstandards, Content-Pflege über ein schlankes CMS-Interface.

EmDash: Wenn die Frage selbst neu gestellt wird

Am 1. April 2026 hat Cloudflare EmDash angekündigt. Es ist kein Aprilscherz. Und es illustriert das Argument dieses Artikels besser als jedes theoretische Beispiel es könnte.

Cloudflare hat WordPress nicht verbessert. Cloudflare hat WordPress weggelassen und neu gebaut. EmDash ist vollständig in TypeScript geschrieben, auf Astro aufgebaut, serverlos ausgelegt und ohne eine einzige Zeile WordPress-Code entstanden. Ein Ingenieur, zwei Monate, intensiver Einsatz von KI-Coding-Agenten.

Die Architekturentscheidungen sind konsequent: Jedes Plugin läuft in einer isolierten Sandbox mit explizit deklarierten Berechtigungen, AI-native konzipiert mit Agent Skills, CLI und eingebautem MCP-Server.

Praktisch relevant ist, wo das Lock-in tatsächlich liegt: EmDash kann WordPress-Inhalte bereits heute importieren, Posts, Seiten, Medien. Was nicht portierbar ist, sind Builder-Abstraktionen. Elementor-Layouts, Bricks-Templates, Divi-Shortcodes: diese Schichten bleiben zurück. Der Content ist frei. Die Abstraktionsschicht ist das Lock-in.

Matt Mullenweg hat EmDash als "very solid" mit "some excellent engineering" beschrieben, die Agent Skills als "amazing" und "a brilliant strategy", und eingeräumt, dass Automattic etwas Vergleichbares entwickeln muss (CMSWire, 2026). Das ist keine Ablehnung. Das ist die Bestätigung der Richtung durch den Mann, der WordPress leitet. Auch wenn er noch andere Worte genutzt hat.

EmDash ist v0.1.0, ohne Plugin-Community und Themes-Marktplatz. Für die Mehrheit heutiger WordPress-Nutzer ist es noch keine valide Alternative.

Aber EmDash ist kein Produkt für heute. Es ist ein Signal über die Richtung. Ein Infrastrukturunternehmen hat WordPress als Architekturproblem eingestuft, das durch Neubau effizienter lösbar ist als durch iterative Verbesserung, und hat das in zwei Monaten bewiesen.

Konsequenzen

Elementor und Divi haben für eine Dekade echten Mehrwert geliefert. Millionen von Menschen haben Websites gebaut, die sie ohne diese Tools nicht hätten bauen können. Das ist real.

Bricks und Etch haben aus den Fehlern der ersten Generation gelernt. Ihr Code ist sauberer, ihre Architektur ist tiefer, ihre KI-Kompatibilität ist höher. Für professionelle WordPress-Entwickler, die heute Entscheidungen treffen müssen, sind sie die vernünftigere Wahl.

Aber die wichtigere Entscheidung ist "WordPress, ja oder nein", nicht "welcher Builder". Headless WordPress mit Astro oder Next.js, direktes Framework-basiertes Development mit KI-direktem Code, oder EmDash auf mittlere Sicht: Diese Optionen gehören auf den Evaluierungstisch.

Bricks- und Etch-Expertise hat heute einen realen Markt. Das ist kein Argument gegen den Aufbau dieser Kenntnisse. Es ist ein Argument dafür, parallel den Weg zu framework-basierter, KI-direkter Entwicklung anzufangen.

Fazit

Die Sprachbarriere zwischen Mensch und Computer war der eigentliche Grund für alle Builder-Generationen. Elementor hat diese Barriere auf die falsche Weise gesenkt: mit proprietären Formaten, aufgeblähtem Code, kaputten Abstraktionen. Bricks und Etch haben es besser gemacht, mit sauberem HTML, klarer Architektur, tiefer Site-Kontrolle.

Was keine dieser Generationen verändern kann: Die Barriere selbst verschwindet. Nicht durch bessere Builder, sondern weil natürliche Sprache zur direkten Schnittstelle zwischen menschlicher Absicht und Maschinencode wird. KI übersetzt ohne proprietäre Zwischenformate, ohne visuelle Umwege, auf Basis von Webstandards, die seit Jahrzehnten dokumentiert sind.

Zwei Generationen WordPress-Builder. Dieselbe strukturelle Frage. Eine Antwort, die von beiden noch nicht vollständig gegeben wurde.


Quellen: