5 WordPress page builders from a web developer's perspective 👎👎👎👎👎

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 when used together with popular themes like Impreza. I had to edit cryptic shortcodes in the source code editor and my customers could only reorder sections (rows) in the "backend editor" but not after clicking on "edit with WPBakery". What a mess!

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. WordPresss page builders can produce nice frontends at first sight, but they had a horrible developer experience when I had to use them in 2024 and it's hard to make their output accessible. 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.

Is this fine?

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 problems start

The problems start when small businesses 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 advantages are lost when we activate Full Site Editing.

Our theme's template parts and block patterns can be 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. 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 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. However, we can spot page builders without logging into a WordPress admin backend by looking for typical CSS class names in the page source code. A wp-block is most probably written by the WordPress block editor. Elementor adds 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.

We can 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 if you don't need to do anything beyond its intended scope.

WP Bakery is quite flexible but does not work properly – at least not in combination with the Impreza theme. 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, 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 developer 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 didn't understand it or 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 contains many posts about this error, but most 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: "fine", 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.

Many third-party themes and plugins don't work properly, and vendors refuse support except for logged-in customers. This allows them to hide what's wrong with their software and let developers fall into the same traps as their predecessors, while naive designers and project managers fall for their shiny ads and positive customer reviews. WordPress core and Gutenberg use honest open-source development, at least.

Avoid page builders if you are a developer!

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! (You probably don't!)

Isn't the block editor another page builder?

If you start a clean new theme from scratch, following the official WordPress core/Gutenberg guidelines, everything will work smoothly (or maybe it won't).

No wonder when the documentation sounds like ChatGPT wrote it:

Adhering to the create-block tool’s structure is not mandatory, but it serves as a reliable reference. The files it generates encompass everything needed for a block’s definition and registration. Following this structure can help maintain consistency and ensure your blocks are well-organized and easy to maintain.

When creating a block in a WordPress plugin, you usually register the block on the server in the main PHP file of the plugin. This is done using the register_block_type() function.

The build process provided by wp-scripts will take the files from this folder and generate the production-ready files in the project’s build folder.

The recommended way to add a custom block is creating a plugin with a React + Webpack project. But reading the manual and following the recommendations doesn't guarantee that it works, when relying on a framework that's still buggy.

Qutoing a support discussion on wordpress.org:

Follow the issue linked in the other topic ...
You may just have to wait a few more days until a fix is released.

I am not sure what fixed this issue but it is now solved, my custom blocks now appear in the editor.

Gutenberg's bug count

At least it's open-source software, but it looks like it's still in its beta phase or it has been released too early:

Gutenberg bug issues in 2024: 1927 open, 7334 closed.

Working with the WordPress block editor or any other page builder as a developer is still no fun in 2024, and maybe we should stop doing it and keep working in classic mode with custom post types and TinyMCE.

Pragmatism

We can use evergreen default blocks and block groups, add custom class names, and save our groups to block templates we and our customers can reuse when creating new pages.

One step further, but still without inadequate overhead, block variations are easy to find in the block inserter and can be equipped with child elements ("inner blocks"), custom properties and class names, and example content.

Gutenberg block variations without a build process

Customizing Gutenberg without React and Webpack is possible, pragmatic, and suitable for old-school developers who don't want their customers to miss out on the block editor's advantages.

Instead of creating custom blocks from scratch, we can define block variations with minimal code and use functions like wp.blocks.registerBlockVariation with plain vanilla (ES6) JavaScript.

As WordPress.org focuses on the official React/JSX way to customize Gutenberg, use Google and GitHub to find alternative tutorials and examples. I won't link any, as they're probably outdated when you read them. Apart from the (incomplete and opinionated) official WordPress docs, I recommend reading Carolina Nymark's fullsiteediting.com (in English) or Jessica Lyschik's Gutenberg-Fibel (in German).

Always strive for a clean and minimal solution generating valid HTML markup and plain vanilla CSS, so you don't get locked in a tooling ecosystem that might not work in future WordPress versions or alternative content management systems!