Elementor V4 feels like an alpha build, not a production-ready editor

I genuinely wanted Elementor V4 to succeed. The ideas behind it are good. Atomic elements are the right direction. A class-first workflow is the right direction. Variables, components and proper design-system architecture are exactly what Elementor has needed for years.

The problem is not the vision.

The problem is the execution.

Right now, Elementor V4 feels less like a proper rebuild and more like an unfinished layer placed on top of an already fragile ecosystem. Instead of rebuilding the foundations cleanly, V4 often feels like V3 with another abstraction layer added on top: new styling systems, new UI patterns, new inheritance logic and new workflows all coexisting with older systems that still behave differently underneath.

The result is inconsistency everywhere.

The editor says one thing. The frontend shows another. Classes behave differently depending on context. Templates lose styling. Popups fail to load Atomic CSS properly. Dynamic content breaks inheritance. Responsive variants render differently between preview and frontend. V4 styles behave unpredictably inside V3 templates. Local classes, global classes and generated CSS still do not feel dependable enough for serious production work.

And this is not speculation. There are already dozens upon dozens of open GitHub reports covering exactly these problems:

• classes not rendering correctly,
• styles disappearing,
• frontend CSS not loading,
• dynamic content breaking styling,
• popup CSS missing,
• Template widgets ignoring Atomic styles,
• editor preview mismatches,
• custom fonts appearing only in the editor,
• settings randomly resetting,
• background styles refusing to save,
• custom CSS behaving inconsistently,
• controls clearing values unexpectedly,
• frontend rendering bugs across multiple widgets,
• and even excessive database writes related to the Atomic caching system itself.

These are not edge-case bugs.

These are foundational workflow problems.

The biggest issue is that Elementor V4 was presented as “production ready” while many workflows that existed in V3 for years are still missing, incomplete or unreliable.

Some examples:

• no Adobe Fonts integration,
• no proper HTML flexibility inside text widgets,
• missing layout capabilities,
• missing production-critical widgets,
• incomplete custom CSS workflows,
• no ability to properly save defaults for Atomic widgets,
• arbitrary class limits,
• inconsistent responsive controls,
• no proper grouping architecture for classes, variables or components,
• missing design-system management features,
• and continued dependence on workarounds for extremely common real-world scenarios.

This is what makes V4 feel unfinished.

The architecture itself is promising. In many ways, it is exactly where Elementor needed to go. But the surrounding ecosystem still feels like a prototype rather than a mature production builder.

One of the most frustrating parts is that V4 now requires significantly more technical knowledge while Elementor still markets itself primarily as an easy visual builder for everyone.

In V3, many users could realistically build and maintain websites with minimal CSS knowledge. V4 changes that completely. The entire workflow now revolves around classes, inheritance systems and design-system thinking. That is not necessarily bad — in fact, many developers prefer it — but Elementor cannot simultaneously position V4 as “simple drag and drop for everyone” while also pushing users toward a far more developer-oriented workflow.

At the moment, V4 sits awkwardly between two audiences:

• it is not stable or flexible enough for advanced developers,
• yet it is already becoming too complex for many casual users.

That is a dangerous position for a visual builder to be in.

The UX problems also become very obvious the moment you try building a real medium-sized website exclusively in V4.

Managing large numbers of classes, variables and components quickly becomes painful. Filtering alone is not enough. There is still no proper grouping system for:

• typography variables,
• spacing variables,
• colour systems,
• component collections,
• utility classes,
• or scalable information architecture.

Once you move beyond a simple landing page, the workflow starts feeling increasingly difficult to manage.

And then there are the arbitrary limits.

The 100-class limit especially feels disconnected from how modern scalable websites are actually built. Proper class architecture for large sites can easily exceed that. When artificial limitations appear inside systems specifically designed for scalability, it creates the impression that product restrictions are being prioritised over actual developer workflows.

The overall impression is that Elementor V4 was released far too early.

It currently feels much closer to a public beta — in some areas even an alpha — than a polished major release. The problem is not ambition. The ambition is good. The problem is that the product was positioned as the future of Elementor before the foundations were stable enough to support that claim.

And what makes this even more frustrating is the direction Elementor as a company appears to be taking.

Instead of fully stabilising the editor itself, more and more attention seems focused on AI tooling, hosting products, subscriptions, upsells, platform expansion and ecosystem monetisation. Meanwhile, many of the core editing workflows that professionals rely on daily still feel unfinished or unreliable.

Elementor built its reputation by making WordPress website building simpler, faster and more accessible.

That should still be the priority.

Right now, however, it often feels like the company is trying to become an all-in-one platform before fixing the core reliability issues inside its own builder.

The most valuable thing Elementor could do right now is simple:
pause the marketing for a moment and force every product manager, designer and developer internally to build a real client website using V4 exclusively.

Not a demo page.
Not a landing page.
A real production website with:

• dynamic content,
• templates,
• responsive layouts,
• loops,
• popups,
• components,
• global systems,
• WooCommerce,
• accessibility requirements,
• multilingual content,
• and realistic editing workflows.

The amount of friction, missing functionality, inconsistencies and workaround hunting would become immediately obvious.

Because that is where V4 currently struggles most:
not in demos,
but in real-world production use.

Elementor V4 still has enormous potential. The foundation itself is not the problem. In many ways, the Atomic approach is exactly the future Elementor needed.

But right now the execution feels unfinished, inconsistent and prematurely pushed into production.

Until the class system, frontend rendering, components, responsive controls, dynamic content support, custom CSS workflows, Theme Builder behaviour and third-party compatibility become significantly more stable, I cannot recommend V4 for serious production websites.

For now, I would strongly recommend continuing with the classic V3 workflow for client projects — or considering more mature alternatives such as Bricks Builder.

• This topic was modified 18 hours, 43 minutes ago by gestionwpraf.