Here are some thoughts and experiences about page builders in WordPress: my subjective ranking and specific pros, cons, workarounds, and workflows. Abstract: Page builders suck, but Gutenberg (a.k.a. the Block Editor) is the most flexible alternative for developers, and Divi might be the most elegant for non-tech-savvy website owners. WP Bakery has the worst UI ever: apart from its ugly and outdated design and its broken page preview; some items can't be edited unless you use CSS or edit cryptic shortcodes in the source code editor.
Why use WordPress page builders at all?
From a web developer's perspective, all page builders share the same disadvantage: They strive for a "what you see is what you get" no-code approach, discouraging or preventing editing a page's source code. Page builder manufacturers claim that they "ensure that there is everything you need to create a website, blog, portfolio, or even a portal without touching a line of code." They even claim that users can "save time" using their software, although it has a learning curve and it takes about 10x longer trying to use their stuff compared to writing HTML and CSS. "Saving time" also means creating technical debt. Safely transferring code and content between development, staging, and production instances becomes more challenging if it's possible at all, and so does linting and code consistency. Using a page builder theme feels like using Microsoft Word or PowerPoint for layout and design, losing most advantages of modern CSS.
This might be fine for startups and hobbyists who want maximum flexibility without spending money on professional web development and who don't know HTML, CSS, and responsive web design.
The problem starts when small businesses start to scale and want to change and extend their websites step by step beyond the initial do-it-yourself approach. Developers should advise a relaunch with a proper (child) theme. We can still follow a hybrid approach and give website owners a lot of flexibility to edit their layout thanks to the Gutenberg block editor, but we can restrict that freedom and yield the benefits of code-based development: separation of concerns, testability, deployment and rollback, code reviews etc.
Full Site Editing is bad (but not the worst)!
However, many of those advantages are lost when we activate Full Site Editing.
Our theme's template parts and block patterns can get overwritten by alternative versions only available in a specific WordPress instance. Worse, even without Full Site Editing, the block editor's poorly documented JSON-in-HTML-comments syntax required inconsistent code formatting. So when you add a line break or omit a redundant parameter, you risk causing a "broken" block in the visual editor, even when the block still works in the theme's frontend.
Gutenberg: "This block contains unexpected or invalid content.
Attempt Block Recovery ..."
At least we can open a code view in the block editor to copy its output to a theme file, another page, or another WordPress instance. Other page builders, like Divi, hide their source code more consequentially. Gutenberg writes valid HTML source code at least, storing its metadata in HTML comments, so it won't appear when we change the theme or paste our content elsewhere. Gutenberg also has a hierarchical page structure view where you drag and drop elements without the need to locate them within the page preview and which allows you to understand the DOM structure and existing styles more easily without using your browser's developer tools.
Using 5 different WordPress page builders in 2024
I have shared my problems and workarounds with current WordPress technologies and extensions in several blog posts, so I don't need to repeat every detail here. A ranked listicle of page editors for WordPress in 2024 would only have negative numbers. I don't like any of them. But as far as I can see, Gutenberg is still one of the lesser evils, as I have to say, after trying to work with Elementor and Divi. Bakery, Divi, and Elementor seem to have a lot in common. They are more restricted but also more stable and mature than Gutenberg, which still has many issues in 2024.
Maybe we don't want to ask a potential customer if their legacy content has been built using a page builder. But we can spot page builders without logging into a WordPress admin backend by looking for typical CSS class names used in the page source code. A wp-block is most probably written by the WordPress block editor. Elementor add an elementor-element class name to nearly every DIV element and Bakery chose wpb_ as its prefix. Divi uses the et_pb prefix to identify as the Elegant Themes' page builder, Bakery writes quite nondescript wpb_ and w- prefixes like w-vwrapper.
| page builder | notorious issue | telltale class |
|---|---|---|
| Gutenberg/FSE | Block Recovery destroys custom code. | wp-block |
| Divi | "Your Save Has Failed" = lost all unsaved changes. | et_pb |
| Elementor | Existing elements became deprecated. | elementor-element |
| Bakery | Saving styles destroys the whole page preview. | wpb_ |
| Semplice | Nice, but not enough flexibility. | mejs-semplice-ui |
We can possibly add more items to the bottom of the list. The more specific and restricted no-code solutions become, the harder it gets for web developers to get their work done. Semplice is just one example of a specialized page builder that can do a great job, but only as long as you don't need to do anything beyond its intended scope.
WP Bakery is quite flexible, it's used by meta builders like Impreza and integrates with WordPress' Gutenberg block editor. If it would only work and update its preview properly, but it doesn't - at least not in combination with the Impreza theme. They can produce nice frontends but had a horrible developer experience when I had to use them in 2024. Divi looked nicer and more modern, but both page builders are surprisingly restricted if you need to edit or extend their markup, like adding an intermediate wrapper element. WordPress' new built-in page builder, "(web)site editing", also known as "full site editing" was a half-baked mess when I last tried to use it and the backend UI in wp-admin kept changing. Biggest and most unintuitive con: although you can define templates and template parts in your theme code, that only serves as an initial status that will get overridden in the database without any official way to synchronize the diff.
Elementor vs. Divi: which one is worse?
Still, I put Elementor and Divi below WordPress core in my list. Why? First, I prefer necessary features to be part of free and open source software, not maintained by third-party vendors. Second, the block editor tries to emit some semantic markup, even more so if we define our own blocks or reusable block groups.
Elementor and Divi both suffer from "divitis"
Divi mostly does what its name suggests: creating div elements and using class names for structure and styling. Elementor's markup is even worse in a way, as there are individual class names for each element, like "elementor-element-587b5fd", used for adding individual styles. Elementor even writes extra style blocks in the document body. But then again, Gutenberg writes inline styles. I could randomly reorder my list every day or based on my most recent frustration.
I found out that some unhelpful mobile styles weren't legacy code written by the previous web dev, but rather defaults hard-coded in the Divi theme. At least I was able to override them in the editor UI, but it still felt like working against another developer's concept because I don't understand it or I don't agree with it.
If we want or have to use page builders, we should try to use them in their intended way if we can. But if we add custom styles and markup, we should understand what's going on and find a way to make our customizations as robust as possible without breaking anything else. And of course we should not take their editor for granted.
Divi: "Your Save Has Failed"
Divi failed to save a page modification on localhost on the same instance that used to work fine one day before. The error description was neither helpful nor specific. It didn't even look like an error message. The web is full of posts about this error, but most of them just rephrase the original message. So, I end up debugging third-party code instead of doing web development.
To be fair, Divi seems to work stable, at least when we take small steps and save our work often.
Conclusion: not bad, but bad for devs 👎👎👎👎👎
Page builders can be a great tool for small(er) website owners, but they suck if we have to use them as web developers. We don't control the markup, and we can only guess what's happening under the hood and if our clever custom CSS will still work when the maintainers decide to switch their layout from flex to grid in an upcoming update.
Page builders include ready-made solutions with a shallow learning curve for their intended use cases. You can add a parallax effect without understanding what it is. You can use semitransparent gradients without learning their CSS syntax.
But sooner or later, you will experience the exact opposite: Some seemingly simple styles will seem impossible unless you place a dirty workaround in the global customizer styles or scripts after giving up on finding the correct way to do it using only the official UI. You might discover that using an uploaded image with a semitransparent gradient overlay and the built-in parallax effect breaks your layout in specific browsers or screen sizes. You might notice that some of your divider images don't appear in Firefox.
Above: another example of an obscure bug in third-party code.
WordPress Page builder projects often feel like one step forward, three steps back to me as a web developer. They're helpful for some people but stand in the way of web developers who prefer to code. If a client asks you to maintain their legacy website, ask who did it before and why they're not in charge anymore. Think twice if you really want to do it!
Top comments (1)
P.S. don't paste formatted rich text into a page builder directly, it may contain hidden metadata that you don't want to expose and that clutters the exported markup even more.
This was pasted from Figma to Divi:
... and it was so long that I even noticed it in the browser.