CSS Frameworks für Bricks Builder: Der große Vergleich 2026

Ein Meinungsbeitrag mit Recherche. Alle Einschätzungen in diesem Artikel spiegeln persönliche Erfahrungen und Bewertungen wider. Preise und Features wurden im April 2026 recherchiert.

Wer mit Wordpress und Bricks Builder arbeitet, steht früher oder später vor einer zentralen Entscheidung: Nutze ich ein CSS Framework, und wenn ja, welches? Die Antwort beeinflusst den gesamten Workflow, die Wartbarkeit der Projekte und letztlich auch die Geschwindigkeit, mit der neue Websites entstehen.

Dieser Beitrag vergleicht die aktuell relevanten CSS Frameworks für Bricks qualitativ und quantitativ, ordnet sie ein und nimmt dabei kein Blatt vor den Mund. Am Ende steht ein Fragenkatalog, der bei der Entscheidung hilft.

Hinweis zu Preisangaben: Alle Preise sind auf Euro umgerechnet (1 USD ≈ 0,92 EUR, Stand April 2026). Die meisten internationalen Anbieter rechnen in USD und weisen Nettopreise aus. Für Käufer aus Deutschland kommen 19 % Umsatzsteuer hinzu, sofern der Anbieter diese nicht bereits berechnet. Im Zweifel: Preis auf der Checkout-Seite prüfen.

Warum überhaupt ein CSS Framework?

Bricks Builder liefert seit Version 2.2 einen solides Styling-System mit Style Manager, Fluid Typography, Spacing Scales und Color Manager. Man kann damit vollständig ohne Framework arbeiten oder schlicht eines importieren. Trotzdem entscheiden sich viele Entwickler für ein zusätzliches Framework, weil sie damit:

