A few weeks back, Devin Egger stirred up a small hornet’s nest when he made the case for choosing Divi, at least when compared to Wix or WordPress’s own Full Site Editing (FSE). The public response was quite similar to our own internal reaction when the idea was first pitched – shock, disbelief, and maybe some admiration.
Personally, Divi is my least favorite of all the page builders. In my page building days, I was a hardcore Beaver Builder fan, and I still find their ecosystem and community to be one of the best. And if I had to pick between Elementor and Divi, I’d probably first consider a career change, remember that I need to feed my numerous children, and go with the very popular Elementor ecosystem. Then I’d prepare myself for more than a few security vulnerabilities to ruin my weekend.
But that was the past; now we have Full Site Editing, assuming the beta tag is removed in the forthcoming 6.0 or 6.1 release. I even used the new Twenty Twenty-Two theme on my personal blog, to try out FSE and because it’s a beautiful theme. While it wasn’t nearly as enjoyable or frictionless as using something like Beaver Builder, there were some real glimpses of potential.
When Devin’s article about Divi came out, we saw a few recurring comments from the community with some pretty strong arguments against Divi and against page builders more broadly. But the more I read through them, the more I was reminded of the block editor itself. Much of what was said could have easily applied to Full Site Editing, leading me to the title of this article: the block editor is a page builder, too.
Shortcode Soup
One of the biggest complaints about Divi is its heavy reliance on shortcodes to render content. In a method used by others, such as Visual Composer, Divi takes the contents of its interactive page builder and stores it using the WordPress method of adding attributes to shortcodes. If you go back in time a decade or more, it made sense and was a very “WordPress-y” way to do things. However, the minute you disable the page builder, you lose access to all of those shortcodes and any semblance of a usable HTML.
The block editor’s response to this is to store everything as raw HTML, with comment tags that stash serialized JSON objects for settings. And many block plugins or tools like ACF Blocks can abstract things even further. In this sense, with the core blocks, you should be able to pull the rendered HTML out of the database entirely and just use it. With Divi, you would need to be able to run your actual site, allow it to render the pages, then copy the content from the front-end.
So what’s the big difference here? In the block editor, you have raw HTML ready in your database, no processing required. Of course, if you’re using any sort of block plugins or enhancement suites, then we really start to see this differentiation go out the window. In fact, I’d argue that most of the HTML for anything beyond a typical post would still be pretty unusable. Columns and alignment won’t render, cover blocks wouldn’t actually cover anything, spacers are meaningless – you get the picture.
In either case it’s pretty easy to get the raw HTML that you can copy/paste somewhere else, but with Divi’s reliance on shortcodes, you may run into more trouble with a broken site. Score one for the block editor here.
The User Interface
While I didn’t see this complaint out in the wild, one of my largest issues with Divi is the user interface. The icons always felt meaningless and the interactions are extremely sluggish. When you open the editor on any page with more than a few rows of content, you may as well schedule in a bathroom break and a short nap before you’re ready to edit anything, as the interface takes forever to load.
On the other hand, I see page builders like the early automobile industry. Maybe one of the big companies comes up with some fancy new feature first: the steering wheel, anti-lock brakes, the tiny little fridge that doesn’t fit anything or even get cold – but pretty soon you see the same features in every new car on the road. The ‘standard’ features of a page builder become so widespread that anything that set your product apart (like being able to modify the header, footer, or archive pages) will pretty soon become standard fare.
In this way, the Block Editor’s UI really is not that much different from what was already out there. Fixed sidebar panels to control settings, liberal use of vague iconography, drag-and-drop functionality, all powered by a chunky JavaScript library. I think for ease-of-use, the block editor’s UI probably falls behind Beaver Builder and Elementor (which may be why Elementor’s growth is out-pacing WordPress itself). However, the Gutenberg team takes interaction speed very seriously, and has made amazing strides in that respect.
Accessibility
Accessibility tends to be the top issue for any web platform, and this makes complete sense. We’re rebuilding the entire world in digital form, and the fact that accessibility is moving closer to the center of developers’ minds is amazing progress.
When discussing accessibility in page builders, there are actually two different topics – the accessibility of the page builder experience itself and the accessibility of the website content for visitors to your site. In other words, a page builder needs to be accessible for anyone who will be managing content, as does the final result of what you build.
After an initial outcry and the departure of the accessibility team lead, it does feel like the accessibility of the block editor has improved, both back and front end. They’ve even begun incorporating tools like color contrast checkers. On the other hand, I’ve been critical of the block pattern directory in the past, because I believe these accessibility checks are basically being ignored, and that moderation has been lax. I didn’t do a full audit of Divi’s Layouts, but the site itself did seem to fail some basic color checks, and keyboard navigation was unreliable at best. That didn’t leave me hopeful for the layouts themselves.
If there has been more ongoing accessibility testing on the block editor, I’d love to add it to this article, but for now, I’ll have to agree with accessibility expert Amber Hinds on this one: Divi has some more work to do.
Themes and Custom CSS
If you’ve read anything I’ve written about FSE, you probably already know that my biggest gripe is the lack of custom CSS. Most page builders actually encourage custom CSS by including a code editor in the builder itself. Elementor, for example, makes it very easy to apply CSS specifically to the block of content you’re editing, scoping it automatically for you.
FSE seems to actively fight against the use of CSS by hiding the customizer and moving us away from the live reloader. Instead, you can only fiddle with knobs and dials, text inputs and secret menus. What might take two lines of CSS instead takes a user manual and the ability to decipher hieroglyphics. In this way, FSE is more of a page builder than the other page builders!
While it’s been a while since I built a site from scratch using a page builder, the last I recall, you started with a very blank starter theme, like Hello, Astra, or the Beaver Builder theme. The idea was that you were going to control everything in the page builder, so the theme would simply get out of your way. With FSE, though, there’s still a place for themes that start you off with some personality. From Twenty Twenty-Two, Wabi, and Frost, to outliers like Tove and Kubrick2, many block themes come ready to make a statement, or at least push you towards a specific aesthetic.
I think the big distinction here is clear: other page builders are really marketed towards developers and marketing agencies. For users where pixel-perfection and a few lines of custom code are a necessity, you’re probably still better off with a third-party page builder. Full site editing really seems geared towards users who want a head-start and don’t have a fixed destination in mind. This is the Wix crowd, the Squarespace crowd, NOT the typical page builder crowd. Whether or not FSE is as easy as those other two… well we can leave that for another article.
A Great Page Builder should be a Platform
There’s nothing wrong with page builders – for the right project or the right type of client, a page builder is a great way to get a solid website up and running at a fraction of the cost. Sometimes the best development toolkit is the one you already have, whether its Divi, Beaver Builder, or [gulp] WP Bakery.
The best measure of a platform’s health is whether it’s helping others grow financially. WordPress is beyond healthy in this respect. We’re all indebted to its presence and the community for our livelihoods. We’re seeing the same thing for other page builders (especially Elementor). The ecosystem is growing and there’s financial gains to be made by using it. I think that will be the true measure of success for Full Site Editing in WordPress – will it inspire others to build on top of it?
When we build a “classic” site for a client, we like to tell them “if you can write an email, you can edit your website.” With full site editing or any page builders, we probably wouldn’t say that. Instead, FSE is closer to “if you can understand Photoshop but also some of the settings are missing…”
I think the eventual goal of FSE may be “if you can create a PowerPoint, you can edit your website.” Of course, PowerPoint is just one tool, and not always the right one for the job. Sometimes, the user just wants to write an email.
