I want to start by saying that I didn’t want to do a Gutenberg vs Beaver Builder comparison, since in their current state I don’t see them as direct competitors. However developing for both tools is different enough I decided to write a comparison between developing for Gutenberg vs Beaver Builder, and why my preference is Beaver Builder.
Despite my preference of developing for Beaver Builder I think Gutenberg is a dramatic improvement over the classic editor and will be the foundation of a new era for WordPress, and you can read more about that in my WordPress Gutenberg Review.
My Development Environment
I’d like to give an overview of my two primary development environments as this is part of the basis for my preferences.
- Personal Development Environment
- I regularly work on a Mac OS X computer and Windows 10 computer. I use OneDrive to share all of my files between the two computers. Each are setup with Node, PHP, Phing, Git, etc. I develop directly on my dev web server (ssh-on-save) and then build and deploy where necessary. This allows me to move from one computer to another with no interruption, and no need to maintain a XAMP stack on each local computer.
- Work Development Environment
- My work environment is very similar, except that I’m working exclusively on a Windows 10 computer and all files are saved on a local network drive so that they can be shared with co-workers. We’re utilizing a dev/stage/prod server setup there as well (with ssh-on-save to dev).
Why I Prefer Creating Modules Over Creating Blocks
When learning to develop for a new tool one of the most important things is developer/API reference and examples. Both Gutenberg and Beaver Builder have solid developer reference, however in general I feel that Beaver Builder’s is better organized. Its examples in the reference (and the modules within the plugin itself) are also a great source of reference and the vast majority of the time code can be copied directly into your own custom modules and it will work. Conversely, Gutenberg is attempting to remain as developer friendly as possible and has provided reference in ES5 and ESNext (ES6+ and JSX), but there isn’t always example code in both versions, and there isn’t always context surrounding the code letting you know where/how it should be used.
If you’re serious about making Gutenberg blocks it’s all but mandatory to use build tools (node/webpack/babel/etc). Without this your project could end up enqueuing dozens of JS and CSS files, and none of the ESNext/JSX code will run in the browser. Getting your project setup to properly use these build tools is one of the biggest hurdles to get past when first starting out with Gutenberg, especially if you’re not already using them for other projects (such as React). As mentioned earlier I work off of a remote development server so this type of workflow isn’t ideal as I have to build (or have webpack watching my files and auto-build) and then upload them to my remote server to test. This adds an extra step and is less efficient, and if anyone has any recommendations as to how I could improve this workflow please leave a comment!
Alternatively, with Beaver Builder there is no need for build tools as there is no need for ESNext (unless you just really want to use it) or JSX. On top of that, to prevent dozens of JS and CSS files from being enqueued Beaver Builder renders out all of the necessary dependencies for a given page and caches that as a single JS and CSS file on the web server. So, as long as a module has been built correctly it’s as simple as editing your files, and saving them, and Beaver Builder handles the rest.
Alternatively, Beaver Builder controls are defined in PHP as a series of nested arrays and they can be dynamically built using data already available in PHP, with no need for extending the WP Rest API or making Ajax API calls. This has been beneficial for me in several projects over the years I’ve used Beaver Builder as I was able to take an existing PHP app and build a Beaver Builder module for it with very little code duplication by utilizing the apps existing APIs.
Rigging a Block or Module
In order to setup the skeleton for a block you need to add necessary fields (components/elements) to a BlockControls or InspectorControls component and then setup all necessary event listeners. This is both a pro and a con as it gives you complete control over how everything is setup, but you also need to setup everything to make sure the state is updated as inputs change.
On the other hand, with Beaver Builder, rigging up a module is as simple as creating nested arrays that define the controls and their behavior – the vast majority of the time there is no need to worry about module state or event handling as that’s all taken care of by Beaver Builder itself. Once in a great while I’ve found the need to create my own field types, but that’s been a rarity. It’s so incredibly easy to setup advanced/complex input controls, such as repeatable sets of controls (called forms, that are re-usable throughout a project, in Beaver Builder).
Experience and Familiarity
Without any doubt I have more experience creating modules for Beaver Builder than creating blocks for Gutenberg. This is largely due to Beaver Builder being around several years longer than Gutenberg. Regardless, as open minded, and objective, as I’m trying to be about Gutenberg this experience, and familiarity, creates a natural bias towards Beaver Builder and this is something of which I’m very well aware. The flip-side of this is that once Gutenberg has been around for as long as Beaver Builder it has huge potential to be much more than it is right now.
The End Product
Gutenberg is now part of the WordPress core so it’s incredibly appealing to developers (including myself) to use a standard that is likely to be a part of WordPress for many years to come. On top of that blocks are super portable between instances of WordPress since there are no plugin dependencies. This is an undeniable benefit of Gutenberg over any third-party page builder product. Lastly, there will naturally be more designers, developers, and editors within the community than any plugin could ever hope to attract.
In spite of how I began this review, stating that I didn’t want to directly compare Gutenberg to Beaver Builder, it’s difficult not to when comparing the end product of a block vs a module and the environment in which each resides. Another way of putting it is that the sum of the editing experience is comprised of more than a single block or module, no matter how great they may be, but rather by the experience of using the editor or page builder as a whole. In each of their current states Beaver Builder has immeasurably more flexibility and features than Gutenberg and I know that my custom modules can easily be used in countless different ways.
In the end, I actually do enjoy creating blocks for Gutenberg; I just prefer creating modules for Beaver Builder.