• Konsistenz erzwingen: Farben, Abstände und Typografie folgen einem System statt individueller Entscheidungen pro Element. Unerlässlich für Teamwork.
• Responsive-Arbeit reduzieren: Fluid Typography und Spacing mit clamp() ersetzen manuelle Breakpoint-Anpassungen.
• Wartbarkeit erhöhen: Änderungen an einer zentralen Variable wirken sich auf die gesamte Site aus. Einhaltung des DRY (Don't repeat yourself)-Prinzips
• Geschwindigkeit steigern: Variablen-Tokens beschleunigen den Build-Prozess erheblich.
• Best Practices einhalten: opinionated Frameworks wie ACSS bringen bewährte Konventionen mit, die besonders Teams und Einsteigern helfen.

Gleichzeitig bringt jedes Framework auch Nachteile: zusätzliche Abhängigkeit, Lernkurve, potenzielle Kosten und die Frage, was passiert, wenn der Hersteller aufhört zu entwickeln. Dass das keine theoretische Sorge ist, zeigt der Fall OxyProps weiter unten.

Die Frameworks im Überblick

1. Bricks Native (Style Manager)

Ansatz: Seit Bricks 2.2 (Februar 2026) liefert Bricks ein eigenes, ausgewachsenes Design-System-Werkzeug: den Style Manager. Dieses Update hat die Ausgangslage grundlegend verändert. Bricks bietet jetzt nativ, was früher ein Drittanbieter-Framework erforderte. Ich persönlich finde es super, dass Bricks das jetzt nativ hat. Ein paar Kudos an Maxime Beguin (Advanced Themer) und das Team um David Babinec (Core Framework), hätten allerdings nicht geschadet, da die beiden das vorgelegt haben.

Preis: Kostenlos (im Bricks-Lizenzpreis enthalten)

Was der Style Manager mitbringt (seit Bricks 2.2/2.3):

• Color Manager: Farbpaletten mit automatischer Generierung von Schattierungen, Transparenzen und komplementären Farben. Light/Dark-Mode-Varianten pro Farbe. Import/Export als JSON.
• Fluid Typography Generator: Seit 2.1 unbegrenzte Typography Scales mit T-Shirt-Sizes, numerischer oder Custom-Benennung. Skalierung über clamp() mit konfigurierbaren Breakpoints und Ratios.
• Spacing Scales: Analog zur Typografie auch für Abstände. Fluid, variabel, exportierbar.
• Global Variable Manager: CSS-Variablen direkt im Builder erstellen, kategorisieren und verwalten.
• CSS Framework Importer: Beliebige CSS-Dateien importieren. Bricks extrahiert automatisch Klassen und Variablen und gruppiert sie nach Kategorien.
• Live Preview on Hover: Farben, Klassen und Variablen werden beim Hovern live auf dem Element vorgeschaut.
• HTML & CSS to Bricks (seit 2.3): HTML und CSS aus beliebigen Quellen einfügen, Bricks konvertiert automatisch in native Elemente, Klassen und Variablen.

Wer einen vorkonfigurierten Startpunkt ohne Plugin sucht, kann zusätzlich Fancy Framework nutzen: ein kostenloses Variablen-Set (Fluid Typography, Spacing, Farbpalette), das als JSON-Import und CSS-Snippet direkt in Bricks geladen wird. Keine Abhängigkeit, kein Plugin, aber auch keine Utility-Klassen oder Autovervollständigung. Für Einsteiger ein pragmatischer Einstieg, bevor man ein eigenes System aufbaut.

Stärken:

• Keine zusätzliche Abhängigkeit, kein Plugin, kein Vendor Lock-in
• Volle Kontrolle über jeden Aspekt des CSS
• Zukunftssicher, da direkt von Bricks gepflegt
• Export der generierten Variablen und Klassen als CSS-Datei

Schwächen:

• Kein opinionated Workflow: Man muss eigene Entscheidungen über Namenskonventionen, Skalen und Struktur treffen (kann je nach Philosophie auch Vorteil sein)
• Keine SCSS-Mixins oder erweiterte Developer-Tools
• Für Teams fehlt die erzwungene Konvention, die ein Framework wie ACSS liefert, beziehungsweise es erfordert die Disziplin eine zu erzeugen und einzuhalten
• Kein Convert-to-REM-Feature oder Clickable-Parent-Klassen

Meine Einschätzung: Seit Bricks 2.2 ist „kein Framework" nicht mehr gleichbedeutend mit „alles manuell". Die Frage „Brauche ich noch ein kommerzielles CSS Framework?" wird seit diesem Update in der Community ernsthaft diskutiert, und die Antwort ist nicht mehr automatisch „ja".

2. Automatic.css (ACSS)

Website: automaticcss.com

Ansatz: Begonnen als Utility-Framework, weiterentwickelt als komplette CSS-Tool-Library, speziell für WordPress Theme Builder wie Bricks, Etch entwickelt. Kombiniert BEM-Klassen mit CSS-Variablen und einem UI-Dashboard zur Konfiguration. Stark opinionated mit klaren Best Practices und steter Weiterentwicklung.

Preis (Nettopreise, zzgl. 19 % USt. für DE-Käufer):

• Freelancer (3 Sites): ab ca. 73 €/Jahr (79 $)
• Agency Pro (unlimited): ca. 137 €/Jahr (149 $)
• Lifetime (unlimited): ab ca. 367 € einmalig (399 $)

Stärken:

• Umfangreichstes Feature-Set aller Bricks-Frameworks
• Automatische Typografie-Skalierung, Farbschattierungen, Spacing-Rhythmus
• „True Builder Integration" mit Autovervollständigung und Kontextmenüs in Bricks
• Automatische mobile Optimierung (laut Hersteller 60–90 % weniger Responsive-Arbeit)
• Umfangreiche Dokumentation, Videokurse und aktive Community
• Auto-BEM-Funktion (ctr) und SCSS-Mixins für Fortgeschrittene
• Accessibility-Features wie Clickable Parent mit einer Klasse
• „Frames" als ergänzendes Wireframing- und Komponenten-System und zusätzliche Figma Librarys und Werkzeuge.
• Mittlerweile großes Entwicklerteam dahinter.

Schwächen:

• Höchster Preis unter den Frameworks (für Agenturen günstig, für Freelancer, gerade zu Beginn eine Investitition)
• Steilere Lernkurve durch den Umfang der Features
• Opinionated: Wer vom ACSS-Workflow abweicht, arbeitet gegen das System
• Updates (sowohl Builder als auch Framework) können Wartungs- und Reparaturaufwand erzeugen, da kein Baking vorhanden.
• Kann für kleine, einfache Projekte überdimensioniert sein

Der Elefant im Raum: Etch, Version 4 und die Zukunft von ACSS

ACSS-Gründer Kevin Geary entwickelt mit Etch einen eigenen WordPress Page Builder, der als „Visual Development Environment" positioniert wird und auf Gutenberg-APIs aufbaut. Etch ist das erklärte Herzstück von Gearys Unternehmen Digital Gravy. Die offizielle Linie lautet: ACSS wird weiterhin Bricks unterstützen. In der Praxis zeigt sich ein differenzierteres Bild.

ACSS Version 4 bringt einen radikalen Schnitt:

• Kein Support mehr für GenerateBlocks, Breakdance.
• Nicht rückwärtskompatibel mit Version 3. Die Mehrheit der Utility-Klassen wurde entfernt. Vergleiche zeigen: ACSS 4 ist 85 % leichter als 3.3.6, was sich gut anhört, aber bedeutet, dass über 2.300 CSS-Einträge (Variablen, Klassen, Selektoren) weggefallen sind.
• Version 3 erhält fünf Jahre Security-Updates, aber keine neuen Features mehr.
• Utility-Klassen werden in v4 zu „Recipes" umgebaut, die über spezielle Trigger (@ in Bricks) abgerufen werden, statt als globale Klassen geladen zu sein.

Was das für Bricks-Nutzer konkret bedeutet: Wer heute 20, 50 oder 100 Client-Sites auf ACSS v3 betreibt, steht bei einer potenziellen Migration auf v4 vor einem erheblichen Aufwand. Klassen, die in v3 existierten, sind in v4 nicht mehr vorhanden. CSS-Variablen haben sich verändert. Custom CSS, das auf v3-Selektoren referenziert, bricht. Diese Nacharbeit ist für Agenturen und Freelancer unbezahlte Arbeit an bestehenden Projekten, die kein Client beauftragt hat. Fairerweise muss man aber auch sagen: Man muss nicht upgraden. Bei einer durchschnittlichen Lebensdauer von 3 Jahren je Website, stehen Kosten-Nutzen auch nicht im Verhältnis.

Gleichzeitig bleibt die Frage: Wie priorisiert ein Team, das gleichzeitig Etch, ACSS und Frames entwickelt, den Support für einen Drittanbieter-Builder wie Bricks? Geary hat zugesagt, dass ACSS v4 Bricks unterstützen wird. Aber das Muster ist erkennbar: ACSS wird zunehmend für Etch optimiert, und Bricks-Support wird zum Mitnahme-Feature statt zum Kernprodukt.

Meine Einschätzung: ACSS ist nach wie vor das Feature-reichste Framework. Aber wer heute einsteigt, sollte sich bewusst sein, dass die strategische Reise in Richtung Etch geht. Für neue Projekte lohnt sich ein Blick auf v4 und seine Kompatibilität mit dem eigenen Workflow. Für bestehende v3-Projekte empfiehlt sich ein realistischer Migrationsplan und eine ehrliche Kalkulation der Migrationskosten.

3. Core Framework

Website: coreframework.com

Ansatz: Modulares CSS-Framework mit visueller Oberfläche zur Konfiguration. Verfügbar als kostenlose Web-App, als kostenloses WordPress-Plugin und mit kostenpflichtigen Builder-Addons.

Preis:

• Web-App und WordPress-Plugin: kostenlos
• Bricks Builder Addon: ca. 119 € einmalig (Nettopreis, über den Core Framework Marketplace)
• Gutenberg-Integration: kostenlos enthalten

Stärken:

• Kostenloser Einstieg, sowohl als Web-App als auch als WP-Plugin
• Modularer Aufbau: Klassen und Variablen können einzeln aktiviert oder entfernt werden
• Visuelle UI zur Verwaltung von Farben, Typografie, Spacing und Komponenten
• Builder-übergreifend: funktioniert mit Bricks, Oxygen und Gutenberg
• Kein Vendor Lock-in: Stylesheet kann exportiert und ohne Plugin weiterverwendet werden
• Fluid Typography und Spacing mit mathematischen Skalen
• Aktive Weiterentwicklung, über 4.000 User, auf WordPress.org gelistet

Schwächen:

• Bricks-Integration (Addon) ist kostenpflichtig und separat zu erwerben
• Weniger opinionated als ACSS, erfordert mehr eigene Entscheidungen
• Dokumentation und Onboarding-Material nicht so umfangreich wie bei ACSS
• Community kleiner als die ACSS-Community
• Einige User berichten von gelegentlichen Bugs in der Gutenberg-Integration

Meine Einschätzung: Core ist der beste Kandidat für Menschen die Ihr eigenes Framework entwickeln möchten und bereit sind die Verantwortung dafür zu übernehmen. Flexibel genug, um sich dem eigenen Workflow anzupassen, strukturiert genug, um Konsistenz zu gewährleisten. Der Export-Ansatz (CSS ohne Plugin nutzbar) macht es zum Framework mit dem geringsten Lock-in-Risiko. Für Teams mit Bricks und Gutenberg ist es die naheliegendste Wahl.

4. Advanced Themer (AT Framework)

Website: advancedthemer.com

Ansatz: Primär ein Plugin zur Erweiterung von Bricks Builder (Builder Tweaks, Produktivitätshacks), das seit einiger Zeit auch ein eigenes CSS-Framework mitbringt. Das AT Framework ist eine Unterfunktion von Advanced Themer.

Preis (inkl. MwSt. für EU-Käufer):

• 1 Lizenz: 59 €/Jahr
• 5 Lizenzen: 99 €/Jahr
• Unlimited: 149 €/Jahr
• Lifetime (unlimited): 369 € einmalig

Stärken:

• Zwei Produkte in einem: Framework plus umfangreiche Builder-Erweiterungen (176 Features)
• Extrem einfache Einrichtung direkt in Bricks, kein separates Dashboard
• Fluid CSS-Variablen, Farbpaletten-Generator mit Schattierungen
• Visueller CSS Grid Builder
• AI-Integration für CSS-Generierung im Editor
• „Strict Editor View" zum Schutz vor Client-Änderungen
• Performant: kein JS-Framework auf dem Frontend, keine ungenutzten Utility-Klassen
• Modularer Ansatz: einzelne Features können deaktiviert werden
• Aktiver und extrem freundlicher Entwickler

Schwächen:

• Das Framework ist bewusst simpler als ACSS, bietet weniger Details
• Nur für Bricks Builder, kein Cross-Builder-Support
• AT ist ein Schweizer Taschenmesser. Wie bei dem muss man es aber erstmal erlernen. Es hat wirklich viele Features
• Keine Produkttrennung zwischen Framework und Builder-Tweaks
• So cool Maxime ist, er ist eine One-Man-Show.

Meine Einschätzung: AT ist das unterschätzte Paket. Wer die Builder-Erweiterungen sowieso nutzt (und die sind exzellent), bekommt das Framework quasi geschenkt. Für Entwickler, denen ACSS zu viel und Bricks Native zu wenig ist, trifft AT einen Sweet Spot.

5. OxyProps / BricksProps (eingestellt)

Website: oxyprops.com (Stand April 2026 noch erreichbar, aber ohne erkennbare Aktivität)

Status: OxyProps ist das Paradebeispiel dafür, warum Vendor Lock-in bei CSS Frameworks ein reales Risiko ist. Das Projekt basierte auf Open Props, einer Open-Source-Sammlung von CSS Custom Properties, und erweiterte diese um Utility-Klassen, Custom Elements und eine Builder-Integration für Oxygen und Bricks. In Bricks benannte sich das Plugin automatisch zu „BricksProps" um.

OxyProps war technisch elegant: ein Zero-Specificity-Ansatz, Smart Context Menus, Light/Dark Mode out of the box, ein durchdachtes Farbsystem und ein günstiger Lifetime-Preis ab 49 €. Es wurde von einem einzelnen Entwickler (Cédric Bontems) gepflegt. Genau das wurde zum Problem.

Das letzte substanzielle Update von OxyProps stammt aus Ende 2024 (Version 1.11.2). Seitdem herrscht Funkstille: keine neuen Releases, keine Kommunikation über die Zukunft des Projekts, keine Reaktion auf Kompatibilitätsfragen mit neueren Bricks-Versionen. Das Projekt ist de facto tot.

Was man daraus lernen kann:

• Ein Ein-Personen-Projekt kann jederzeit und ohne Vorwarnung aufhören zu existieren.
• „Open Source Basis" (Open Props) schützt nur die zugrunde liegenden CSS Custom Properties, nicht die Builder-Integration, die Utility-Klassen oder die Custom Elements.
• Wer heute noch OxyProps im Einsatz hat, steht vor der Frage: Manuell migrieren oder hoffen, dass nichts bricht.
• Der günstige Lifetime-Preis war im Nachhinein ein Warnsignal: Ein einzelner Entwickler kann ein Framework dieser Komplexität nicht dauerhaft zu diesem Preis pflegen.

OxyProps bleibt in diesem Vergleich als Warnung stehen. Wer ein Framework evaluiert, sollte immer fragen: Was passiert, wenn dieses Projekt morgen verschwindet?

6. Winden (Tailwind CSS für WordPress)

Website: dplugins.com/downloads/winden

Ansatz: Bringt Tailwind CSS in WordPress und Page Builder. Kompiliert Tailwind direkt im Browser, ohne Node.js oder lokale Entwicklungsumgebung. Scannt sowohl Dateien als auch die WordPress-Datenbank.

Preis: Annual und Lifetime-Optionen über dPlugins (ca. 45–92 € netto/Jahr, zzgl. USt., genaue Preise auf der Website)

Stärken:

• Volle Tailwind CSS 4 Integration ohne Build-Pipeline
• Finales CSS unter 10 KB durch JIT-Kompilierung
• Builder-übergreifend: Bricks, Oxygen, Breakdance, Elementor, Gutenberg, klassische Themes
• Zugang zum gesamten Tailwind-Ökosystem (DaisyUI, Flowbite, Preline UI etc.)
• Autocomplete für Tailwind-Klassen in Bricks
• @apply-Direktive zum Extrahieren wiederholter Patterns in Custom Classes
• Kein Vendor Lock-in: Tailwind-Klassen funktionieren unabhängig vom Plugin

Schwächen:

• Erfordert solide Tailwind-Kenntnisse; Bricks oder auch allgemein Builder sind dafür eigentlich nicht ausgelegt
• Dokumentation wird von Nutzern als lückenhaft beschrieben
• Kein visuelles Dashboard wie bei ACSS oder Core im Builder.
• Die DX (Developer Experience) in Bricks ist nicht vergleichbar mit Tailwind in VS Code
• Debugging kann komplex werden, wenn Bricks-Styles und Tailwind-Klassen kollidieren

Persönliche Einschätzung: Tailwind CSS gehört nicht in einen Page Builder

Tailwind CSS ist ein hervorragendes Werkzeug. Es hat die Frontend-Entwicklung in React, Vue und Svelte nachhaltig verändert und dominiert dort zu Recht. Aber ein Page Builder ist nicht das Umfeld, für das Tailwind konzipiert wurde, und die Übertragung funktioniert in der Praxis schlechter als in der Theorie.

Der Kerngedanke von Tailwind ist: Utility-Klassen direkt im Markup anwenden, statt separate Stylesheets zu pflegen. In einem komponentenbasierten Framework wie React oder Svelte ist das elegant, weil jede Komponente ihren eigenen, isolierten Scope hat. In einem Page Builder wie Bricks hingegen erzeugt dieser Ansatz schnell Spaghetti-HTML: Elemente tragen 15, 20 oder mehr Klassen, die Struktur wird im Builder unübersichtlich, und die Wartbarkeit leidet. Was in einer .svelte-Datei lesbar ist, wird im Bricks-Strukturbaum zum Alptraum.

Dazu kommt: Tailwind skaliert in einem Builder-Kontext schlecht. In einem Code-Editor hat man Suchen-und-Ersetzen, Linting, Tailwind IntelliSense und die volle Kontrolle über das Markup. In Bricks arbeitet man visuell, klickt sich durch Elemente, und die Klassen-Eingabe ist ein einfaches Textfeld. Die gesamte DX, die Tailwind so produktiv macht, fehlt.

Es gibt auch ein konzeptionelles Mismatch: Bricks bringt ein eigenes, mittlerweile mächtiges Styling-System mit (siehe Style Manager, Abschnitt 1). Wer Tailwind parallel nutzt, hat zwei Systeme, die um dieselben Concerns konkurrieren. Farben, Breakpoints, Spacing: Alles existiert doppelt und kann kollidieren.

Trotzdem gibt es einen validen Anwendungsfall: Teams, die bereits tief in Tailwind stecken und WordPress-Projekte ohne Umlernen umsetzen müssen, profitieren von Winden. Die Vertrautheit mit den Klassen und die Möglichkeit, dieselben Design Tokens projektübergreifend zu nutzen, kann die Lernkurve auf Null reduzieren. Für diesen spezifischen Fall ist Winden eine pragmatische Lösung.

7. DIY: Eigenes Framework mit AI und Bricks 2.2

Ansatz: Kein Framework kaufen, sondern mit Hilfe von AI (Claude Code, ChatGPT) und dem Bricks Style Manager ein eigenes, projektspezifisches CSS-System generieren.

Preis: 0 € (abgesehen von der eigenen Arbeitszeit und ggf. einem AI-Abo)

Warum das 2026 realistisch ist:

Drei Entwicklungen haben diese Option erst ermöglicht:

1. Bricks 2.2 Style Manager liefert die Infrastruktur. Der CSS Framework Importer frisst jedes CSS-File und sortiert es automatisch in Kategorien. Der Variable Manager, der Color Manager und die Scale-Generatoren stellen sicher, dass importierte Systeme sofort mit Autovervollständigung und Live Preview funktionieren.

2. AI kann ein konsistentes Variablen-System in Minuten generieren. Ein Prompt wie „Generiere mir ein CSS-Custom-Properties-System mit 6 Spacing-Stufen (fluid, clamp-basiert, 320px–1440px), einer Type Scale (1.25 ratio, 7 Stufen), einem Farbsystem mit Primary/Secondary/Neutral je 10 Schattierungen in OKLCH, und dazu BEM-kompatible Utility-Klassen für Spacing, Farben und Typography" produziert in einem Durchgang ein funktionales Grundgerüst. Nicht geschliffen, aber skalierbar.

3. Der Import-Workflow existiert. CSS generieren, in Bricks via Framework Importer laden, sofort arbeiten.

Realistischer Aufwand: Ein halber bis ein Tag für ein brauchbares Grundgerüst, plus ein weiterer Tag für Feinschliff und Testing. Das ist weniger als die Einarbeitungszeit in ACSS und kostet nichts außer der eigenen Zeit.

Welche CSS-Methodik?

Wer ein eigenes System baut, braucht eine Konvention für die Benennung. Die relevanten Optionen:

• BEM (Block Element Modifier) bleibt der sinnvollste Ansatz für Bricks-Projekte. .card, .card__title, .card--featured ist im Strukturbaum sofort lesbar, skaliert gut und wird von Template-Anbietern wie Bricksmaven konsequent eingesetzt. BEM funktioniert besonders gut in Kombination mit Bricks' Komponenten-System: Die Komponente ist der Block, die inneren Elemente sind die Elements, Varianten werden über Modifier gesteuert.

• CUBE CSS (Composition, Utility, Block, Exception) ist eine interessante Alternative für Teams, die Utility-Klassen und Custom-Komponenten kombinieren wollen. Die Composition-Schicht (Layout-Utilities) kommt aus dem Bricks Style Manager, die Block-Schicht nutzt BEM-artige Custom Classes. CUBE ist konzeptionell sauber, aber weniger verbreitet und schwerer zu dokumentieren.

• Reines Utility-First (Tailwind-Stil) ergibt im Builder-Kontext wenig Sinn (siehe Abschnitt 6).

• SMACSS und OOCSS sind eher historisch relevant und bringen im Page-Builder-Kontext keinen Mehrwert gegenüber BEM.

Meine Empfehlung: BEM als Basis, ergänzt um ein kleines Set an Utility-Klassen für häufig gebrauchte Spacing- und Typografie-Werte. Das ist die Kombination, die in Bricks am natürlichsten funktioniert und am einfachsten an neue Teammitglieder zu vermitteln ist.

Stärken:

• Maximale Kontrolle und Anpassung an den eigenen Workflow
• Keine Kosten, kein Vendor Lock-in, keine Plugin-Abhängigkeit
• AI-generierte Systeme können in Minuten iteriert und angepasst werden
• Ideal als Lernprojekt: Wer sein eigenes Framework baut, versteht CSS besser
• Kann schrittweise wachsen, ohne von Anfang an alle Eventualitäten abzudecken

Schwächen:

• Erfordert CSS-Wissen und die Disziplin, Konventionen einzuhalten
• Kein Support, keine Community, keine Tutorials
• Kein Ökosystem (keine kompatiblen Template-Libraries)
• AI-generiertes CSS muss reviewed und getestet werden
• Für Teams schwieriger zu standardisieren als ein etabliertes Framework
• Muss nachhaltig gepflegt und angepasst werden. Sowohl an die CSS Weiterentwicklung als auch an den Builder

Meine Einschätzung: Für Solo-Entwickler mit solidem CSS-Wissen ist ein AI-generiertes Framework auf Basis des Bricks Style Managers eine ernstzunehmende Option. Für Teams rate ich eher zu einem etablierten Framework (Core oder AT), weil die erzwungene Konvention wertvoller ist als die eingesparten Lizenzkosten.

Quantitativer Vergleich

OxyProps / BricksProps wurde entfernt, da das Projekt seit Ende 2024 keine Updates mehr erhält und als eingestellt gilt.

Qualitative Einordnung

1. „Bricks reicht" (Bricks Native, DIY): Seit Bricks 2.2 die stärkste Position. Der Style Manager liefert das technische Fundament. Die DIY-Option ergänzt das um ein AI-gestütztes, maßgeschneidertes System. Die Frage, ob ein Drittanbieter-Framework überhaupt noch nötig ist, wird in der Community aktiv und kontrovers diskutiert.

2. „All-in-One Workflow" (ACSS): ACSS definiert nicht nur ein CSS-System, sondern einen kompletten Workflow. ACSS bringt Dinge mit, die Bricks Native (noch) nicht kann: Convert-to-REM, Clickable Parent, SCSS-Mixins, das Frames-System. Allerdings: Mit Etch als eigenem Builder und dem nicht rückwärtskompatiblen v4-Update verschiebt sich der Fokus des Unternehmens. Wer ACSS für Bricks kauft, kauft zunehmend ein Nebenprodukt statt ein Kernprodukt.

3. „Visueller Baukasten" (Core Framework): Modularität, visuelle UI, Cross-Builder-Kompatibilität und CSS-Export machen Core zum Framework mit dem geringsten Lock-in. Das Bricks-Addon kostet ca. 119 € einmalig.

4. „Builder-Erweiterung mit Framework" (Advanced Themer): AT ist primär ein Builder-Enhancement-Plugin, das ein Framework als Bonus mitbringt. Für viele Bricks-Entwickler ist AT ohnehin installiert, und das AT Framework als leichtgewichtige Alternative wird zunehmend attraktiv.

Sonderfall Tailwind / Winden: Meiner Meinung nach nur für einen sehr spezifischen Anwendungsfall sinnvoll: Teams aus der Tailwind-Welt, die WordPress-Projekte umsetzen müssen.

Template- und Block-Ökosystem

Ein oft unterschätzter Faktor: Welche Drittanbieter-Templates und Block-Libraries sind mit dem gewählten Framework kompatibel?

• ACSS: Breiteste Unterstützung. Bricksmaven, BricksMade, Bricksfusion , Brixies und viele weitere bieten ACSS-kompatible Templates. Frames (von den ACSS-Machern) ist ein eigenes Wireframing-System.
• Core Framework: Wachsende Unterstützung durch BricksMade, Bricksfusion und den eigenen Marketplace.
• Advanced Themer: Unterstützung durch BricksMade und Bricksmaven, wachsend.
• Winden/Tailwind: Zugang zum riesigen Tailwind-Ökosystem (DaisyUI, Flowbite etc.), aber Integration in Bricks erfordert manuelle Anpassung.
• Bricks Native / DIY: Kompatibel mit allen Templates, die auf „Bricks Vanilla" basieren. BricksMade und Bricksfusion bieten diese Option explizit an.
• OxyProps: War nie breit unterstützt. Ökosystem nicht mehr existent.

Bricksfusion verdient eine besondere Erwähnung: Das Toolkit kann Sektionen automatisch zwischen ACSS, Core Framework, AT Framework und Bricks Vanilla konvertieren (ab 119 €/Jahr bzw. 279 € LTD). Wer sich heute für ein Framework entscheidet, kann mit Bricksfusion zumindest teilweise den Wechsel erleichtern.

Performance-Perspektive

Alle genannten Frameworks sind auf Performance ausgelegt. Trotzdem gibt es Unterschiede:

• Bricks Native & DIY: Minimaler Overhead, da kein zusätzliches Plugin geladen wird. Der Style Manager generiert reines CSS.
• ACSS: Kann zwischen Full-Utility-Modus und Ultra-Minimal-Variable-Modus umgeschaltet werden. Erfordert bewusste Konfiguration.
• Core Framework: Modularer Ansatz ermöglicht das Entfernen ungenutzter Module.
• Advanced Themer: Bewusst ohne JS-Framework-Abhängigkeit auf dem Frontend gebaut.
• Winden: JIT-kompiliertes Tailwind CSS, typischerweise unter 10 KB finales CSS. Allerdings: Tailwind erzeugt im Builder-Kontext tendenziell mehr Klassen pro Element als CSS-Variable-basierte Frameworks, was den HTML-Output aufbläht.

In der Praxis sind die Unterschiede bei gut konfigurierten Setups marginal. Der größte Performance-Killer ist selten das Framework, sondern die Art, wie es eingesetzt wird.

Vendor Lock-in: Was passiert, wenn das Framework verschwindet?

Eine berechtigte Sorge, und mit OxyProps kein hypothetisches Szenario mehr, sondern dokumentierte Realität.

• Bricks Native / DIY: Kein Risiko. Design Tokens sind Teil des Builders bzw. reines, exportierbares CSS.
• ACSS: Klassen und Variablen bleiben im HTML/CSS erhalten. Aber mit v4 steigt das Risiko: Wer auf v3 bleibt, bekommt keine neuen Features. Wer auf v4 migriert, muss mit Breaking Changes rechnen. Theoretisch kann man auch einfach nur das Stylesheet laden, aber es existiert kein Bakingfeature.
• Core Framework: CSS kann als Stylesheet exportiert werden. Das geringste Lock-in unter den Plugin-basierten Frameworks. Wenn besteht ein Verlustrisiko der Funktionalitäten im Builder.
• Advanced Themer: CSS-Variablen bleiben, aber das Plugin muss aktiv bleiben.
• Winden: Tailwind CSS ist ein etablierter Standard. Das generierte CSS funktioniert ohne Plugin.
• OxyProps (Warnung): Genau das Szenario, das alle fürchten. Projekt seit Ende 2024 faktisch eingestellt. Wer OxyProps noch im Einsatz hat, sollte zeitnah migrieren.

Fazit

Es gibt kein objektiv bestes CSS Framework für Bricks Builder. Es gibt nur das beste Framework für den eigenen Kontext.

Bricks Native hat mit dem Style Manager in Version 2.2 die Karten neu gemischt. Fluid Typography, Spacing Scales, ein mächtiger Color Manager mit Dark Mode und die Möglichkeit, eigene Utility-Klassen zu generieren: Vieles, wofür man noch vor einem Jahr ein Drittanbieter-Framework brauchte, liefert Bricks jetzt selbst. In Kombination mit AI-generierten CSS-Systemen und einer sauberen BEM-Konvention ist die DIY-Option 2026 kein Kompromiss mehr, sondern eine echte Alternative.

ACSS dominiert den Markt durch Umfang, Community und Ökosystem. Es bietet nach wie vor Features, die über das Bricks-Native-Angebot hinausgehen. Aber die strategische Verschiebung in Richtung Etch, der nicht rückwärtskompatible Sprung auf v4 und das Risiko unbezahlter Nacharbeit bei bestehenden Projekten machen ACSS zu einer Investition, die man mit offenen Augen tätigen sollte.

Core Framework bietet den besten Kompromiss aus Flexibilität, Preis und Cross-Builder-Support. Advanced Themer ist das beste Paket, wenn man die Builder-Erweiterungen mitdenkt. Tailwind via Winden bedient eine Nische, die ich für die meisten Bricks-Projekte nicht empfehlen würde.

Das Schicksal von OxyProps sollte als Mahnung dienen. Ein technisch elegantes Framework, das sang- und klanglos verschwunden ist. Wer heute ein Framework wählt, sollte immer auch fragen: Wie groß ist das Team dahinter? Wie nachhaltig ist das Geschäftsmodell? Was passiert mit meinen 50 Client-Sites, wenn morgen die Updates aufhören?

Die wichtigste Erkenntnis bleibt: Das Framework, das man konsequent nutzt und versteht, ist besser als das theoretisch überlegene, das nur halb eingesetzt wird.

Alle Preise wurden im April 2026 recherchiert und nach bestem Wissen umgerechnet. EUR-Umrechnung basiert auf ca. 1 USD ≈ 0,92 EUR. Nettopreise sind als solche gekennzeichnet. Bei Käufen aus Deutschland zzgl. 19 % USt., sofern nicht anders angegeben. Da sich Angebote ändern können, empfiehlt sich ein Blick auf die jeweiligen Websites vor dem Kauf.

Dieser Beitrag enthält keine Affiliate-Links.