Why Bricks, Builderius and Etch solve the right problem at the wrong level

For decades, there was a language barrier on the web. On one side: human intent. On the other: machine code. In between: years of learning effort, specialized craftsmanship, expensive developers. Anyone who didn't have one of these three things needed a translation layer. That's how page builders came to be.

This translation layer is currently disappearing. Not through better builders. But because the language itself is becoming accessible.

Natural language is the new brush for the web. Anyone who today types "build me a responsive product page with hero, features and CTA" into a language model gets production-ready code. No drag-and-drop. No panel configuration. No proprietary intermediate format. The barrier between intent and result is collapsing.

In this context, we look at Bricks Builder, Builderius and Etch in the WordPress world. Not as an answer to this shift, but as a consequence of an insight that emerged before it: that classic WordPress builders are structurally broken. That's true. And it still isn't enough.

Theme builders, not page builders: a difference that matters

A new category of tools has learned from the mistakes of the first generation of page builders. Bricks Builder, Builderius and Etch have made a design decision that Elementor never made: to treat HTML output as a primary quality metric, not as a byproduct.

Before the technical consequences are discussed, a distinction must be made that is missing from most builder debates.

Elementor is primarily a page builder. It is deployed on an existing WordPress theme and controls the content of individual pages. Header, footer, template hierarchy remain largely outside its control.

Bricks, Builderius and Etch are theme builders. They control the entire site architecture: global templates, header, footer, archive pages, single post templates, custom post type templates. A theme builder that takes code quality seriously can keep the entire site consistently clean. A page builder like Elementor can only ever be as good as the theme code in which it is embedded.

What clean code means in the AI context

AI models were trained on web standards: HTML, CSS, JavaScript. The closer a system stays to these standards, the better an AI can work with it. Kevin Geary, the developer behind Etch, has put it directly: AI knows HTML, CSS and JavaScript. It doesn't know builder syntax.

This is the crucial structural advantage of these theme builders over Elementor, and it has nothing to do with AI features in the builder. It lies in the basic architecture.

But it has a hard limit. Clean HTML output doesn't mean the data layer underneath is clean. And the data layer is the real problem.

What no builder generation can fix: the foundation

Here lies the core that neither Elementor nor Bricks nor Etch can solve.

WordPress was designed in 2003. The database schema is designed for a world without cloud-native architecture, without serverless, without AI-native workflows.

WordPress performs between 20 and 100 database queries per page view depending on the page type. The wp_postmeta table, where builder layouts, custom fields and plugin settings are stored as key-value pairs, is one of the most common performance bottlenecks on complex sites. The wp_options table loads autoload data on every request, regardless of whether this data is needed on the current page. WordPress plugins run in the same execution context as WordPress Core, without sandbox, without permission model: 96% of all security problems on WordPress sites originate in plugins (Cloudflare, 2026).

Elementor cannot change these characteristics. Bricks cannot change them. Etch cannot change them. The second builder generation builds cleaner code on the same foundation. That's real progress. It's not a way out.

And AI? The common pattern: All three theme builders have clean code output, but their AI strategies currently treat the same basic question as an Elementor: How do I get AI to navigate through WordPress structures? The answer to this question is structurally less efficient than the alternative of letting AI work directly on web standards.

Who still needs a visual interface for development?

Here lies a shift that should be stated more directly than the builder industry does.

A visual development interface had two functions. First: help developers prototype and iterate faster. Second: enable non-developers to work without code.

AI fundamentally changes both functions.

For developers, the visual interface of the theme builder is increasingly optional. Anyone who today works in tools like Cursor or with Claude Code has a coding partner that understands template hierarchies, builds component-based architecture and performs iterations in minutes. The UI of a builder is a detour in this workflow, not an advantage. Etch explicitly markets itself as a Cursor-like experience. The more honest question is: If Cursor is already Cursor, why then Etch?

What remains is the second function: content maintenance by editors, marketing teams, non-developers. This group needs an interface. But they don't need a development interface. They need a clean CMS interface for content tasks.

The most sensible division of modern workflows is not "which builder", but the separation of two tasks that builders have artificially united: development via AI-direct code on web standards, content maintenance via a lean CMS interface.

EmDash: When the question itself is restated

On April 1, 2026, Cloudflare announced EmDash. It's not an April Fool's joke. And it illustrates the argument of this article better than any theoretical example could.

Cloudflare didn't improve WordPress. Cloudflare omitted WordPress and rebuilt it. EmDash is completely written in TypeScript, built on Astro, designed serverless and created without a single line of WordPress code. One engineer, two months, intensive use of AI coding agents.

The architecture decisions are consistent: Every plugin runs in an isolated sandbox with explicitly declared permissions, AI-native designed with Agent Skills, CLI and built-in MCP server.

What's practically relevant is where the lock-in actually lies: EmDash can already import WordPress content today, posts, pages, media. What is not portable are builder abstractions. Elementor layouts, Bricks templates, Divi shortcodes: these layers stay behind. The content is free. The abstraction layer is the lock-in.

Matt Mullenweg has described EmDash as "very solid" with "some excellent engineering", the Agent Skills as "amazing" and "a brilliant strategy", and conceded that Automattic must develop something comparable (CMSWire, 2026). That's not a rejection. That's confirmation of the direction by the man who leads WordPress. Even if he also used other words.

EmDash is v0.1.0, without plugin community and themes marketplace. For the majority of today's WordPress users, it is not yet a valid alternative.

But EmDash is not a product for today. It is a signal about the direction. An infrastructure company has classified WordPress as an architecture problem that can be solved more efficiently through rebuilding than through iterative improvement, and has proven this in two months.

Consequences

Elementor and Divi have delivered real added value for a decade. Millions of people have built websites that they couldn't have built without these tools. That's real.

Bricks and Etch have learned from the mistakes of the first generation. Their code is cleaner, their architecture is deeper, their AI compatibility is higher. For professional WordPress developers who have to make decisions today, they are the more reasonable choice.

But the more important decision is "WordPress, yes or no", not "which builder". Headless WordPress with Astro or Next.js, direct framework-based development with AI-direct code, or EmDash in the medium term: These options belong on the evaluation table.

Bricks and Etch expertise has a real market today. That's not an argument against building these skills. It's an argument for starting the path to framework-based, AI-direct development in parallel.

Conclusion

The language barrier between humans and computers was the actual reason for all builder generations. Elementor lowered this barrier the wrong way: with proprietary formats, bloated code, broken abstractions. Bricks and Etch have done it better, with clean HTML, clear architecture, deep site control.

What none of these generations can change: The barrier itself is disappearing. Not through better builders, but because natural language is becoming the direct interface between human intent and machine code. AI translates without proprietary intermediate formats, without visual detours, based on web standards that have been documented for decades.

Two generations of WordPress builders. The same structural question. An answer that has not yet been fully given by either.

 


Sources: