WordPress Page Builders, Reviewed: Beaver Builder, Divi Builder, WPBakery Page Builder, Elementor
This article reviews four prominent WordPress page builder solutions: WPBakery Page Builder, Divi Builder, Beaver Builder, and Elementor.
This article reviews four very prominent WordPress page builder solutions: WPBakery Page Builder (formerly Visual Composer), Divi Builder, Beaver Builder, and Elementor.
To start off, if you simply want to know our recommendation for the best WordPress page builder, here it is:
Best WordPress Page BuilderReliability is everything in a page builder, and Beaver Builder is the most technically solid of the major options.
Good WordPress Page Builders: Now a Thing
Before about three years ago, all WordPress page builders were so bad that I refused to use them. I carried this bias for a while, but eventually I took a second look and found that WordPress page builder solutions are getting good, and are now the correct choice—more than widgetized homepages, column shortcodes, page template custom fields, and other half-measures—for getting layouts into your WordPress content.
However, when I wrote that “WordPress page builders are getting good,” I specifically meant one page builder: Beaver Builder, the first builder that I ever found to be a help and not a burden. I’d worked with both the Divi Builder and the WPBakery Page Builder (previously called Visual Composer) through numerous clients who’d installed them on their own sites, and I found that both builders reliably made doing good work almost impossible.
So, how is it now? Are WordPress’s other largest, best-selling page builders improving in quality too? How is Beaver Builder doing today? What’s up with Elementor? Let’s find out in our review and comparison of Beaver Builder, Elementor, Divi Builder, and WPBakery Page Builder.
Why You Can Trust Me on WordPress Page Builder Solutions
Before we get rolling, here’s a quick personal introduction, why you should trust me, and full disclosure.
Hi! I’m Fred Meyer. I’ve been writing about WordPress nearly every week for five years here on WPShout. I’m also co-founder of boutique web agency Press Up, where my day job is making WordPress websites for people, especially small businesses.
Getting an accurate picture of any paid-for digital product can be notoriously difficult, because reviews are often informed by whichever company pays out the biggest commissions. The four products we review here are reviewed on the basis of being the largest and best-known builders in WordPress. All four have affiliate programs, so links to each of those products, including those we do not recommend, are affiliate links. The content of this article has not been affected in any way by affiliate payout comparisons (as I write this, I have no idea which affiliate program pays out what), as the substance and thoroughness of the content itself should clearly demonstrate.
This WordPress page builder comparison review was not commissioned by or edited by any third party, and is the product of my experience as a professional WordPress developer who both works with and writes about WordPress every day.
- Executive Summary
- Divi Builder Review
- WPBakery Page Builder (Formerly Visual Composer) Review
- Beaver Builder Review
- Elementor Review
- Additional Thoughts
Beaver Builder vs. Elementor vs. Divi Builder vs. WPBakery Page Builder: Which WordPress Page Builder to Use
Here’s the executive summary.
Beaver Builder Review Summary
Beaver Builder is the only WordPress page builder you’ll ever need. Of the four builders reviewed, it’s one of only two (Elementor being the second) that helps, rather than hinders, a WordPress developer’s work.
I enthusiastically recommend Beaver Builder, and I use it as an indispensable tool in my day-to-day development work. It continues to redefine upward what WordPress development can be, and I urge you to try it now:
Elementor Review Summary
Elementor is extremely ambitious and very high-quality overall. It’s arguably the most feature-rich of the four builders, and only some slight UI quibbles and a bit of bugginess at the edges keep it from being my first choice.
I recommend Elementor for anyone who wants a lot of very high-quality layout elements and innovative features, and can tolerate a slightly less rock-solid builder than the sturdier but blander Beaver Builder:
Divi Builder Review Summary
Divi Builder has some flashy and downright cool UI innovations, but because its technical core is shaky it ultimately gets in the way rather than helping.
I don’t recommend Divi Builder, but I don’t think using it is necessarily an enormous mistake—you’ll get some very cool functionality, but you’ll lose a fair amount of control over how your final product comes out. If you do want to try it out, then:
WPBakery Page Builder Review Summary
WPBakery Page Builder is a burning train wreck of elaborately broken features, bafflingly careless UI decisions, and astonishingly fragile hacks. It makes simple tasks difficult; difficult tasks hellishly frustrating; and good, thoughtful WordPress development a literal impossibility. I beg you to stay as far away from it as possible, and hope that you’ll tell everyone you meet to do the same.
I’m serious, don’t do this, but:
Brief Explanation of the Results
This review confirmed that relatively little has changed in terms of quality among the three most prominent page builders in WordPress that I’d previously used extensively. Of the three, Beaver Builder is still the only one that I would ever use—and, in fact, do use, on almost every WordPress project I work on.
Beaver Builder’s and Elementor’s biggest advantage over Divi Builder and WPBakery Page Builder is simply that they don’t get in the way of the precise, accurate work that a developer needs to do.
Beaver Builder’s and Elementor’s biggest advantage over Divi Builder and WPBakery Page Builder is simply that they don’t get in the way of the precise, accurate work that a developer needs to do to get a site actually displaying and working properly. By default, a given page builder is just one more piece of bad third-party software in a WordPress developer’s way—but Beaver Builder and Elementor are actually an aid, not an impediment.
The other two plugins simply can’t say the same. Although Divi Builder has some real strengths (WPBakery Page Builder honestly doesn’t), both are still, fundamentally, in the way.
The various ways in which both Divi Builder and WPBakery Page Builder hamper a developer’s ability to work are the key reasons why I would never use either page builder myself. They include:
- Dumping huge amounts of hard-to-override CSS onto the page.
- Hiding real layout elements (margins, padding, max-width) in favor of abstract ideas like “Buffers” and “Stretch” that may appeal to nontechnical people but make working with precision impossible.
- Hardcoding important layout decisions into their modules, such as the number of columns in an image gallery.
- Generating serious bugs that take developer time to fix, such as introducing layout errors on the live site that disappear in the builder view, or causing pages to develop horizontal scroll bars.
- Making page content fragile, buggy, and forever tied to the page builder itself by wrapping it in dozens of nested shortcodes.
Both Divi Builder and WPBakery Page Builder are guilty of each of these problems. Beaver Builder, by contrast—and please understand this as the miracle it is, because page builders are hard to write—is guilty of none of them, and is instead actually an aid to a serious WordPress developer who needs a robust, powerful way to create layouts. Elementor is ever-so-slightly more fragile, but not enough to push it into “unusable” territory—and its powerful feature set is arguably worth the tradeoff.
Beaver Builder is an enthusiastic yes. Elementor is a cheerful sure! Divi Builder is a thoughtful, reflective no. WPBakery Page Builder is NOPE through a megaphone.
But that doesn’t mean that Divi Builder and WPBakery Page Builder are created equal. Divi Builder is quite good at what it’s good at: appealing to nontechnical people while sweeping technical messiness under the rug. WPBakery Page Builder is elaborately bad at everything, except, seemingly, at making sales. Beaver Builder is an enthusiastic yes. Elementor is a cheerful sure! Divi Builder is a thoughtful, reflective no. WPBakery Page Builder is NOPE through a megaphone.
Methodology: How We Reviewed the Builders
Rather than looking at the builders’ prices, page load speeds (which was recently done well), PHP version compatibility, and so on, we wanted to see what it’s like to try to do WordPress development with each builder.
In other words, this article asks: How are these page builders to actually use?
The Main Task: Copy a Real-Life Landing Page
To me, the best test of a WordPress page builder is whether it can efficiently create real-life page layouts—especially for homepages and landing pages, the most layout-intensive parts of most WordPress sites.
For the main task of this review, I chose an existing homepage/landing page to copy: the relatively simple, center-of-the-road landing page of Tile, a startup for finding lost items that I’ve used and liked in the past. To be specific, I set to work copying the first half of that page, as that was more than enough to get a feel for each builder:
To look only at the capabilities of the page builder plugins themselves, and not at how they interact with the specifics of any particular theme, I did my landing page demos on a test site running a clean, default, no-customizations version of the WordPress starter theme Understrap, on a blank page using the theme’s “Empty” page template.
There’s nothing unusual going on on the Tile homepage, but there are lots of standard page builder-y layout elements: a full-width slider, boxed text content, a video embed, and so on. Building toward implementing this template is the general “project” that I put each page builder to work on.
Front-End Editors Only
We’re only using the front-end component of each builder, because it’s a massively better experience: WYSIWYG versus nothing of the sort. Having a good front-end editing experience is what being a “good WordPress page builder” means in 2018. (See our discussion of where Gutenberg would fit on this list for more on the topic.)
Plugin Versions Used
We based this review off the lates commercially available version of each plugin, which at publication was:
- Beaver Builder Standard 188.8.131.52
- Elementor 2.0.8, Elementor Pro 2.0.3
- Divi Builder 2.0.68
- WPBakery Page Builder 5.4.7
We’ll update this review as major changes come out, but one thing we’ve learned through the review itself is that most page builders’ overall quality is relatively steady over time, because both their core technical choices and their strategic, philosophical, and marketing foundations are relatively static.
So I’d say don’t worry too much about version changes in this review, unless you’re either aware of really earth-shattering changes to one or another builder, or are reading this after about October 2020 and I haven’t come back in and changed that date to a new one.
Gravity Forms Embed
I wanted to test how each page builder worked with a well-supported, well-coded third-party plugin. I used each builder to add a Gravity Forms form onto the landing page, either through the builder’s own methods or using a shortcode. The main question is how similar it looks to the no-page-builder default:
Restrict Content Pro
As an admirer of Pippin Williamson’s excellent 2016 survey of WordPress page builder solutions, I wanted to investigate two specific technical issues he brought up. The first is a shortcode that spans multiple page builder elements. The example I used is
[not_logged_in], a shortcode from Pippin’s own Restrict Content Pro.
The question is: can the page builder have standalone elements inside, and therefore separating, the
[/not_logged_in] shortcode tags? Builders often struggle with this if they themselves use shortcodes for layouts—which is a bit of a spoiler alert if you know how Divi Builder or WPBakery Page Builder mark up their post content.
Also following Pippin, I wanted to test whether each builder would incorporate a
the_content filter properly. I wrote a very simple plugin to filter the text “Problem String” to instead return “Filtered String” and tested whether the filter came through on each page builder.
Screen-Capture GIFs, Screen-Capture GIFs Everywhere
For this article, it felt important to be able to show, not tell, the various interface features and bugs I found in these page builders.
Three 90-minute YouTube “Builder Review” videos was feeling likely to be unwatchable, so I’ve broken out interesting moments for all four builders into screen-capture GIFs. I’ve set them to load once you click on them, so that this page isn’t 200MB of data all at once.
If you can play this GIF, you should be good on the rest:
I’m hoping this approach will give you real visibility into exactly what I’m talking about when I praise or criticize an aspect of a builder.
Let’s get into the reviews!
Divi Builder Review: “Elegant” in Places, but Missing Fundamentals
Divi Builder is significantly better than I expected, but it’s still stunted by Elegant Themes’ usual focus on style over substance.
I’ve had a lot of bad experiences with client websites that use Divi, the theme that is the Divi Builder’s native home. I’ve also have a lot of bad experiences with everything ever created by Elegant Themes. I find, across the board, that its products look really shiny and attractive until you try to use them, like a brightly painted sports car shell that turns out to have no doors (you climb in through the window), no seats (you squat in place), and an electric engine that only runs on an extension cord.
Overall, Divi Builder is significantly better than I expected, but it’s still stunted by Elegant Themes’ usual laser focus on style and consumer perception over substance. If I squint, I can almost see using the Divi Builder myself, for some of its genuinely cool features—but then I look at the details, and it’s out of the question.
Let’s examine those details.
Divi Builder: The Good
Awesome Inline Text Editing
Front-End Wireframe Mode
I think the Divi Builder’s “wireframe mode” is a nice development out of its origins as a back-end builder. You can click to enter “wireframe mode,” and work with and manipulate the section-row-column-element structure of the page directly—all while staying on the front end and without page refreshes. Leaving takes you back to a live-previewing front-end view of the page:
Generally Clean, Helpful Design
These minor issues aside, the Divi front-end builder is, in my opinion, laid out effectively and efficiently and makes good use of the screen real estate. It’s generally clear where things are, what they do, and how to use them.
Divi Builder: The Bad
Slow and Frequent Redrawing
This was not only an issue on page load. In the demo below, cancelling (rather than saving) changes to the text field leads the Gravity Forms embed to redraw itself for some reason, and it takes a long time—maybe three or four seconds—to render.
Very Obtrusive CSS Style Overrides
The first area that makes the Divi Builder really unusable is its overwhelming application of CSS styles to elements on the page. I first noticed this when I applied a Gravity Forms form through a shortcode, and saw the input fields shrinking to comically small proportions:
The issue is that Gravity Forms itself wants to tell these inputs to have sensible widths—100% by default—but all Gravity Forms’ own styles are being overwritten by absolutely enormous Divi Builder style declarations. In this case, the Divi Builder sets the inputs’ width to auto, which it intends as a sensible default of its own but which shrinks the form fields to almost nothing.
You may not realize how big a problem the Divi Builder’s overbearing CSS rules are until you contemplate doing the work yourself to fix them.
You may not realize how big a problem this is until you contemplate doing the work yourself to fix the overbearing CSS style rules of your own page builder—rules whose list of targeted HTML selectors easily run to dozens of lines. Do you want to use any third-party resource that has an opinion on how it should be styled? A business listing plugin might be an example.
Uh-oh: its styles are randomly overwritten by a torrent of Divi styles, each targeting dozens of CSS selector combinations more or less at random. Good luck rewriting the listing plugin’s own CSS rules—as you run, one by one, into the places where they’re not working—using selectors verbose enough to overwrite the Divi Builder’s.
This problem cropped right back up, for similar reasons, when I tried a WooCommerce “products” widget:
I guarantee that I didn’t want my list of products to have the Divi Builder’s thoughtful(?) default width of 20.875%. Now I’ve got quite a bit of CSS to write just to be able to reimpose my own design ideas (or even WooCommerce’s) onto Divi’s avalanche of overrides.
This issue, by itself, is easily enough to turn an entire website project into an ordeal.
From experience on numerous client projects involving the Divi Builder, WPBakery/Visual Composer, and similar builders, I can say the following: this issue, by itself, is easily enough to turn an entire website project into an ordeal. It’s a massive argument against using the Divi Builder for anyone who needs website projects done right—“right” here being as modest as “my products widget isn’t 20.875% wide for reasons I have no control over.”
Flashy Design Options with Missing Fundamentals
A number of times in testing the Divi Builder, I found myself wowed by its design options. For example, Divi’s Gallery feature lets you do on-the-fly Instagram-style tweaking of things like the hue and saturation of your gallery images:
After several minutes of looking, though, I realized you can’t change something extremely basic: how many columns the gallery is laid out into! Divi has decided there will be four images per row, and there’s no option to change that.
There’s also no option to change which size of image the gallery uses. You can’t make a gallery of thumbnails (which are square), or of any other specially registered image dimension you might need on your project. The five gallery images I’ve chosen have ragged bottom borders, since the images have different underlying dimensions—and there’s no way to do anything about that other than manually cropping the images in something like Photoshop.
I can count on zero hands the number of times I’ve needed to box-shadow an entire gallery while putting strikethroughs in its captions and sepia-toning the images themselves—all of which are options in the Gallery module. However, as a developer I’m certainly going to need to lay elements out the way I want them pretty much every time, and that includes getting to dictate whether a gallery is a four-column display of large images or a tightly packed thumbnail grid.
As another example, the Divi Builder’s “gutters” implementation is flashy and presumably appealing to nontechnical people—but it’s a big question mark for developers and other precision-minded people who need spaces between elements to be in pixels,
rems, or other technical units, not unitless chunks:
Despite its apparent ease of use, this feature, like several others like it in the Divi Builder, has the effect of making precision significantly harder to achieve by creating user-facing layout options that aren’t the way you actually control layout. If I want columns to have
The dark design flaw at the heart of the Divi Builder is that it’s based in shortcodes. You can see this clearly if you deactivate the builder, which results in the Fallback to Shortcode Devastation that you’ll be familiar with if you’ve worked on a few or more WordPress client projects that used builders like the Divi Builder or Visual Composer:
Divi Builder Review: Summing Up
Divi Builder’s issues are only visible once you try to apply the software to real purposes and projects.
As I’ve mentioned, the Divi Builder’s user interface is more usable and sanely coded than I’d expected, and even had some wow moments I wasn’t expecting.
With Divi Builder (as, candidly, with all Elegant Themes products I’ve tried), the real issues are only visible underneath the surface, once you start to try to apply the software to real purposes and projects.
So with the Divi Builder, the devil is in the details, not in the superficial presentation. One major issue is the torrent of CSS styles the plugin brings with it, and how those styles’ syntax leads them to override the helpful and necessary styles that other elements bring with them. Another is the lack of full control over various elements of layout and presentation—the folksy unitless “gutter” value, the automatic four-column gallery layouts, and more. A third is the inherent fragility of the Divi Builder’s use of shortcodes as the basic unit of layout.
My overall experience with the Divi Builder was unexpectedly, pleasantly lukewarm—but I certainly can’t think of a situation in which I would use it.
I can’t really say that the Divi Builder is something that you only use if you’re insane or badly misinformed—which I’ll happily say (shout, even) about the WPBakery Page Builder. Given my uniformly dark history with numerous Divi-based website projects, and with all Elegant Themes products in general, my overall experience with the Divi Builder was unexpectedly, pleasantly lukewarm.
But I also certainly can’t think of a situation in which I myself would use the Divi Builder, putting myself at the mercy of its fragile, random, and difficult-to-fix technical missteps. This is especially true given how much better Beaver Builder is in almost every single way.
WPBakery Page Builder Review: This is All Wrong
I’ve worked with WPBakery Page Builder (previously called Visual Composer) on numerous client sites, and I’ve absolutely hated the experience every time. Coming into this review, I definitely had one eyebrow pre-arched.
I knew it was possible, though, that the underlying software is actually decent, but it’s been getting embedded in horribly coded themes by people who don’t want to pay a developer until they’ve already broken everything themselves—which is, after all, WPBakery’s target market. So I was curious to look at the page builder plugin itself in detail, alone and with fresh eyes.
WPBakery Page Builder is either badly designed or broken at almost every level imaginable.
Welp, I understand the problem now. WPBakery Page Builder is badly designed, broken, or both at almost every level imaginable. As you read the review below, please keep in mind that the details I pick out to criticize are more examples to convey an overall environment in which nothing works properly, rather than a concrete list of specific complaints about an overall-decent piece of software.
WPBakery Page Builder: The Good
Nice Gesture Toward Mobile-First Inheritance
I like WPBakery’s way of dictating responsive behavior where the default is that things inherit their properties from the next smallest size. This dovetails nicely with the idea of “mobile-first” development, which assumes people are on a phone, and changes things as devices get larger, rather than vice-versa.
Because of its market power, WPBakery Page Builder has integrations with almost any sizeable plugin on the market. Below is a niceish integration with Gravity Forms that beats the shortcode embed I ended up doing in Divi Builder:
WPBakery Page Builder: The Bad
Slow and Labor-Intensive
Watch me try to save a change in WPBakery Page Builder:
- The one-second or so pause after I set the background image, before it fills in the empty gray square.
- How my changes will not live-preview without me clicking “Save changes,” and the moderate pause even after the button click.
- The three-second or so pause after I click “Update” before the green save bar gradually filters in.
- The final one-second or so pause when I click to exit the builder.
The most serious source of UI drag is the clunky, awkward, everything-by-hand previewing and updating process.
However, the most serious single source of UI drag is not slow, bulky code, but rather the clunky, awkward, everything-by-hand previewing and updating process. In the WPBakery page builder, absolutely nothing—changes to content, formatting, or layout, changes to modules, rows, or pages—live-previews or live-updates. You have to push everything through yourself with a button press (or more than one), and wait anywhere from one to several seconds for an updated version to come back. This gives the entire user experience a draining, laborious, rotary-telephone feel.
Using the WPBakery Page Builder feels like trying to run underwater.
The sum of this and numerous other UI slowdowns is that using the WPBakery Page Builder feels like trying to run underwater.
Awkward, Unintuitive, and Clunky
The WPBakery page builder is not just slow, it’s also awkward and unintuitive on almost every level imaginable.
Using the WPBakery page builder, I frequently feel annoyed and hemmed-in in a way that is very different from all of the other builders reviewed.
Using the WPBakery Page Builder, I frequently feel annoyed and hemmed-in in a way that is very different from Divi Builder, Beaver Builder, and Elementor, all of which have invested strongly in intuitive, coordinated user interfaces. I feel like I’m using MS Word ’95.
Let’s take another example of bad UI: in WPBakery’s (mostly rather sensible) “Image Gallery” module, you have a chance to choose image sizes for your gallery images. How do you choose? A dropdown of available image sizes, right?
Yes, it’s a text field, for you to type in the slug-ized name of the image size you’re looking for—that is, assuming you know what image sizes are registered in your theme, and how to use WordPress’s slug conventions for size names like “Medium Large.”
Of course, since WordPress’s existing PHP functions make it easy to access a list of registered image sizes, the choice to make this a text field rather than a dropdown of size options is as nonsensical as a “Date of Birth” field that expects a MIDI file. By itself, this single design choice won’t break anything (unless the user typos), but the accumulated weight of it and dozens of similarly careless choices make the WPBakery page builder a gnat swarm of frustration even in those instances in which it technically “works.”
Speaking of which:
Everything Is Broken
To use WPBakery Page Builder is to immediately invite baffling bugs and errors into your workflow and website.
To use WPBakery Page Builder is to immediately invite baffling bugs and errors into your workflow and website—even an environment as clean as, in this case, a stock, customization-free starter theme and no other running plugins.
The first thing I noticed was that my page developed a horizontal scrollbar. This means that something’s pushing the page out to be wider than it wants to be, and so you have to scroll left and right on every device to see the full content. This is ugly anywhere, but it’s an especially efficient way to ruin the user experience on mobile devices.
For the record, this bug isn’t confined to full-width page templates (not that that would excuse the problem). You can get horizontal scrollbars in a boxed layout as well, by using a pageable container in a “stretched” row:
It may seem like I’m making a big deal of this, but you have to understand that “My site has a horizontal scrollbar all of a sudden” is not a small misstep by the plugin developers. It’s the exact kind of problem that people spend hundreds of dollars having WordPress developers like me debug.
It’s also the type of work that I absolutely hate doing: writing inherently hacky, fragile custom code to wrench very bad but deeply embedded commercial software back into place. Giving WPBakery’s page builder a close examination was very much an experience of staring into the dark heart of a huge percentage of these dismal debugging jobs.
On the same subject, the WPBakery Page Builder’s previewing is consistently, persisently different from how the actual page ends up looking to users, even on very simple layouts:
Again, you may not realize how significant a problem faulty previewing like this is—until you have someone (say, a client) who wants her design implemented actually correctly. Then you’re stuck trying to compensate for a tool that’s broken for obscure and unfixable reasons.
While we’re discussing inaccurate previewing, let’s mention the WPBakery page builder’s strange habit of hiding the nav menu on some—but not all—page templates:
We want a slider section that runs up right against the nav menu. How are we going to get that, when the preview not only lies to us about the amount of margin there actually is, but also hides the menu itself? Mysteries of the WPBakery page builder.
You simply cannot assume that any piece of the WPBakery Page Builder will work as it should.
Also, as with the Divi builder, deactivating the WPBakery Page Builder plugin is a one-way trip to Shortcode Hell, where you get to see exactly why the builder is as fragile as it is.
These examples aside, the broader trend is that you simply cannot assume that any piece of the WPBakery Page Builder, used for any purpose, will work as it should.
In reviewing this plugin, it can be difficult to get across the crucial distinction between defensible shortcomings and plain, actual nonsense.
It’s actually hard to review the WPBakery plugin, because so much of it is broken so badly that it’s hard to explain. Specifically, it can be difficult to get across the crucial distinction between defensible shortcomings—“rough edges,” “questionable design choices,” and so on—and plain, actual nonsense. So much of WPBakery Page Builder is, quite simply, nonsense.
I could give so many examples here, so I’ll confine myself to a few that are representative. The first is a detail about WPBakery’s front-end interface. Do you know what the single largest UI item on the page is? It isn’t something like a “Save and View Changes” button (which is actually a small “Update” button and, separately, a plain X), or any other piece of useful UI.
No. It’s a hat that links you to the WPBakery purchase page. Not to documentation, tutorial videos, or tech support: to the purchase page, for a paid-only commercial plugin that you logically must have already purchased to be seeing this interface.
This single design choice itself doesn’t do much to break the WPBakery user experience—but it is a great, simple illustration of the thoughtlessness that runs throughout the entire project.
Here’s another example: the WPBakery page builder plugin has no boxed layouts. Without using external CSS, there is no way to, for example, create a full-width row with a light gray background, which contains an 800px-wide centered text box. If you look at the Tile homepage, about half the content is boxed text in a fullwidth layout, and this is simply impossible with WPBakery by default.
But in simply assuming that we’re dealing with a boxed page template, and then giving no fallback for actual full-screen layout creation like you’d use to build almost any landing page in the world, WPBakery is shipping a bizarrely incomplete product that puts what builders should find easiest—having the full screen to work with and only using part of it—out of reach.
I’ll give a few more examples. The way WPBakery lets you save “Templates”—full pages of content—but not modules, columns, or rows. Or the decision to let you add new “Deprecated” modules (rather than just continuing to support them if they’re there already)—but only if you use the “Add New Element” dialogue from the big white plus in the top left. The handling of widgets, which lets you add some kinds of widgets as modules (like “Recent Posts”) but not others (like “Audio”) for unclear reasons.
I’ll close with a final example that, to me, summarizes the whole plugin. The “Separator” element (for creating
<hr>s) lets you pick colors not with a color picker, but with a dropdown of around 16 color options with obviously custom-defined names like “Peacoc,” “Mulled Wine,” and “Juicy pink” (yes, with irregular spelling and capitalization)—including one color, “Vista Blue,” that is in fact a light sea-green—plus a “Custom color” option at the bottom that opens up a new option, “Custom Border Color,” that is the color picker that the entire interface should have been all along.
Again, these are just examples, chosen more or less at random from within a piece of software that simply does not make sense. If you’re not convinced of that at this point, you’re beyond my power to persuade, and may want to try the product for yourself.
WPBakery Page Builder Review: Summing Up
I came into this review believing WPBakery Page Builder was badly broken and an enormous source of badness in WordPress overall. After working closely and attentively with the plugin, now I know it. Avoid.
Beaver Builder Review: The Best WordPress Page Builder
I’ve reviewed Beaver Builder in depth once before. That review corresponded to Beaver Builder 1.x, and we’re now on 2.x. I want to update that review fully, but in the meantime the main thing that’s changed is that the Beaver Builder interface is now much more seamless and intuitive than it was a year ago.
As you’ll see, what hasn’t changed is that Beaver Builder, alone among the WordPress page builder solutions I’ve tried, actually works: you can use it for stuff, and the stuff gets done properly. It’s with that sense of basic celebration that I’ll launch into this review of Beaver Builder’s performance on our test.
Beaver Builder: The Good
It Actually Works
By this I mean: You can use Beaver Builder to quickly accomplish your actual goals. I was able to get a solid, attractive, non-buggy, non-fragile start on the Tile homepage design in about 20 minutes of work—while also demoing a flawless Gravity Forms embed and a passed “multi-part” shortcode test at the bottom:
Of the four builders I tried, my progress in Beaver Builder was without question the one I’d most want to show Tile themselves. I could honestly say, “We’re well underway implementing your homepage design, just need a fair amount of polish work, fonts and so on, but we’re on the right track.”
The pages I created in the Divi and WPBakery builders, because of those builders’ structural weaknesses, are interesting case studies of failure and dead-ending—not progress toward an actual web development goal. My progress in Elementor was pretty smooth, but also seemed to risk being buggier; I’d feel a fair amount more anxious during the demo.
What You Write Becomes Actual Reality
This point has a few facets.
In Beaver Builder, you do layout by cleanly setting actual CSS layout elements.
First, in Beaver Builder you do layout by cleanly setting actual CSS layout elements—in particular, padding and margins—for every row, column, and module you create. When you set a row to be “full-width” and set its padding and margins to 0, the row then actually, truly stretches to be the full width of the content container. When you set the content within that row to be “boxed” with a max-width of 800px, the content actually, truly has a max-width attribute of 800px. When you set a module to have an 80px top margin, that gets filtered directly through to an actual CSS style that you can look at and change.
What Beaver Builder doesn’t do is skip steps in its user interface, by relying too heavily on blunt instruments like 12-column grids (which it uses and which are wonderful, but with the huge difference that you can actually set the width of the space being divided into columns), or by jumbling real layout concepts into mushy, end-user-convenience-focused systems like “gutters” or “stretch columns.”
As a result, a layout that in WPBakery Builder you’d be trying to cobble together with “a stretched row containing a single 1/2 column plus I guess two 1/4 spacing elements but I hope we can get those to disappear on mobile and also I guess we’ll need to set a max-width for the 1/2 column,” in Beaver Builder you just declare cleanly, simply, and literally.
When you click Done > Publish, what you see is exactly what you saw when you were editing the page.
The next thing that happens is: Your declarations stick. When you click Done > Publish, what you see is always exactly what you saw when you were editing the page. That means no surprise horizontal scrollbars, no disappearing nav menus, no unexplained extra margins or padding. In Beaver Builder what you write sticks, and your visitors see it as you’ve designed it. That’s what WYSIWYG page builders are supposed to do, and it’s hard to describe what a difference it makes to be using one that actually does it.
The main takeaway from this GIF is, again, what happens when I click Done > Publish. What happens is nothing: everything sits in place exactly, precisely, down-to-the-pixel where it’s been told to be, because it’s all resting on styling rules that are actually real.
A subtlety that points back at the high underlying quality of Beaver Builder’s approach to layout is what happens when I change the slide height from 500px to 400px. Nothing happens right away. Why is that?
It’s because the slide text itself has so much top and bottom margin that it’s “pushing” the slide itself to be taller than the height we’ve suggested for it. When we reduce the text’s top margin from 250px to 150px, the slide can finally “relax” down to the 400px we’ve suggested for it.
This is how actual web layout works, and even if the ability to make two contradictory statements and only have one take effect might confuse some end-users with no technical grounding, it’s heaven to a developer who thinks in actual layout terms.
Fallback to Clean HTML
One amazing thing about Beaver Builder is that if you turn it off, the markup falls back to astonishingly clean HTML:
This is a really, really good sign for a bunch of reasons. First, it solves the practical concern of how to get your page content back out if you ever need to deactivate the builder—a major issue with Divi Builder, WPBakery/Visual Composer, and most other builders.
The clean fallback shows that the Beaver Builder developers actually care about code quality.
Second, it shows that the Beaver Builder developers actually care about code quality. Working with the other two builders involves (to different extents) the very familiar sinking realization that the commercial software you’re stuck using simply doesn’t care about quality: they sell to the end user, and any fatal flaws that an end user won’t pick up on become your problem. Beaver Builder gives the opposite feeling in numerous places, and this is one of them.
Third, and probably most important, this means that Beaver Builder itself is built on something less fragile, buggy, ugly, clumsy, and about-to-be-destroyed-by-Gutenberg than shortcodes. Of the builders reviewed here, Beaver Builder most displays an underlying robustness, a hey-that-worked quality that makes you dare to trust the software. That is 100% related to the fact that its creators didn’t hitch its vast layout and design functionality to the awkward, fragile, and wonky shortcode API (or, as a reader of this article commented, to the devil’s bargain of iframes).
Building an ever-growing page builder’s worth of complex features on shortcodes means you’re always playing defense—always compensating for the slow, fragile, and bulky engine at the base of everything. Beaver Builder is different: it can actually make sense, and that feeling of not being in overwhelming technical debt shines out loud and clear throughout every aspect of the user experience, as we’ve discussed in the sections above.
Beaver Builder: The Bad
Relatively Few, Blandly Named Default Modules
In Beaver Builder I often do find myself wondering if there’s a module that does what I need, and what it’s called if so. Module names like “Callout” and “Icon,” with no explanation text, don’t give a very clear picture of what you’ll get when you open them up; and the overall population of modules is relatively slim.
I’m curious about trying some of the module packs that various developers have built for Beaver Builder, but I’m also quite aware that when you go from “plugin” to “unofficial extension,” you open yourself up to a lot of additional fragility and bugginess. I intend to test out and comment on extending Beaver Builder in this way in the future.
Reliance on Truly “Full-Width” Page Templates
One thing Beaver Builder doesn’t do—and that I really value about (of all things) WPBakery Page Builder—is allow you to stretch a row horizontally beyond the bounds of the normal content container.
In other words, if you’re using Beaver Builder on a “No Sidebar” page template that just gives you one 1100px column to work with, there’s no easy way to create elements that are truly full-width—meaning going to the edge of the screen, rather than just to the edge of the 1100px boundary that’s set up.
The burden is on you, the developer, to know how to create “empty” or “true fullwidth” templates that give you the entire horizontal screen area to work with, or to be using a theme that has them.
This means that the burden is on you, the developer, to know how to create “empty” or “true fullwidth” templates that give you the entire horizontal screen area to work with, or else to be using a theme that has one or more of those templates.
No “Undo” on Layout Changes
Beaver Builder doesn’t let you undo layout changes, such as moving or deleting columns. Sometimes I’ll delete a column by accident and have to re-make the overall layout within the row, which makes things feel more precarious than they would otherwise.
Beaver Builder Review: Summing Up
What I can’t fully convey here is just how helpful a good WordPress page builder like Beaver Builder can be to a WordPress developer’s day-to-day work.
As I’ve made clear, the Divi and WPBakery page builders are on one side of the “It makes my job easier” continental divide, and Beaver Builder is on the other side.
What I can’t fully convey in this review is just how helpful a good page builder can be to your day-to-day work as a WordPress developer.
If you haven’t tried it yet, I strongly encourage you to do yourself a favor and try Beaver Builder today.
Elementor Review: Extremely Ambitious, A Bit Buggy, Very Good Overall
Look closely at Elementor, and you’ll find an exceedingly ambitious and very high-quality page builder.
I’ve tried Elementor once or twice on past projects, and somehow it never “stuck.” It always felt just a little buggier than Beaver Builder, and I always felt a little out-of-place in the user interface.
As it turns out, those issues remain unchanged. But I’m really glad for the deep-dive I took into Elementor: past those immediate irritations lies a shockingly ambitious and overall excellent page builder. It may not be good enough (specifically, seamless enough UI-wise and bug-free enough) to shake me loose from Beaver Builder, but there’s a lot that only Elementor does that I really, really want now, and I’d happily recommend the plugin.
Elementor: The Good
Robust and Thoughtful
Elementor is, overall, good software.
There’s not a great screen-capture for this, but Elementor is, overall, good software. I found myself mostly able to work in it.
This breaks down into a variety of general strengths—“for the most part” statements such as:
- Things are where I want or expect them.
- Layout options are sane and detailed enough for a developer to use.
- Individual elements (“Header,” “Image,” etc.) come with the right options and work properly.
- The UI is fast enough and works smoothly enough to not create a major buildup of frustration.
Overall, I felt like my work with Elementor progressed mostly smoothly and at a good pace: the landing page was coming together nicely by the time I stopped. That’s pretty much the bottom line for page builders, and it puts Elementor, very generally, in the “good” column.
Whoa, That’s Extremely Cool: Dynamic Values
With Elementor, you can insert programmatically determined values into your page builder content.
This blew me away when I first saw and understood it. With Elementor, you can insert dynamic, programmatically determined values—like “current date and time” or “current post title”—into your page builder content:
I can’t say enough about what a cool and broadly useful feature this is—it makes every other page builder feel feature-poor in a way that’s going to bother me now. This might be especially useful for developers who are less comfortable registering widgets, shortcodes, or the other not-great ways to get dynamic data onto the page.
Rich Layout Customization Options
Elementor gives you a huge amount of very useful flexibility in terms of layout:
Section layout features include:
- An option to set the section height to 100% of the screen height.
- The ability to vertically position elements (top, middle, bottom) within that height.
- A feature which I’ve never seen before, and which I absolutely love: the ability to dictate which HTML tag (
footer, and so on) wraps the section.
Elementor lets you control layouts in ways that I haven’t seen another page builder match.
Together, this feature set lets you control layouts in useful-to-a-developer ways that I haven’t seen another page builder match. Seeing the thoughtfulness and power of these layout features was one of those moments where I really started to feel like I “get” Elementor and its appeal.
I do have some implementation issues here. I don’t like that “Columns Gap” is a bunch of words (“Narrow,” “Wide,” “Wider,” and so on) rather than actual numerical values: why take power from developers when most other things are fairly rigorous?
Similarly, it might be nice to let the “Content Position” be a percentage rather than a dropdown, for edge cases where you want things to be 25% from the top of their container.
And I’d love to see the “HTML Tag” option either have an “Other” option and a text field, or just be a text field in the first place—that would let you specify your own HTML elements, and not rely on Elementor’s prepopulated list. If you’re using this option, you’re a developer, and developers can type
div properly into a text field or suffer the consquences.
But these are side-notes to the overall point, and that is that Elementor gives you a ton of layout control. I believe it does this the best of the builders I’ve reviewed.
Lots of High-Quality Elements
Elementor has an enormous profusion of layout elements.
If there’s one place that Beaver Builder feels week, it’s in the variety of default layout elements it makes available. They tend to feel both bland and blandly named, and I’m always wondering-slash-doubting if Beaver Builder will have a module that’ll do the next thing I need. Of course, there are Beaver Builder extension packs, but I haven’t gotten into using those yet and I’m concerned about brittleness and an overall drop in quality once you’re making heavy use of third-party extension packs.
Elementor does not have this problem. It has an enormous profusion of default layout elements:
In my limited testing, these layout elements were uniformly high-quality: simple, well-named, robust, easy to customize. You can use these to do everything from restaurant menus to product sale countdowns—all handled by your page builder.
Far more than the other builders on this list, Elementor is really trying to create its own unified, in-house visual and technical language for common layout elements of all kinds. If you know where I think WordPress needs to go, you know how dear a project that is to my heart—even if I’m skeptical that a third-party builder’s proprietary solutions will be able to complete with the official WordPress “Blocks” concept once Gutenberg finally arrives solidly enough to start bending the market toward itself.
Of all the builders I’ve tried, Elementor clearly seems to set its sights the highest.
Using Elementor, I consistently felt, “Wow, this project is really trying to give me as much power as possible.” Of all the builders I’ve tried, Elementor clearly seems to set its sights the highest.
Everything we’ve said so far points to that, but let’s give another example, in the color palette system:After reading Elementor’s notes on its approach to colors, I realized it’s aiming squarely for an integrated, Squarespace-like “You change it once, and every element reflects that change” experience. This sort of change-it-once integration is what WordPress should be—and what, for example, Gutenberg will hopefully be in five years. I’m not saying Elementor gets to Squarespace-land now, or will get there ever, but that’s certainly its ambition.
As another example, the way that many layout options (such as padding) are available in
% units is the kind of above-and-beyond feature that made me realize: “Oh wow, the goal of this project is to empower me totally.”
Elementor’s ambition could honestly be the headline for everything I like about it. My favorite Elementor features—its rich layout options, its dynamically calculated values, its huge array of layout elements—are all a result of the Elementor team thinking more ambitiously than any other page builder I’ve reviewed about how to put more power in the user’s hands, and then going out and doing it.
Writes Clean Post Content
Like Beaver Builder, the other I’d-actually-use-it page builder in this review, Elementor falls back to clean HTML when you turn it off:
This tells us not only that we can turn Elementor off if we need to, but also that Elementor’s developers have made smart fundamental architecture choices. That freedom from contorted fundamentals shows in an overall faster, more robust, and less error-prone experience than either of the shortcode-based builders in this review.
Elementor: The Bad
Elementor’s previewing is good, but it isn’t perfect, and less-than-perfect previewing is a significant problem.
As small and “get-overable” as this seems, it makes me worry about using Elementor on client projects. “My homepage banner has weird white space next to it and it looks incredibly unprofessional,” emails the client at 11:30 PM. What happened? I can’t trust Elementor to tell me the truth about how everything looks, and so now I’m using browser inspectors in two different tabs to compare the front-end itself with the Elementor view to see how the margin snuck in. In other words, I’m debugging my page builder: bad times.
This issue can occasionally become more serious. The Gravity Forms preview was way, way off from the (fine-looking) final product:
I didn’t attempt to debug the problem, but I believe that Gravity Forms’s stylesheet is having trouble making it into the Elementor preview—which is a troubling sign, since there are plenty of plugins other than Gravity Forms that need to register their own CSS styles.
Page builders create layouts. When your page builder misleads you about layout, it’s a big problem. Elementor’s performance on this topic wasn’t very encouraging.
Weirdly Divorced from the Front End
This is probably the single reason why I’ve never felt like using Elementor extensively on my own projects. Elementor always feels next to, and even weirdly in the way of, the front end. I feel like I’m always fighting Elementor to get to “okay, how does my webpage look now?”—which is about the last experience I’d expect, or want, from a front-end builder.
Once you’re editing a page in Elementor, you cannot view that page without Elementor in the way somehow, except by manually navigating to it in a new tab.
I’ll start with what I find to be the most frustrating manifestation of this design problem: Elementor has no interface for “stop editing and view this page.” Once you’re editing a page in Elementor, you cannot view that page without Elementor in the way somehow, except by manually navigating to it in a new browser tab.
And a “Preview Changes” button that does take you to the page itself, but opens in a new tab and still leaves a
/?preview_nonce=0d7ae825e0&preview=true-type query string on the page, which is just enough to leave me not knowing if what I’m looking at is actually final or not:
If you remove the query string, you’re finally on the page, but you’re in a new tab with the old one still open, and you had to trim your URL manually to get rid of the idea that the page is somehow a preview.
So the issue is that there’s no direct, in-the-same-tab escape hatch to the front end. Writing about this design choice by an otherwise mostly powerful and thoughtful plugin is one of those “Am I crazy?” moments. How could you build a front-end builder that won’t let the user quickly see the front end? I can’t tell you how many times I scoured the interface for a “Publish and Close” button. If you like screengrabs of frustration, here’s what those searches looked like:
I suspect this design choice may result partly from a technical difference between Beaver Builder and Elementor. When you’re editing a page in Elementor, your browser’s URL bar shows you’re at the “edit post” URL for that page in
wp-admin, just like you would be if you used the back-end editor, with the addition of an
&action=elementor query string. When you edit a page in Beaver Builder, you’re at the URL for the page itself, plus a
admin-ajax calls. And I’m guessing that this is why Elementor makes it so frustratingly hard to get from “front-end editor” to “actual front end.”
Contributing to this overall issue is Elementor’s general layout as a Customizer-style strip along the left side of the page. I have mixed feelings about this choice, but overall I prefer pop-up windows. Beaver Builder’s large text boxes can sometimes get in the way of the content they help you edit, but at least you feel like you’re interacting with the front end itself, not an off-to-the-side sidebar-y representation of it.
The issue is more, simply, that I’m not on the front end: I’m next to it. This Customizer-like strip is crowding my content over onto the right part of the screen, and I’m mainly interacting with the strip rather than with my content directly. It’s not the end of the world as a design choice, but it is a layer of the type of abstraction that front-end builders—to me—exist to remove.
Overreaches in Places
In places, Elementor’s ambition overreaches to an extent.
Above, I praised Elementor’s ambition. But in places, that ambition overreaches to an extent.
When I activated Elementor—without setting any typography or color schemes, just activating the plugin—it immedately overrode (broke) the theme’s existing typography, replacing UnderStrap’s tall/thin/gray/default-font headers with its own squat/bold/blue/Roboto default choice:
This basically steals the theme’s thunder. In my opinion, it’s fine to offer color and typography features in a page builder, but not to erase the theme’s own choices even if I ignore those builder features. I later found out that Elementor has options to “Disable Default Fonts” and “Disable Default Colors”; but these are in a back-end (
wp-admin) settings interface that many people likely won’t find. I think it should be an opt-in, not an opt-out, with the opt-in happening automatically if the user starts actively making typography choices in the builder.
Similarly, Elementor has a “Maintenance Mode” feature that lets you hide your site behind a “coming soon” or “maintenance mode” notice:
Say it with me: “Why do I want my page builder putting my site in maintenance mode?”
It’s cool that you can throw up an Elementor template as the maintenance mode page, but overall this seems like plugin feature creep to me—at least bundled as a core plugin feature and not an extension. There are good maintenance mode plugins already. I don’t like a page builder plugin I can’t turn off without accidentally publishing my entire site to the web.
A Few Unfortunate Choices
Some Elementor choices and features don’t gel as I’d expect, in a way that feels like it reflects puzzling or incomplete design decisions.
For example, I strongly dislike that Elementor elements are called “Widgets”:
Really? You’ve decided to reuse WordPress’s hardest-to-visualize piece of techno-jargon, so now it’s no longer clear whether “widget” refers to “actual WordPress widget” or “Elementor element?” You named your plugin Elementor, for crying out loud—call them elements!
Similarly, the color palette system is great, but I really don’t like how I can only customize the top, nameless color palette, but not actually save my own named palettes. I’d much rather have a “Save Custom Palette” feature than the handful of stock named palettes they give me—which, in my mind, are more or less useless except for demoing the feature itself. I’m a WordPress developer, setting a color scheme for a site that I intend to design carefully and thoughtfully. What are the chances I’m going to look at the eight color options you show me and go “Sure! That one!”
Elementor’s powerful and thorough feature set also comes with some nagging irritations.
As one more example, I don’t like how the “Color Palette” and “Color Picker” features are completely separate: you have to manually add the same colors to both interfaces if you want in-palette default colors to show up in your color pickers. Wouldn’t you want the color picker to at least default to being filled by the active palette? What are the chances I’m going to go to the trouble of specifying the color palette I want on the site, and still want your random forest green showing up as a default option in my color pickers?
These specific examples aside, the broader point is that Elementor’s powerful and thorough feature set also comes with some nagging irritations.
Elementor Review: Summing Up
Elementor is by far the most ambitious builder plugin I’ve ever seen, while also maintaining a mostly high level of quality.
Given what Elementor makes available, I can’t not recommend it. It’s a great page builder plugin, and it’s by far the most ambitious builder plugin I’ve ever seen, while also maintaining a mostly high level of quality.
Yet I, personally, will be sticking to Beaver Builder for my own projects. Part of this is a level of personal preference in terms of UI: to me, using Elementor feels, at times, confined and separate in a way that I started using page builders to escape.
Elementor is buggier than Beaver Builder.
The far more important issue is also not nearly as subjective: Elementor is buggier than Beaver Builder, inaccurate previewing being the main problem.
To me, page builders are a bit like parachutes: reliability is everything. The only reason I started using WordPress builders at all is because Beaver Builder relentlessly failed to disappoint me—for so long, and so consistently, that I started to realize I could actually trust the software in real projects. For all its amazing strengths, Elementor remains just slightly more in cross-your-fingers-and-bite-your-nails territory than Beaver Builder, and that’s somewhere I simply don’t want to be.
So Beaver Builder is significantly plainer than Elementor, but it’s also noticeably sturdier. I also personally prefer Beaver Builder’s UI. But they’re both outstanding plugins, and they’re leaps and bounds ahead of both Divi Builder and WPBakery Page Builder. I can happily recommend both.
What About Other Builders?
Most smaller WordPress page builders have all the problems we’ve identified in these builders, and many more.
There are a ton of page builders out there, but speaking from experience: if you haven’t heard of them, they’re unlikely to be very good. WordPress page builder solutions, like airplane manufacturers, tend to benefit from economies of scale, and from time to refine themselves in the marketplace. So just like it’s unlikely there’s a “garage Boeing” lying out there somewhere to discover, most smaller WordPress page builders have all the problems we’ve identified in these builders, and many more.
Having said that, I do want to point out two other builders that are worth examining and which I’d eventually like to work into this article:
- Site Origin Page Builder, which I’ve been encouraged a few times to review following the original publication of this article. It’s on my to-do list.
- Offsprout, which markets itself as “WordPress’s first drag-and-drop builder for design agencies and freelancers.” It’s run by Sam Brodie, a very passionate WordPress architect who I met at WordCamp US and whose vision and approach I really admire. Its Pro version just launched, and I’d like very much to check out and review it soon. In the meantime, I urge you to have a look—I’d love to hear your feedback on it, and I know Sam would too.
What About Gutenberg?
Wait, why are we still talking about WordPress page builders? Isn’t Gutenberg—the official layout solution slowly making its way into WordPress core—just going to kill all builders off really soon?
In a word, no.
The just-launched Third Edition of our “learn WordPress development” course Up and Running contains around 10,000 words on exactly what Gutenberg is and isn’t, and what it means and doesn’t mean for WordPress. I encourage you to learn that material from the source, and I don’t want to try too hard to summarize a very complex and interesting topic here; but here’s, very briefly, what I’d like you to understand:
Gutenberg is nowhere near to being a layout builder in the same sense as any of the plugins we just reviewed.
Gutenberg is nowhere near to being a layout builder in the same sense as any of the plugins we just reviewed. You couldn’t even begin to put together the layouts we assembled in any of the reviewed plugins, even one as flawed as the WPBakery Page Builder.
How is Gutenberg right now as a layout builder? Well, Gutenberg has columns, sort of, but they’re utterly primitive and there’s no way to style them. Nor is there currently any notion of the “Rows” layout element that is extremely important and useful in every major layout builder plugin. Gutenberg is also not on the front end—and won’t be, in its official implementation—meaning you’re building your website’s pages in a
wp-admin environment that, at the end of the day, doesn’t look much like them.
So for layout-intensive tasks, Gutenberg is not a page builder competitor right now, and it won’t be in the near future—although it does certainly carry a lot of longer-term possibility for disrupting dynamics in the WordPress page builder space (and in WordPress as a whole). For more details, I urge you to read Up and Running: the Core version is just $67, and that’s an immense amount of WordPress wisdom, including Gutenberg wisdom, for the price of only six $11 cups of coffee.
tl;dr: Get Beaver Builder Now
If you’re in the market for a WordPress page builder, my top choice is Beaver Builder. If that’s all you take away from these 8,000 words and 50 GIFs, that’s enough.
I can also happily recommend Elementor:
What experiences have you had with WordPress page builder solutions? Let us know in the comments below!